Clef/Clef-Flash의 판별 성능을 7개 태스크로 Jev와 비교

Jev의 등장 이후, 확률로 판단을 반환하는 AI 모델에 대한 화제가 늘어났습니다. Laya나, Jev와 호환되는 API를 갖춘 Kev 등 오픈 소스 모델도 공개되고 있습니다. 이번에 시도할 모델은 이러한 흐름에 합류한 Cloudflare의 Clef입니다. 우선 판별 정확도를 확인하고, 판매 포인트인 속도는 다음 기회에 조건을 맞춰 검증해보고 싶습니다.

빨리 판단을 내릴 수 있어도, 거짓을 진실과 구별하지 못한다면 안심하고 맡길 수 있을까요? 이번에는 환각(hallucination) 탐지 결과가 궁금했습니다. 참고로 제목의 '거짓'은 근거와 다른 정보나 근거 없는 정보를 포함하는 환각을 의미합니다. 모델이 의도적으로 거짓말을 하는지에 대한 이야기는 아닙니다.

OpenAI 역시 2026년 9월 29일 DevDay에서 GPT-6 Luna를 사용하는 Decisions API를 한정 프리뷰로 발표했습니다. 공식 X 게시물에서도 실시간 의사결정에 사용할 API로 소개하고 있습니다. 질문과 답변 후보를 정의하여 콘텐츠 분류나 요청 분배, 에이전트의 다음 행동을 선택하는 메커니즘입니다. Jev를 사용했을 때부터 관심 있던 분야였지만, 각 사의 발표가 이어지면서 정말 흥미로워졌다고 느낍니다.

Cloudflare는 Jev나 Clef 같은 모델을 'Decision Model'이라고 부릅니다. 글이나 상태를 전달하여 '어떤 처리에 분배할지', '사람의 확인이 필요한지'와 같은 판단을 선택지별 확률로 받는 모델입니다. 본 기사에서는 '판별 모델'로 표기하겠습니다. OpenAI의 Decisions API는 답변 후보 중 하나를 선택하는 API로 발표되었으며, 확률을 반환하는지에 대해서는 이번에 확인한 발표에서 설명되지 않았습니다.

이후 2026년 10월 1일, Cloudflare가 Clef/Clef-Flash를 공개했습니다. 공식적으로 내세우는 것은 판별 정확도와 속도의 양립입니다. Clef는 품질을 중시하고, Clef-Flash는 응답 속도를 중시하는 포지셔닝입니다. 모델의 가중치(weight)가 공개되어 있고, API 역시 Jev와 호환됩니다. Jev에서 사용하던 질문이나 결과를 읽어오는 처리를 재활용하여 테스트할 수 있어, 정확도가 얼마나 다른지 궁금했습니다.

챗 모델에서도 구조화 출력(structured output)을 사용하면 판별 결과를 JSON으로 받을 수 있습니다. Clef의 특징은 글을 생성하지 않고, 선택지별 확률을 직접 계산한다는 점입니다. 애플리케이션 측에서는 그 확률에 임계값(threshold)을 설정하여 분류나 처리 분배에 사용할 수 있습니다.

이러한 의도가 명확히 보이는 것이 Hugging Face 모델 카드에서 링크된 Cloudflare의 정확도 및 응답 시간 비교 다이어그램입니다.

출처: Cloudflare 비교 페이지 (2026년 10월 6일 참조). 공식 다이어그램을 인용. 이번 실험 결과가 아닙니다.

가로축은 응답 시간 중앙값으로, 왼쪽이 빠르고, 세로축은 벤치마크를 집약한 Decision Index로, 위일수록 고정확도입니다. 좌상단에 가까울수록 속도와 정확도 양면에서 유리합니다. 점선은 다이어그램 내에서 'efficient frontier'라고 불리는 경계로, 정확도와 속도의 트레이드오프(trade-off)를 보여줍니다. 여기서 사용된 Decision Index는 나중에 소개할 이번 7개 태스크의 지표와는 다른 것입니다.

다만, 측정 방법에 대한 설명에는 주의가 필요합니다. Clef의 수치는 Cloudflare 자체 신고 값이며, 속도는 독자적인 제공 환경에서 측정한 것입니다. 다른 모델에 사용된 기준 GPU 환경과 동일하지 않아 응답 시간을 직접 비교할 조건은 아닙니다. 이 다이어그램은 공식이 목표로 하는 포지셔닝으로 읽고, 속도의 우위를 확인한 실험 결과와는 분리하여 다루어야 합니다.

이번에는 Clef의 사용법을 소개하고, Jev와 7개의 공개 벤치마크를 통해 판별 정확도를 비교합니다. 지난번에 측정했던 GPT-5.4와 Claude Sonnet 4.6도 비교 대상에 포함했습니다. 속도와 비용의 우열은 이번 평가 대상에 포함하지 않습니다.

Jev와 호환되는 API로 시도 가능

Clef의 API는 공식 모델 카드에서 Jev/SystemOne과의 호환성이 명시되어 있습니다. Jev를 사용하는 애플리케이션에서는 기존 질문 정의와 응답을 읽어오는 처리를 재활용할 수 있습니다.

입력하는 state와 questions, 그리고 질문 ID별 결과인 answers는 Jev와 동일한 형식입니다. 이용하는 서비스에 맞춰 연결처, 인증 정보, 모델명만 전환하면, 같은 판별 처리로 Clef를 시도해볼 수 있습니다.

state에는 판단 자료가 되는 글이나 상태를, questions에는 판단 항목을 전달합니다. Jev와 마찬가지로 질문에는 3가지 종류의 타입을 지정할 수 있습니다.

noul은 true / false의 확률을 반환합니다 -
choice

는 정의한 선택지별 확률을 반환합니다.
score

순서가 지정된 레벨의 확률과 기대 점수를 반환합니다.

API 형식은 호환되더라도, 반환되는 확률이나 판정 정확도는 모델마다 다릅니다. Jev에서 전환할 때는 실제 입력으로 정확도와 임계값을 확인해 주세요.

공개된 모델은 다음 두 가지입니다.

두 모델 모두 가중치는 Apache-2.0 라이선스로 Hugging Face에 공개되어 있습니다. GPU를 준비하지 않고 시도하려면 Cloudflare Workers AI나 OpenRouter의 API를 이용할 수 있습니다. OpenRouter의 API는 Jev/SystemOne과 호환되는 형식입니다.

OpenRouter에서 시도하기

API 연결 경로는 POST /api/v1/systemone입니다. 서비스 장애가 의심되는 메시지를 판별하는 예를 보여드립니다. API 키는 리포지토리나 코드에 작성하지 말고, 환경 변수 OPENROUTER_API_KEY에 설정해 주세요.

curl https://openrouter.ai/api/v1/systemone \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
...

응답의 answers.outage.noul에 true 측의 확률이 들어갑니다. Jev와 호환되는 형식이기 때문에, 모델명과 연결 경로를 전환하여 비교할 수 있습니다.

7개 태스크로 비교하기

ToxicChat, BeaverTails, HaluEval QA, HaluEval Dialogue, BoolQ, ANLI R3, Prompt Injection의 7개 태스크를 평가했습니다. 3가지 모델에 입력, 질문문, 정답 라벨을 맞추었습니다. API에는 각각 한 건씩 보내 각 모델로 총 3,800개의 판정을 진행했습니다.

이진 분류(Binary Classification) 6개 태스크는 AUROC로, 3클래스 분류의 ANLI R3은 Accuracy로 평가했습니다. 둘 다 값이 클수록 좋은 지표입니다. 코드, 실험 조건, 상세 결과는 clef-quickstart에 공개했습니다.

비교 대상으로 GPT-5.4와 Claude Sonnet 4.6의 지난 실측값도 추가했습니다. 두 모델과 Jev는 2026년 9월, Clef의 두 모델은 10월에 측정되었습니다. 저장된 예측 데이터에서 지표를 재계산하여 이번과 동일한 평가 대상임을 ID와 정답 라벨로 확인했습니다.

LLM에는 동일한 판단 자료와 질문을 전달하고 확률을 JSON 내의 수치로 출력하도록 했습니다. 이것은 토큰 생성 확률이 아니라, 모델 자체가 답변한 확률입니다. Clef가 직접 반환하는 확률과는 취득 방법이 다릅니다. GPT-5.4는 reasoning_effort=none으로 측정된 값이며, 추론을 사용했을 경우의 성능을 나타내는 것은 아닙니다.

마크로 평균은 7개 태스크의 지표를 단순하게 평균한 값입니다. AUROC와 Accuracy를 포함하므로, 태스크별 결과와 함께 확인해 주세요.

6개의 이진 분류 태스크를 같은 눈금으로 나열했습니다. 막대의 길이는 AUROC를 나타내며, 클수록 정예(Positive) 사례를 부적(Negative) 사례보다 높게 순위화할 수 있음을 의미합니다. 점 추정의 비교이며, 차이의 통계적 유의성은 검증하지 않았습니다.

ANLI R3은 3클래스 분류의 정답률입니다. AUROC와는 지표가 다르므로 별도의 그림으로 만들었습니다.

LLM도 나열해 보면, HaluEval QA에서는 GPT-5.4와 Claude Sonnet 4.6이 Clef를 능가했고, ANLI R3에서는 두 LLM 모두 Jev를 능가했습니다. 한편, BeaverTails에서는 Clef의 점 추정이 5개 모델 중 가장 높았습니다. 판정 모델인지 채팅 모델인지만으로는 결정되지 않으며, 태스크에 따라 우세한 모델이 달라집니다.

Clef는 ToxicChat, BoolQ, Prompt Injection에서 Jev와의 차이가 작았고, BeaverTails에서는 점 추정으로 약간 능가했습니다. 안전성 분류나 이진 라우팅(Binary Routing)을 시도해 볼 후보가 됩니다.

ANLI R3과 HaluEval QA에서는 Jev와의 격차가 벌어지고 있습니다. 특히 Clef-Flash의 HaluEval QA는 AUROC가 0.329였습니다. 무작위로 순위를 매긴 경우인 0.5보다 낮습니다.

HaluEval QA에서, 환각을 간파했는가

HaluEval은 문장에 포함된 할루시네이션(hallucination)을 찾아낼 수 있는지 조사하는 벤치마크입니다. QA에서는 근거 정보와 질문에 대해 올바른 내용과 환각이 포함된 내용을 준비했습니다. 여기서는 근거와 다른 정보나 근거가 없는 정보를 '환각'으로 판정합니다.

이번에는 모델에게 답변을 생성하게 한 것이 아닙니다. 준비된 내용을 하나씩, 근거와 함께 전달했습니다. 그리고 이에 대해 '이 내용에 환각이나 근거 없는 정보가 포함되어 있는가'라고 질문하고 있습니다. 300문제에 각각 두 종류의 내용이 있기 때문에, 올바른 내용 300건과 환각을 포함하는 내용 300건, 총 600건입니다.

Jev의 저장된 데이터까지 포함하여, 세 모델의 문제 ID와 정답 레이블은 600건 모두 일치했습니다. 각 모델이 반환한 것은 내용 한 건당 '이 내용에 환각이 있다'는 확률입니다. 이하에서는 '환각 있음'의 확률이라고 부릅니다. 이것은 정답일 확률이 아니기 때문에, 올바른 내용에는 낮은 값을, 환각을 포함하는 내용에는 높은 값을 반환하는 것이 바람직합니다.

'환각 있음'의 확률은 어디에 분포했는가

평균값만으로는 모델이 반환한 확률의 분산(ばらつき)을 알 수 없습니다. 그래서 올바른 내용과 환각을 포함하는 내용을 나누어, 건별 '환각 있음'의 확률을 분포도(分布図)로 만들었습니다.

가로축은 모델이 반환한 '이 내용에 환각이 있다'는 확률 구간이고, 세로축은 그 구간에 들어간 내용의 건수입니다. 확률을 0.1 간격으로 나누고, 같은 구간의 두 개를 나란히 배치했습니다. 각 구간에서 왼쪽 점선 막대는 올바른 내용을, 오른쪽 색상 막대가 환각을 포함하는 내용을 나타냅니다. 막대를 좌우로 나눈 것은 입력 종류를 구분하기 위함이며, 두 개 모두 같은 확률 구간을 집계하고 있습니다. 입력은 각각 300건이고, 세 모델의 눈금은 공통입니다.

올바른 내용의 점선 막대가 낮은 확률 구간에, 환각을 포함하는 내용의 색상 막대가 높은 확률 구간에 모일수록, 두 가지를 구분하기 쉽다는 것을 알 수 있습니다. 점선으로 표시된 0.5를 판정 경계로 한다면, 0.5 이상의 구간에 있는 점선 막대는 오판정(誤判定)이고, 0.5 미만의 구간에 있는 색상 막대는 놓침(見逃し)에 해당합니다.

Jev는 올바른 내용이 낮은 확률 쪽에, 환각을 포함하는 내용이 높은 확률 쪽에 많이 모여 분포했습니다. Clef도 올바른 내용에는 낮은 확률을 반환하고 있지만, 환각을 포함하는 내용에 대한 확률은 넓게 분산되어 있고, 0.5 미만인 경우도 많았습니다.

Clef-Flash는 올바른 내용에도 높은 '환각 있음'의 확률을 반환하고 있습니다. 환각을 포함하는 내용의 분포와도 겹치고 있으며, 올바른 내용을 강하게 의심하는 경향이 보입니다. 이는 준비된 내용에 대한 판정 결과일 뿐이며, Clef-Flash 자체가 환각을 생성했다는 의미는 아닙니다.

부가 설명: 모델이 반환한 '환각 있음' 확률의 평균

분포를 평균값으로 요약하면 다음과 같습니다.

이 표는 모델이 반환한 '환각 있음' 확률의 평균이며, 정답률이나 탐지율(検出率)이 아닙니다. 예를 들어 Clef-Flash의 0.569는 환각을 포함하는 내용 300건에 대해 반환된 '환각 있음' 확률을 평균하면 56.9%였다는 의미입니다. '56.9%의 내용에서 환각을 찾아낼 수 있었다'는 의미가 아닙니다.

Clef의 평균 0.486도, 각 건의 확률이 0.5 근처에 모여 있었다는 것을 의미하지 않습니다. 분포도에서는 낮은 값부터 높은 값까지 넓게 분산되어 있습니다. 평균이 가깝더라도, 판정 경향은 같지 않을 수 있습니다.

부가 설명: 확률 0.5 이상을 '환각 있음'으로 판정한 경우

그렇다면 실제로 몇 건을 '환각 있음'으로 판정한 것일까요? 설명을 위해, 모델이 반환한 '환각 있음'의 확률이 0.5 이상이면 '환각 있음', 0.5 미만이면 '환각 없음'으로 하는 공통 기준에 따라 다시 계산했습니다. 다음 표는 평균 확률이 아니라, 판정된 건수와 각 300건에 차지하는 비율입니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

판정 건수는 임계값에 따라 달라집니다. 0.5는 최적화된 값이 아니며, 이전 표의 AUROC와는 다른 관점입니다. 프롬프트 조정이나 few-shot 예시 추가도 진행하지 않았습니다. 이 결과만으로 환각 탐지 전반을 평가해서는 안 되며, 사용하려는 데이터로 오판과 놓침 모두를 확인해야 합니다.

왜 HaluEval QA에서 차이가 났는가

지금까지의 결과를 보면 'Clef가 환각 탐지에 서툰 것 아닌가'라고 생각하기 쉽습니다. 하지만 공개 정보를 조사해 보면 그것만으로는 설명할 수 없습니다.

공식 모델 카드에는 다른 환각 탐지 벤치마크인 RAGTruth의 결과도 실려 있습니다.

그렇다면, 이번 차이는 어디서 왔을까요? 아래는 공개된 모델 구성과 이번 결과로부터 추론한 가설입니다. 원인을 특정하기 위한 추가 실험은 아직 진행되지 않았습니다.

가설 1: 학습한 판단과 이번 QA의 조건이 다르다

Cloudflare의 학습 방법 설명에 따르면, 내부 합성 데이터를 사용하고 기반 모델(Foundation Model)의 가중치를 고정하며, 저랭크 어댑터와 판정용 헤드(Head)를 학습시키고 있습니다. 확률 조정에는 Brier loss도 사용했습니다. 다만, 확인한 공개 자료에서는 환각 탐지용 데이터의 내역이나 HaluEval QA 같은 문제의 비율은 알 수 없었습니다.

반면, HaluEval QA는 HotpotQA에서 유래된 올바른 답변에 대해 ChatGPT로 환각을 포함하는 답변을 만들고, 가장 그럴듯하게 구별하기 어려운 것을 선택하는 방식으로 만들어졌습니다. '문장으로서 그럴듯한가'가 아니라, '주어진 근거로 그 내용을 뒷받침할 수 있는가'를 확인해야 합니다.

학습된 판정 경향이 이 조건과 맞지 않아, 그럴듯함이나 답변 작성 방식에 영향을 받았을 가능성은 있습니다. 하지만 오판 사례를 점검하지 않았기 때문에 이는 가설입니다. '환각 탐지를 학습하지 않았다'고까지는 말할 수 없습니다.

가설 2: 질문문이나 true / false의 의미에 민감했다

이번 질문은 답변에 환각이나 근거 없는 정보가 포함되어 있는지 물어본 후, 근거와 완전히 일치하지 않는지라는 부정형으로도 바꿔 표현했습니다. noul

은 true 측의 확률을 반환하기 때문에, 실험에서는 이를 '환각 있음'의 확률로 읽었습니다.

API 형식이 호환되더라도, 각 모델이 이 질문을 동일하게 해석했다고 보장할 수 없습니다. 부정형을 피하거나, true / false 각각의 판정 기준을 명시하는 등의 변경으로 결과가 달라질 가능성이 있습니다.

특히 Flash는 올바른 내용에 높은 '환각 있음' 확률을 반환했습니다. 답변의 정확성과 환각 유무를 혼동하고 있지는 않은지, 입력과 반환값의 대응까지 포함하여 확인하고 싶습니다. 다만, 확률을 역전시킨다고 해서 반드시 맞는 근거가 되는 것은 아닙니다. 평가 결과를 보고서 편하게 레이블을 뒤집는 것이 아니라, 다른 검증용 데이터로 질문 해석을 확인해야 합니다.

가설 3: Flash의 모델 구성으로는 근거와의 대조가 어려웠다

Clef의 기반 모델은 Qwen3.8-27B이고, Flash는 Qwen3.5-9B입니다. 규모뿐만 아니라 기반 모델도 다릅니다. 둘 다 내부 표현을 판정용 헤드로 읽어 선택지별 확률을 계산하는 구성입니다.

근거와 답변의 미세한 차이를 포착하는 능력에서 이러한 차이가 영향을 주었을 수 있습니다. 공식 RAGTruth에서도 Flash의 성적이 낮기 때문에, HaluEval QA만의 문제는 아닐 수도 있습니다. 하지만 이번 HaluEval Dialogue에서는 Flash의 AUROC가 0.807이었습니다. 환각 탐지 모든 영역에서 동일하게 실패하고 있는 것은 아닙니다.

모델 규모, 기반 모델, 추가 학습을 분리하여 실험한 것이 아니기 때문에, '작아서' 또는 '추론 논문을 생성하지 않아서' 원인을 단정할 수는 없습니다. 더욱이, 속도를 희생하면서 환각 탐지를 포기했다고까지는 이 실험만으로는 말할 수 없습니다.

임계값 조정으로 해결될 문제인가

Clef의 HaluEval QA는 AUROC가 0.856이므로, 환각을 포함한 내용에 높은 확률을 부여하는 경향 자체는 남아 있습니다. 0.5라는 공통 임계값이 이번 데이터에 적합하지 않았을 가능성도 있습니다. 다만, 낮추면 탐지율도 올라가지만, 올바른 내용을 오판할 확률도 늘어나므로 용도에 따라 양쪽을 확인하고 싶습니다.

반면, Flash의 AUROC는 0.329입니다. 단순히 확률이 너무 높다는 것뿐만 아니라, 올바른 내용과 환각을 포함한 내용의 순위 지정에도 문제가 보입니다. 임계값을 움직이는 것만으로는 순위가 바뀌지 않습니다. 확률의 순위를 유지하는 보정으로도 이 AUROC 문제는 해소되지 않습니다.

우선은 오판 사례를 근거・질문・판단 대상 내용을 3가지 관점에서 다시 읽어보고 싶습니다. 그 위에 질문 문구나 판단 기준을 바꾼 경우에도 같은 경향이 나타나는지 다른 데이터로 확인하고 싶습니다. '거짓을 간파할 수 없다'고 끝내기보다는, 어떤 조건이라면 신뢰할 수 있을지 찾아볼 여지는 있어 보입니다.

속도 비교에는 별도의 검증이 필요함

Cloudflare의 공식 발표에서는 Clef와 Clef-Flash가 Jev보다 빠하다고 보고되었습니다. 이 기사에서는 그 속도 차이를 검증하지 않았습니다.

Jev는 2026년 9월, Clef와 Clef-Flash는 10월 6일에 측정했습니다. Clef의 두 모델은 OpenRouter를 통해 호출하고 있습니다. 측정 시기와 연결 경로가 일치하지 않기 때문에, 기록된 응답 시간만으로는 모델 자체의 속도 우열을 판단할 수 없습니다. API 응답 시간에는 통신이나 서버 측 대기 시간도 포함됩니다.

다음으로 먼저 확인하고 싶은 것은 사용자 관점의 API 응답 시간입니다. Clef와 Clef-Flash는 Cloudflare Workers AI 공식 API로 호출할 수 있으므로, 이 검증에 자체 GPU가 필요하지 않습니다. Jev 역시 공식 API를 사용하며, 동일한 클라이언트에서 같은 기간에 측정하는 방법을 고려하고 있습니다. 입력, 동시 실행 수, 워밍업을 맞추고, 호출 순서를 바꿔가며 반복적으로 측정하여 중앙값과 p95, 오류율을 확인할 것입니다.

다만, 공식 API 간에도 서버 환경은 다릅니다. 알 수 있는 것은 각 서비스의 응답 시간이며, 모델만의 추론 속도는 아닙니다. 추론 자체를 비교하려면 GPU, 수치 정밀도, 입력 길이, 배치 크기 등을 맞춘 실행 환경이 필요합니다. Clef는 공개된 가중치를 자체 또는 클라우드 GPU에 올릴 수 있지만, 그것만으로는 Jev와 동일한 환경의 비교가 가능하지 않습니다.

공식 속도 차이를 재현하려면, Cloudflare가 사용한 입력이나 측정 구간, 제공 환경의 상세 내용도 확인해야 합니다. Hugging Face에 기재된 동작 확인 환경이 그대로 속도 측정 환경이었는지 확인할 수는 없었습니다. 이번에는 거기까지 깊이 파고들지 않고, 먼저 판단 정확도를 검증하겠습니다.

용도에 맞춰 선택하기

이번 7가지 태스크에서는 Clef의 판단 정확도가 모두 Clef-Flash를 능가했습니다. 다만, 27B와 9B 간의 정확도 차이는 태스크별로 다릅니다. ToxicChat이나 BoolQ의 차이는 작고, HaluEval QA에서는 판단 경향도 달라지고 있습니다.

HaluEval QA나 ANLI에 가까운 용도에서는 소량의 실제 데이터로 평가한 후 선택해야 합니다. 이미지 포함 판별에 사용할 경우에도 Clef의 멀티모달 입력을 별도로 평가해 주십시오.

이번 평가 범위

이번 비교는 텍스트 입력만을 사용했으며, 태스크별로 한 종류의 질문 문구를 사용하여 점 추정했습니다. 프롬프트 최적화, few-shot, 이미지 입력, 통계적 유의성 검정은 진행하지 않았습니다. 또한, 공개 벤치마크와 학습 데이터가 중복되는 것도 부정할 수 없습니다.

OpenRouter 모델 페이지에는 기사 작성 시점의 Workers AI 경로에서는 긴 state가 약 2K 토큰으로 잘리는 주의사항이 있습니다. 이번 입력은 그보다 짧은 범위에 포함시켰습니다. 장문을 판단할 때는 연결처의 제한을 확인해 주십시오.

Clef는 Jev 호환 API로 테스트할 수 있을 뿐만 아니라, 공개된 가중치(weights)를 사용할 수도 있습니다. 기존의 판별 처리 과정에 통합할 때는 평균값만으로 결정하지 말고, 실제로 판별하고 싶은 데이터로 정확도를 확인하는 것이 좋을 것 같습니다.

관련 기사로는 Jev가 망설일 때 누구에게 물어볼까?──7가지 벤치마크 비교를 통해 생각하는 LLM 배분(assignment)도 공개했습니다.

이번에는 먼저 Clef가 어떤 판단에 능숙한지 정확도를 통해 살펴보았습니다. 다음으로 궁금한 것은 실제 애플리케이션에서 사용했을 때의 대기 시간입니다. 다음 회차에서는 공식 API를 사용하여 조건을 맞추고, 정확도뿐만 아니라 응답 속도까지 포함하여, 어떤 상황에서 사용하고 싶어지는 모델인지 확인해 보고자 합니다.

Discussion