← Docs hub

Cloud Rewrite Query Quality Guide

이 문서는 Cloud LLM의 rewrite_query를 어떻게 설계하고 검증해야 하는지 정리합니다. 핵심은 Case 2가 나왔다는 사실만으로 성공이 아니라는 점입니다. rewrite_query가 다시 온디바이스 로컬 파이프라인에 들어가 기대 <sk_xx> 토큰으로 매칭되어야 최종 성공입니다.

1. 소스 근거

2. Rewrite 성공 정의

Cloud rewrite 성공은 아래 조건을 모두 만족해야 합니다.

3. Rewrite 문장 작성 규칙

한국어

좋은 rewrite_query:
- 공기질 맵 히스토리 보여줘
- 배터리 확인해줘
- 온도 단위 섭씨로 바꿔줘
- 모든 동작 멈춰줘

나쁜 rewrite_query:
- 공기질 맵 히스토리를 확인하겠습니다
- 배터리 정보를 알려드릴게요
- 사용자가 공기질 맵을 보고 싶어 합니다

영어

Good rewrite_query:
- Check the air quality map history, please
- Check the battery, please
- Set the temperature unit to celsius, please
- Stop all actions, please

Bad rewrite_query:
- I will check the air quality map history
- The user wants to see the air quality map
- Air quality map history information

4. 온디바이스 딕셔너리 적합성 기준

rewrite_query는 사람이 보기 자연스러운 것만으로 부족합니다. 온디바이스 dictionary에 재매칭 가능한 형태여야 합니다.

5. 실패 패턴과 수정 방향

5-1. Cloud prompt/router 강화 판단 기준

Cloud 쪽을 고쳐야 하는 경우와 온디바이스 dictionary를 고쳐야 하는 경우를 분리해야 합니다.

Cloud prompt에 추가해야 하는 rewrite rule은 아래처럼 운영합니다.

1. 제품 기능 요청은 Case 2로 보낸다.
2. rewrite_query는 사용자가 다시 말할 법한 명령형 문장으로 작성한다.
3. rewrite_query에는 기능명, action, 필수 slot을 포함한다.
4. "I will", "I'll", "하겠습니다", "알려드릴게요" 같은 수행 완료 문장은 금지한다.
5. Malaysia RAG 문서가 있어도 제품 기능 실행 요청은 RAG 답변으로 끝내지 않는다.
6. rewrite_query 예시는 온디바이스 dictionary test positive case와 같이 관리한다.

변경 요청서에는 Cloud prompt 수정안만 쓰지 말고, 반드시 아래 근거를 같이 넣습니다.

원문 발화
originalSttResult
Cloud response case/function/available_function/rewrite_query
rewrite_query 로컬 재진입 결과
기대 token / 실제 token
Cloud 수정 필요 여부
Dictionary 수정 필요 여부

6. 테스트 매트릭스

7. 리포트 필수 필드

원문 발화:
originalSttResult:
Cloud request user content:
Cloud response raw:
case:
function:
available_function:
rewrite_query:
로컬 재진입 로그:
dictionary match 로그:
기대 token:
실제 token:
최종 TTS/API:
판정:
수정 대상:

8. 말레이시아 Custom RAG와의 경계

말레이시아 Custom RAG는 현지 고객센터, 보증, 앱 사용법, 국가별 제한 기능 같은 문서 기반 답변을 강화하는 경로입니다. 제품 기능 실행 요청을 RAG 답변으로 끝내면 안 됩니다.

수정 대상 분리 기준: