무엇을 재야 믿을 수 있나 — 구간 기록·품질 지표·실패율·관문

한 줄 요약

음성 비서의 한 턴은 여러 단계를 거치고, 각 단계는 따로 느려지고 따로 실패한다. 그래서 턴마다 추적(trace) 하나, 단계마다 구간(span) 하나를 남기고, 모든 지표 — 단계별 지연 분포, WER, 응답 품질, 실패율 — 를 그 같은 원자료에서 계산한다. 오류율과 사용자가 겪은 실패율은 다른 숫자이고, 근거 검사를 통과한 오답은 정답표로만 보인다. 마지막으로 기준 판보다 나빠졌으면 배포를 막는 관문을 둔다.

왜 이게 필요했나

'평균 응답 1.2초, 잘 됨' 같은 보고는 세 가지를 숨긴다. 어느 단계가 느린지(분포와 단계), 어떤 턴이 실패했는지(실패의 종류), 그리고 답이 맞았는지(품질). 앞 모듈들에서 본 대로 이 파이프라인은 근거 검사를 통과한 오답을 낸다(모듈 5) — 토요일 질문에 평일 시간을 답해도 숫자가 문서에 있으니 통과한다. 지연과 오류만 재는 대시보드에서는 이 오답이 '성공' 으로 집계된다.

어떻게 동작하나

추적과 구간. OpenTelemetry 의 모양을 따른다 — 구간마다 trace_id·span_id·parent_id·이름·시작·끝·상태·속성. 턴 하나가 뿌리 구간(turn) 하나와 자식 구간(asr·retrieve·llm·verify·tts)을 갖는다. 속성에는 확정 글, 찾은 문서, 답, 출처를 담는다. 이 원자료 하나에서 지연 분포(구간 길이), WER(asr 구간의 글 대 정답), 품질(뿌리 구간의 답 대 정답표), 실패율(상태)이 모두 나온다. 지표마다 따로 로그를 남기면 서로 다른 턴을 세게 되어 숫자끼리 맞지 않는다.

WER 다시 보기. 합성 전화 질의 12개에서 이 파이프라인의 ASR WER 은 20% 가까이였다(모듈 3 의 LibriSpeech 에서는 1% 남짓). 같은 모델이다. 평가 자료가 서비스와 닮아야 하는 이유가 숫자로 보인다.

품질 지표 셋. (1) 사실 정확도 — 답이 있는 질문에서, 답에 정답 사실('9 a.m.', '$80' …) 가운데 하나가 들어 있는가. (2) 거절 정확도 — 답이 없는 질문을 거절했는가. (3) 근거 일치율 — 말한 답의 숫자가 인용 문서에 있는가. 이 파이프라인은 거절 정확도 100%, 근거 일치율 100% 인데 사실 정확도는 50% 였다(클러스터 nuc1 노드에서 잰 값). 같은 모델·같은 시드·temperature 0 인데 맥(arm64)에서는 30% 였다 — CPU 가 다르면 부동소수 계산 순서가 달라져 0.5B 모델의 답이 몇 개씩 바뀐다. 그래서 여러분의 실행에서 다시 재고, 기준 판도 같은 노드 종류에서 만든다. 0.5B 모델이 문서의 다른 숫자를 옮기거나, 검사에서 떨어진 답을 대신한 추출 문장이 질문을 비껴가기 때문이다. 근거 일치는 정확함이 아니다.

오류와 실패는 다르다. 단계 셋을 일부러 실패시켜 보면 분명해진다. ASR 이 빈 글을 내면 사용자는 '다시 말해 주세요' 를 듣는다(재질문 — 사용자 실패). LLM 이 시간 초과를 내도 검색한 문단의 문장을 읽어 주면 사용자는 답을 듣는다(한 단계 낮춘 응답 — 오류지만 실패는 아님). TTS 가 실패하면 사용자는 침묵을 듣는다(실패). 오류가 난 턴 3개 중 사용자 실패는 2개였다. 대시보드에 오류율만 두면 '조용히 잘 넘긴 오류' 와 '사용자를 버린 오류' 를 구별할 수 없다.

SLO 와 관문. SLO(서비스 수준 목표)는 사용자가 겪는 것으로 적는다 — 예: 첫 소리 p95 2.5초 이하, 사실 정확도 0.6 이상, 사용자 실패율 5% 이하. 측정과 비교해 통과·미달을 판정한다. 관문(gate)은 한 걸음 더 나아가 기준 판보다 나빠졌는가 를 본다. 지표마다 방향과 허용 폭이 다르다 — WER 과 실패율은 오르면 나쁘고(절대 폭), 사실 정확도는 내리면 나쁘며, 지연은 기계마다 흔들리므로 비율(예: 20%)로 본다. 관문도 코드이므로 막아야 할 것을 넣어 보고 빨간불이 켜지는지 시험한다.

현장에서 만나는 모습

평가 자료는 작게 시작해 사고마다 늘린다. 이 코스의 정답표는 질의 12개에 손으로 단 정답 문서와 사실뿐이다. 그래도 사실 정확도가 절반 남짓이라는 것, 근거 일치율 100% 가 그것을 가린다는 것을 보여 주기에는 충분하다. 운영에서는 실제 통화에서 넘겨진 턴(handoff)과 재질문 턴을 표본으로 뽑아 정답표에 더해 간다. LabHub 저장소가 게이트를 새로 만들 때마다 '막으려는 것을 넣어 보고 빨간불이 켜지는지 확인하라' 고 적어 둔 것(AGENTS.md)도 같은 원칙이다.

지연 지표는 기계를 탄다는 점도 기록에 남긴다. 같은 파이프라인이 노드의 CPU 에 따라 수십 퍼센트 다르게 걸린다. 그래서 관문에서 지연은 같은 기계에서 잰 기준과 비교하거나 비율로 보고, 기준 판의 지표에 '어디서 쟀는가' 를 함께 적는다. 절대 문턱 하나로 판정하면 느린 노드에서 돌린 날마다 가짜 퇴행이 난다. 반대로 품질 지표(WER·사실 정확도)는 기계를 타지 않으므로, 같은 입력·같은 시드로 다시 돌리면 같은 숫자가 나와야 한다 — 다르게 나오면 그것 자체가 조사할 사건이다.

다음 실습에서 할 것

기준 파이프라인에 구간 기록을 걸어 질의 12개를 추적으로 남긴다. 같은 원자료에서 단계별 p50/p95, WER, 사실·거절 정확도와 근거 일치율을 계산한다. 단계 셋을 실패시켜 오류 턴과 사용자 실패를 가르고, SLO 를 정해 판정한다. 기준 판 대비 퇴행을 막는 gate.py 를 만들어 숨긴 사례로 시험받고, 이번 판의 지표로 관문을 돌린다.