LLM 운영 해설서
이 문서는 Day 1~5 문서를 빠르게 대조하기 위한 운영 해설서입니다. 목적은 말레이시아 현지 운영팀이 발화 테스트 결과를 STT, 딕셔너리, On-device LLM, Cloud LLM, Device API, TTS, 상태관리 관점으로 분리해 판단하도록 돕는 것입니다.
공통 판단 원칙
문제가 발생했을 때 어느 단계에서 기대와 실제가 달라졌는지 먼저 찾는다.
단계별 기준:
| 단계 | 확인 값 | 판단 |
|---|---|---|
| 음성/STT | STT raw/originalSttResult | 사용 발화가 텍스트로 제대로 들어왔는지 |
| 전처리 | STT processed/filteredSttResult | 후처리나 치환이 의도를 바꾸지 않았는지 |
| 딕셔너리 | [DICTIONARY_MATCH] |
어떤 JSON 파일이 어떤 phrase로 토큰을 만들었는지 |
| 로컬 LLM | parsedLlamaResponse |
기대 <sk_xx>와 실제 token이 맞는지 |
| Cloud | API Response, case, rewrite_query |
일반 답변/기능 재해석/미지원 분류가 맞는지 |
| Validator | ApiCallValidator, errorcode |
정상 차단인지 기능 실패인지 |
| 기능 실행 | Device API input/output | On-device와 SoC/API 중 어디가 원인인지 |
| 사용자 응답 | ttsText, subtitle, screen |
기능 결과와 안내 문구가 사양과 맞는지 |
Day 1 해설: 제품 기능 사양 및 LLM 구조
제품 음성 기능은 STT 이후의 여러 판단 계층을 하나의 흐름으로 봐야 합니다.
사용자 음성
-> STT
-> On-device dictionary / On-device LLM
-> `<sk_xx>` 기능 토큰
-> ApiCallValidator
-> FunctionCallHandler
-> Device API
-> TTS/화면/상태 정리
Cloud LLM은 이 구조의 보조 경로입니다. Cloud가 직접 제품 기능을 실행하는 것이 아니라, 온디바이스에서 처리하기 어려운 발화를 다시 기능 발화 형태로 재작성하거나 일반 질문에 답변합니다.
운영 판단:
- 제품 기능 지원, 제품 설명/일반 질의, 미지원 기능을 먼저 구분합니다.
- 기능 실행은 token, Validator, Device API, TTS가 모두 맞아야 성공입니다.
- Cloud Case 2는 최종 성공이 아니라 온디바이스 재진입의 시작점입니다.
- 멀티턴과 Cloud continue 상태에서는 같은 발화도 단일 turn과 다르게 처리될 수 있습니다.
Day 2 해설: 온디바이스 딕셔너리 및 E2E Test
딕셔너리에서 가장 중요한 것은 “많이 넣는 것”이 아니라 “충돌을 줄이는 것”입니다.
파일별 기준:
| 파일 | 기준 |
|---|---|
mapping.json |
정확 발화 exact match |
contains.json |
입력 문장 내부 phrase 치환 |
contains_token.json |
기능명과 동작어 조합 매칭 |
3keyword_contains_token.json |
기능명/대상/동작어 3축으로 오매칭 방지 |
substitution_dict.json |
반복 STT 오인식 보정 |
말레이시아 현지 운영 기준:
- Kuala Lumpur, Selangor 같은 지역명은 제품 공간명과 섞지 않습니다.
- mall, office, apartment 같은 건물 표현은 청정 공간명으로 직접 실행하지 않습니다.
- living room, bedroom 같은 제품 공간명은 실제 등록 공간 목록과 대조합니다.
- 현지 별칭 공간명은 테스트 데이터로 관리하고, 없는 공간을 임의 실행하지 않습니다.
- 영어의
show,tell,check같은 짧은 동사는 단독 조건으로 쓰지 않습니다.
E2E 성능은 token 정확도만 보지 않고 STT raw 일치율, processed 보존율, 오매칭률, 미매칭률, Cloud fallback률, TTS 일치율을 함께 봅니다.
Day 3 해설: Cloud LLM 개선 작업 및 테스트
Cloud LLM 결과는 네 가지 Case로 판단합니다.
Case 1: 일반 답변
Case 2: 제품 기능 재해석, rewrite_query 반환
Case 3: 준비 질문 번호 반환
Case 4: 미지원 기능 안내
국내 프롬프트 구조는 Persona, Capabilities, Router, Anti-hallucination, Time/Weather, Output Contract 계층으로 나뉩니다. 말레이시아용 프롬프트도 이 구조를 유지하되 현지 서비스 문서, FAQ, 정책, RAG 문서셋을 분리합니다.
말레이시아 Custom RAG 기준:
- 현지 고객센터/보증/AS 정책은 Malaysia 문서셋을 근거로 답합니다.
- 앱 연결/초기 설정은 현지 앱 가이드 문서로 검증합니다.
- 제품 기능 실행 요청은 RAG 답변이 아니라 Case 2 또는 On-device 경로로 처리합니다.
- 근거 문서가 없는 현지 정책은 추정하지 않습니다.
- 연락처/요금/정책처럼 바뀔 수 있는 정보는 문서 버전 또는 Web Search 필요 여부를 기록합니다.
Day 4 해설: SQE/필드테스트 이슈 분석 및 개선 대응
필드 이슈는 먼저 원인 영역을 분리합니다.
| 원인 영역 | 대표 근거 |
|---|---|
| STT | raw가 발화와 다름 |
| 후처리 | raw는 맞고 processed가 다름 |
| 딕셔너리 | processed는 맞고 token이 다름 |
| Cloud | case/rewrite_query가 다름 |
| 기능 사양 | 기대 동작이 제품 사양과 다름 |
| Error Handler | token은 맞지만 Validator에서 차단 |
| Device API | API input/output 또는 기기 동작이 다름 |
| TTS/화면 | 기능은 맞지만 문구/화면만 다름 |
| 상태관리 | 멀티턴, resume, skipResume, Cloud continue 문제 |
협업 프로세스:
현지 운영팀이 로그와 1차 분류를 작성
-> On-device 담당이 dictionary/handler/validator/resource 확인
-> Cloud 담당이 prompt/case/rewrite/RAG 확인
-> SoC/API 담당이 Device API와 기기 상태 확인
-> 사양 담당이 지원/미지원 및 국가별 정책 확정
-> 수정 후 동일 발화와 주변 negative case 재검증
Day 5 해설: 말레이시아 현지 운영 기준
말레이시아 현지 운영은 테스트 수행보다 “반복 가능한 판단 기준”을 고정하는 것이 중요합니다.
기본 기준:
- 영어를 기본 검증 언어로 두고, 말레이시아 현지 표현은 별도 regression set으로 관리합니다.
- 한국 사양과 동일해 보여도 말레이시아 출시 모델/API 지원 여부를 확인합니다.
- Cloud prompt 구조는 유지하되 Malaysia Custom RAG 문서셋을 분리합니다.
- 이슈는 STT raw, processed, token, Cloud response, API input/output, TTS를 한 표에 기록합니다.
- 개선 요청은 증상이 아니라 어느 단계에서 기대와 실제가 달라졌는지를 기준으로 작성합니다.
최소 리포트 필드:
발화 원문:
언어:
앱/DB/브랜치:
STT raw:
STT processed:
기대 token:
실제 token:
Cloud response:
ApiCallValidator:
Device API input/output:
TTS/subtitle/screen:
재현 조건:
원인 분류:
개선 요청: