정확도를 측정하는 방법.

두 개가 아니라 하나의 방법론인 이유

WER 수치와 별도의 “환각률”을 서로 다른 페이지에 공개하고 싶은 마음이 들 수 있어요. 저희가 그렇게 하지 않는 이유는 둘이 중요한 것을 모두 공유하기 때문이에요. 같은 오디오, 같은 엔드투엔드 실행, 버전 관리되는 같은 코퍼스, 같은 공개 주기, 그리고 기준 정답을 승인하는 같은 검토자들이요. 두 페이지로 나누면 서로 독립된 두 프로그램처럼 보이지만, 실제로는 한 번의 실행에서 두 수치가 모두 나오고, 한쪽이 나빠지면 보통 다른 쪽에도 드러나요. 각 녹음은 프로덕션 파이프라인을 한 번 거치고, 그 한 번의 실행에서 나온 결과물이 아래의 모든 평가 계층에 쓰여요.

1. 1
   녹음 — 오디오 + 축어 기준 정답 + 사전 등록된 사실 목록, 저장소에 버전을 고정해 보관.
2. 2
   엔드투엔드 실행 — 의료진 가입, 환자 생성, 녹음, 문서 생성. 실제 사용자가 거치는 것과 같은 경로예요.
3. 3
   A 계층 — WER은 녹음된 녹취록을 기준 정답과 비교해요.
4. 4
   B 계층 — LLM 심사단은 생성된 문서를 사실 목록과 대조해, 호출 한 번에 사실 하나씩 원자 단위로 채점해요.
5. 5
   집계·공개 — 하나의 aggregate.json이 공개 투명성 페이지를 만들어요.

코퍼스

방법론을 적용하는, 버전이 고정된 녹음 세트예요. 각 녹음에는 축어 녹취록과, 생성된 기록에 들어가야 할 임상 요점(그리고 들어가면 안 되는 요점)을 직접 작성한 사실 목록이 짝지어져 있어요.

발전 로드맵

A 계층 — 단어 오류율

기계적 계층이에요. 단어 오류율은 오래 쓰여 온 음성 인식 지표로, 녹취된 내용과 실제로 말한 내용 사이의 대체, 삽입, 삭제 수를 기준 단어 수로 나눈 값이에요. 낮을수록 좋고, 0%는 녹취록이 기준 정답과 단어 하나까지 일치한다는 뜻이에요.

• 라이브러리. jiwer, 평가 도구 lockfile에 버전이 고정되어 있어 어떤 커밋에서든 같은 수치를 재현할 수 있어요.
• 정규화. 소문자 변환, 문장 부호 제거, 흔한 약어 풀어 쓰기(mg → milligram 등), 유니코드 NFKC. 정규화 규칙은 버전이 고정되어 있어, 겉모양만 다른 차이는 감점하지 않고 실제 오류만 감점해요.
• 신뢰 구간. 채점한 녹음을 부트스트랩 재표본추출해 대표 단어 오류율 옆에 공개해요. 이 지역의 공개 실행은 그 이전에 이뤄져서, 수치는 아직 점추정값뿐이에요.
• 코호트별 세부 내역. 전체와 코퍼스 태그별로 계산해요. 태그는 억양, 언어 변이, 오디오 환경처럼 각 녹음이 시험하도록 고른 조건이에요. 절대 수치가 상한값일 때도 코호트 간 편차가 곧 편향 신호예요.
• 녹음별 WER. 성능 저하가 평균에 묻히지 않고 특정 녹음까지 추적될 수 있도록 공개해요.

다른 제품과의 비교. 비교할 기준이 없어요. 앰비언트 AI 스크라이브 업체 대부분은 단어 오류율을 전혀 공개하지 않고, 공개하는 것으로 확인한 두 곳(Nabla 11.8%, Abridge 12.7%)은 공개하지 않는 내부 벤치마크로 측정하기 때문에 어느 수치도 재현하거나 확인할 수 없어요. WER은 같은 오디오, 같은 정규화 규칙에서만 비교할 수 있으므로, 저희 수치는 위에서 설명한 코퍼스, 녹음, 채점 방법과 함께 그 자체로 제시해요. 다른 업체도 같은 방식으로 공개한다면 환영해요. 그 전까지는 저희 수치와 다른 업체의 수치를 비교해도 큰 의미가 없어요.

솔직한 한계. 영향이 큰 대체(10mg → 100mg)와 영향이 작은 대체(okay → OK)는 원시 WER에서 똑같이 계산돼요. 그래서 B 계층이 있어요. 임상 내용이 맞는지는 토큰 수준의 WER만으로 알 수 없어요.

B 계층 — 포함률과 환각을 위한 LLM 심사단

질적 계층이에요. 생성된 임상 문서를 녹음의 사전 등록 사실 목록과 대조해, 여러 업체에서 고른 독립된 LLM 평가자 패널이 채점해요. 두 가지 속성을 따로 보고할 수 있도록 따로 측정해요.

모든 심사 위원이 보는 프롬프트 원문

시스템 프롬프트와 사용자 메시지 템플릿은 평가 도구 저장소(app/next/tests/accuracy/lib/juror.ts)에 버전이 고정되어 있고, 결과를 새로 고칠 때마다 이 페이지에 동기화돼요. 둘 다 아래에 원문 그대로 실어, 감사자는 요약이 아니라 모델이 받은 질문을 정확히 볼 수 있어요. 재실행과 패널 구성은 달라질 수 있지만, 프롬프트 틀 자체는 바뀌지 않아요.

원자 단위 단일 질문 호출

평가 도구가 심사단에 묻는 모든 판단은 사실 하나, 질문 하나, 호출 하나예요. 모델에게 기록 전체를 한 번에 채점하게 하면 개별 오류가 묻히고 “괜찮아 보인다”는 평균적인 판정이 나온다는 것은 잘 알려져 있어요. 원자 단위 호출은 감사도 가능해요. 누구나 판단 하나를 다시 실행해 심사 위원 세 명의 응답과 패널 판정을 모두 볼 수 있어요.

환각으로 보는 것

출력마다 심사단에 녹취록과 생성된 문서를 줘요. 심사 위원은 출력에서 녹취록이 뒷받침하지 않는, 즉 모델이 지어낸 임상적으로 의미 있는 주장을 모두 나열해요. 패널 결과는 심사 위원 간 합집합이며, 주장 문구 기준으로 중복을 제거해요. 대표 지표는 확정 표시, 즉 심사 위원 2명 이상이 표시한 주장만 세요. 심사 위원 1명만 표시한 항목은 출력별 상세 보기에 “잠정”으로 보여 주지만 대표 지표에서는 제외해요. 심사 위원 2명의 합의라는 기준 덕분에, 한 심사 위원이 지나치게 엄격하게 해석해서 생기는 위양성에 지표가 흔들리지 않아요.

녹취록에 근거하지만 기대 항목 목록에 없는 내용은 일부러 표시하지 않아요. detailsThatMustBeCaptured는 반드시 들어가야 할 항목의 목록이지 “문서에 들어갈 모든 내용”을 정한 계약이 아니에요. 목록에 없는 근거 있는 주장까지 모두 감점하면 위양성이 너무 많이 나왔어요. 특히 객관적 정보와 평가 섹션이 정당하게 필수 항목 이상을 담는 SOAP 형식 기록에서 그랬어요.

심사단 구성

여러 업체의 독립된 모델을 쓰므로 실패 양상이 서로 연관되지 않아요. 평가 도구는 특정 업체에 묶이지 않아, 지원되는 어댑터로 연결되는 모델이라면 어떤 것이든 패널에 들어갈 수 있고, 어댑터가 추가될수록 패널 규모도 커져요. 이 방식은 Replacing Judges with Juries(Verga et al., 2024, Cohere)로 공개되어 있어요. 임상 안전 맥락에서는 모델 하나를 믿는 것보다 독립된 여러 모델로 교차 확인하는 편이 더 깔끔한 결과를 내기 때문에 이 방식을 써요.

같은 업체 주의 사항. Gemini가 심사단에 참여할 수 있지만, 프로덕션 문서 생성 파이프라인도 Gemini를 쓰고, 같은 업체끼리 심사하면 맹점이 서로 연관될 수 있어요. 생성자로서 Gemini가 만든 지어낸 내용을 심사자로서 Gemini가 그럴듯하다고 볼 가능성이 더 높을 수 있다는 뜻이에요. 대응책은 운영 방식에 있어요. Gemini의 판정은 다중 업체 패널 판정과 따로 보고하므로, 독자는 Gemini만 판정했을 때와 다중 업체 패널이 판정했을 때를 비교해 볼 수 있어요. 패널이 N=1이고 그 한 명이 Gemini인 경우(예: 초기 개발 실행), 검증 보고서에 이를 명시해 독자가 그 수치를 과하게 해석하지 않도록 해요.

판정 규칙(패널 규모에 따라 달라짐)

보고서에는 녹음별 심사단 합의율, 즉 심사단이 만장일치였던 호출의 비율(N ≥ 2일 때)이 들어가요. 만장일치가 많으면 명확한 사례가 대부분이라는 신호이고, 불일치가 많으면 방법론이 어려운 영역에서 작동하고 있다는 신호예요. 둘 다 평가자에게 유용한 정보이지, 감출 결함이 아니에요.

심사 위원별 반복 후 투표

각 심사 위원을 temperature 0으로 R번 호출하고(기본 R = 3, 실행마다 설정 가능), 심사 위원의 표는 자신의 R개 응답 중 다수로 정해요. 이렇게 하면 심사 위원 한 명이 불안정한 응답을 내는 5–10%의 호출 문제가 사라져요. 비용은 판단당 N × R회 호출이지만, 사용하는 모델 등급은 생성 파이프라인에 비해 저렴하고, 편차를 줄이는 것이 핵심이에요. 빠른 개발 반복에는 R을 낮추고, 신뢰도 높은 공개 수치에는 R을 높여요.

보정과 평가자 간 일치도

• 보정 점검(평가 도구 버전마다). 직접 만든 누가 봐도 좋은 기록과 누가 봐도 나쁜 기록을 심사단에 돌려요. 심사단은 이 둘을 정확히 채점해야 해요. 그러지 못하면 실제 평가를 시작하기도 전에 방법론이 망가진 것이므로 평가 도구를 멈추고 조사해요.
• 사람과의 평가자 간 일치도(보고서마다). 녹음의 20% 부분 집합을 Clinical Lead가 독립적으로 채점해요. 그 부분 집합에서 심사단 판정과 임상 전문가 판정 사이의 Cohen's κ를 계산해 검증 보고서에 공개해요.

Cohen's κ는 감으로 보는 지표가 아니에요. 우연에 의한 일치를 통제해요. 이 지표를 넣으면 심사단이 “LLM을 믿어 달라”에서 “보고서마다 LLM을 의료진과 비교해 측정했다”로 바뀌어요.

C 계층 — 의미 변화 예정

원시 WER(토큰 수준)과 LLM 심사단(임상 내용 수준) 사이를 잇는 지표예요. 기준 녹취록과 생성된 문서를 같은 임베딩 모델로 임베딩하고, 코사인 유사도로 녹음별 변화 점수를 구해요. 재구성의 충실도를 포착해요. 문서는 원본을 요약하는 것이 목적이지만, 임상적 의미는 유지해야 해요. 녹음별 주석 없이 저렴하게 계속 측정할 수 있는 지표로 유용하고, 시간에 따른 추세도 쉽게 볼 수 있어요. 이상값(변화가 평균에서 N σ 초과)은 사람이 검토하도록 표시해요. 로드맵에 있으며, v1 공개 수치에는 포함되지 않아요.

반복 가능성

파이프라인이 평균적으로는 정확해도 일관성이 없을 수 있어요. 같은 오디오로 매번 다른 문서가 나온다면 흥미로운 현상이 아니라 임상 안전 문제예요. 코퍼스 녹음의 일부를 CI 실행마다 N번(기본 3번) 처리해요. 재실행마다 모든 평가 계층을 돌리고, 재실행 간 편차를 반복 가능성 점수로 삼아 대표 정확도 수치와 함께 보고해요.

보고 주기

재현성

• 모든 것을 버전 관리. 오디오 + 녹취록 + 사실 목록 + 심사 프롬프트 + 심사 모델 버전을 모두 저장소에 커밋해요. 어떤 커밋의 저장소 상태에서든 평가 도구를 다시 실행할 수 있어요.
• 스크립트 하나로 공개. 새 평가 실행은 스크립트 하나(transparency 디렉터리의 ./publish.sh)로 처음부터 끝까지 공개돼요. 평가 도구의 aggregate.json을 페이지 데이터 파일로 복사하고, 브라우저에서 재생할 수 있도록 오디오 파일을 rsync해요. 빌드 단계도, 프레임워크도, 편집 단계도 없어요.
• NDA 하에 공개, 이후 오픈소스. 기술 실사 기간에는 NDA 하에 HNZ에 평가 도구 코드를 공개하고, 장기적으로는 외부 감사자가 방법론 전체를 다시 실행할 수 있도록 오픈소스로 공개하는 것이 목표예요(목표: 배포 후 12개월).
• 가능한 범위에서 코퍼스 공개. v1(합성)과 v2(역할극, 연기자 공개 동의) 코퍼스는 오픈소스로 공개할 수 있어요. v3(동의 기반 실제) 녹음은 PHI 최소화 후에도 PHI 민감성 때문에 제한된 상태로 유지돼요. 코호트별 집계 수치는 공개하지만, 원본 오디오와 녹취록은 공개하지 않아요.

통계 방법론

지루하지만 근거가 탄탄해요. 이 항목들을 명시하면 모든 보고서가 “평가 도구를 돌렸다”에서 “이 방법으로 평가 도구를 돌렸고, 다른 사람도 재현할 수 있다”로 바뀌어요.

비교 벤치마크: Claude 심사단

2026년 10월, 저희는 같은 코퍼스 녹음 13개를 Hanah와 다른 AI 스크라이브 6개(Heidi, Lyrebird, Freed, PatientNotes, CliniScripts, Preve)에 돌리고, 모든 녹취록, 기록, 채점 결과를 벤치마크 페이지에 공개했어요. 이 비교의 기록은 Claude 심사단이 채점해요. 투명성 페이지의 릴리스 보고서는 B 계층에서 설명한 패널이 채점해요.

녹음

각 AI 스크라이브는 Chrome에서 자체 웹 앱으로, 기본 설정의 일반 계정에 로그인한 상태로 실행했어요. 녹음은 브라우저의 마이크 입력으로 재생했고, 모든 스크라이브에 같은 파일을 썼어요. 각 녹음의 프롬프트는 스크라이브의 문서 기능이나 채팅 기능에 한 글자도 바꾸지 않고 입력했어요. 각 스크라이브는 녹음마다 한 번씩, 모두 2026년 10월 6일에 실행했어요. 단어 오류율은 각 스크라이브의 최종 녹취록으로 A 계층과 똑같이 계산해요.

블라인드 채점

녹음마다 각 프롬프트에 대한 모든 스크라이브의 출력을 기준 녹취록, 체크리스트와 함께 하나의 묶음에 넣었어요. 출력은 문자(A~G) 뒤에 무작위로 섞고, 본문에서 제품 이름을 지웠어요. Anthropic의 모델인 Claude가 기준 녹취록만을 기준으로 각 묶음을 채점했어요. 문자와 제품의 대응표는 녹음 13개의 채점이 모두 끝난 뒤에 열었어요.

채점 기준

일관성 규칙

• 이름을 소리 나는 대로 적은 것은 녹취 오류로, 단어 오류율에 반영해요. 약물 이름이 틀리면 중대한 환각 표시예요.
• 말한 내용을 표준 임상 용어로 바꿔 적은 것은 표시하지 않아요. 예를 들어 pH 7.26, lactate 4.3을 대사성 산증으로 적은 경우예요.
• 프롬프트가 평가를 요청할 때, 말한 소견을 의료진이 말한 감별 진단과 연결하는 것은 표시하지 않아요.
• 시스템이 넣는 머리글 내용은 표시하지 않아요: 진료 날짜, 환자 기록 이름, 의료진의 이름·직종·클리닉.
• 지어낸 중재, 조언, 제한 사항, 의뢰, 검사, 모니터링 지시, 관리 결정은 주요 표시예요. “다음 진료 때 재평가” 같은 일반적인 문구는 경미한 표시예요.

녹취록

각 녹취록은 축어 기준과 단어 단위로 정렬하고, 군말 차이는 제외해요. 남은 차이는 Claude가 블라인드로 판단해요. 임상적으로 중요한 녹취 오류는 진단, 치료, 후속 관리, 안전, 기록에 대해 의료진을 오도할 수 있는 오류로, 틀린 약물·용량·숫자·부위·증상, 빠진 부정 표현이나 위험 신호, 누락된 임상 내용 등이에요. 단어 오류율은 A 계층과 같이 계산하되, 같은 뜻의 다른 표기(22 mm와 22 millimetres, 미국식과 영국식 철자, 한자 숫자와 아라비아 숫자, 간체자와 번체자)는 같은 단어로 봐요. 중국어는 글자 단위로 채점해요.

언어 설정

대부분 표준 중국어로 진행한 재평가 진료의 경우, 입력 언어 설정을 제공하는 스크라이브는 모두 표준 중국어로 설정했어요. Heidi는 English and Chinese (Mandarin), Lyrebird와 PatientNotes는 Chinese (Mandarin, Simplified)로요. CliniScripts는 중국어와 영어를 선택했을 때 두 번 시도해도 녹취록을 만들지 못해 기본 설정을 썼어요. Preve는 입력 언어 설정이 없고, Freed와 Hanah는 언어를 스스로 감지해요. Heidi와 Hanah는 이 진료를 각각 세 번 실행했고, 녹취록 결과는 평균을 냈어요.

점수

포함된 임상 세부 사항은 각 녹음의 첫 번째 프롬프트에 대한 임상 체크리스트 항목에서 예를 1, 부분을 0.5, 아니요를 0으로 채점해요. 환각 표시는 같은 기록에서 세요. Preve는 템플릿을 만들 샘플 PDF를 업로드해야만 맞춤 지시를 따르기 때문에, Preve의 기본 임상 기록을 같은 임상 항목으로 채점해요. 중요한 녹취 오류는 진료마다 세요. 업계 수치는 다른 스크라이브 6개의 평균이에요. 모든 판정과 환각 표시는 이유와 함께 벤치마크 페이지에 공개해요.

참고 문헌

• Verga, P. et al. (2024). Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models. Cohere. B 계층에서 쓰는 LLM 패널(PoLL) 심사단 방식의 공개 근거.
• Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. 심사단 방식이 해결하는 단일 심사 모델의 한계를 정리.
• Cohen, J. (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement. 심사단과 의료진 간 일치도에 쓰는 κ 통계량.
• Fleiss, J. L. (1971). Measuring Nominal Scale Agreement Among Many Raters. Psychological Bulletin. 심사 위원별 일관성 확인에 사용.
• jiwer — WER과 관련 지표를 위한 오픈소스 Python 라이브러리, 평가 도구 lockfile에 버전 고정.