1. 배경: 두 번째 발화부터 검색이 실패하는 문제
KT 유선가입 에이전트에서 상품과 요금을 안내하다 보면, 첫 질문은 대체로 온전합니다. 문제는 두 번째부터입니다.
사용자: A 상품 조건이 어떻게 되나요?
봇 : (A 상품 안내)
사용자: 그럼 그거 얼마예요? ← 그대로 검색할 경우"그럼 그거 얼마예요?"를 검색 엔진에 넣으면 아무것도 나오지 않습니다. 의미 있는 단어가 하나도 없기 때문입니다. 사람은 앞 대화를 기억하니까 알아듣지만, 검색은 그 문장만 봅니다.
2. 문제 정의: 후속 질문의 생략 구조
실제 대화 로그를 분석해보니 후속 질문의 상당수가 이런 형태였습니다.
- 지시어로 대체 "그거", "저건", "아까 그"
- 주어 생략 "얼마예요?", "언제부터죠?"
- 조건만 추가 "더 싼 건 없어요?", "약정 없이는요?"
- 비교 요청 "둘 중에 뭐가 나아요?"
전부 앞 대화 없이는 성립하지 않는 문장입니다. 그대로 검색하면 검색 결과가 비거나 엉뚱한 문서가 나오고, 그러면 LLM이 근거 없이 답을 지어냅니다. 검색 실패가 환각으로 이어지는 경로였습니다.
3. 기술적 난점
단순히 "앞 대화를 붙이면" 될 것 같지만 그렇지 않았습니다.
전체 히스토리를 붙이면 노이즈가 됩니다. 대화가 길어지면 이전에 언급됐다가 폐기된 주제까지 딸려옵니다. 사용자가 A를 보다가 B로 옮겼는데 히스토리에 A가 여러 번 있으면, 재작성된 질의에 A가 섞여 들어갑니다.
무엇을 이어받을지가 경우마다 다릅니다. "그거 얼마예요?"는 앞의 대상을 이어받아야 하지만, "약정 없이는요?"는 앞의 대상을 유지하면서 조건을 추가해야 합니다. "다른 건 없어요?"는 앞의 대상을 제외해야 합니다. 같은 후속 질문이라도 처리 방향이 반대입니다.
그리고 가장 위험한 문있었습니다. 재작성 과정에서 LLM이 원문에 없던 것을 넣거나 있던 것을 빠뜨렸습니다.
원문 : "무약정으로 가능한가요?"
재작성: "약정 조건이 어떻게 되나요?" ← '무'가 사라짐. 의미가 반대부정형이 날아가면 정반대의 결과를 검색합니다. 숫자나 날짜가 미묘하게 바뀌는 경우도 있었습니다. 재작성이 도움이 아니라 오염이 되는 상황이었습니다.
4. 대안 검토
1안. 히스토리를 통째로 컨텍스트에 넣는다
재작성 없이 검색 단계에 이전 대화를 함께 제공합니다.
- 장점: 구현이 간단합니다.
- 단점: 검색 품질이 나빠집니다. 검색은 질의가 짧고 명확할 때 잘 동작하는데, 긴 대화를 넣으면 핵심 단어가 묻힙니다. 토큰도 늘어납니다.
2안. LLM에게 한 번에 재작성시킨다
"앞 대화를 참고해 이 질문을 독립적인 질문으로 바꿔줘"라고 시킵니다.
- 장점: 자연스럽게 잘 동작하는 경우가 많습니다.
- 단점: 위에서 본 왜곡이 일어납니다. 그리고 왜 그렇게 바꿨는지 통제할 수 없어서, 틀렸을 때 고칠 방법이 프롬프트 수정밖에 없습니다.
3안. 유형을 나누고 단계적으로 재작성합니다
후속 질문을 유형별로 판별한 뒤, 유형에 맞는 방식으로 문맥을 복원합니다. 그리고 왜곡을 막는 검증을 붙입니다.
- 장점: 처리 방향을 통제할 수 있고, 실패 지점을 특정할 수 있습니다.
- 단계가 늘어 복잡해집니다.
5. 설계 결정 및 근거
3안을 골랐습니다. 2안의 편의보다 통제 가능성이 중요했습니다. 상용 서비스에서는 "대체로 잘 되지만 가끔 반대로 검색합니다"를 받아들일 수 없었습니다.
후속 질문의 유형 분류
재작성하기 전에 이 후속 질문이 어떤 종류인지 5가지로 분류했습니다. 대상을 이어받는 것인지, 조건을 추가하는 것인지, 앞의 것을 제외하는 것인지, 비교를 요청하는 것인지 등입니다.
유형을 먼저 정하니 무엇을 이어받고 무엇을 버릴지가 결정됐습니다. 이를 안 하고 한 번에 재작성시키면 모델이 매번 다르게 판단합니다.
4단계 재작성 파이프라인
① 키워드 보존 → ② 히스토리 승격 → ③ 조건 합집합 → ④ 자가 검증① 키워드 보존 · 현재 발화에 있는 단어를 먼저 확보합니다. 이것이 최우선입니다. 사용자가 지금 말한 것이 가장 중요한 신호이기 때문입니다.
② 히스토리 승격 · 생략된 대상을 이전 대화에서 찾아 채웁니다. 전체를 붙이는 게 아니라 필요한 항목만 끌어올립니다.
③ 조건 합집합 · 이전 조건과 새 조건을 합칩니다. "A 상품" + "약정 없이" → 둘 다 유지합니다. 새 조건이 이전 것을 덮어쓰지 않도록 하는 게 핵심이었습니다.
④ 자가 검증 · 재작성 결과가 원래 의도를 유지하는지 확인합니다.
왜곡 제어: 규칙 기반 제약
가장 중요한 결정이 이 부분입니다. 부정형과 숫자와 날짜 왜곡은 LLM에게 맡기지 않았습니다.
"부정 표현을 유지하라"고 프롬프트에 아무리 써도 확률적으로 샜습니다. 이에 따라 원문의 특정 조건을 고정하는 규칙 기반 처리를 결합했습니다. 원문에 부정 표현이 있으면 재작성 결과에도 반드시 남아 있어야 하고, 숫자와 날짜는 원문의 값을 그대로 유지하도록 강제했습니다.
이는 앞서 환각 문제에서 배운 것과 같은 원리입니다. 확정성이 필요한 곳에는 확정적인 수단을 씁니다. 문맥을 이해해 자연스럽게 다시 쓰는 일은 LLM이 잘합니다. 다만 "이 단어를 빠뜨리지 않습니다"는 보장은 LLM이 줄 수 없습니다. 두 가지를 나눠 각각에 맞는 도구를 붙였습니다.
복합 의도의 처리
"A로 하고 다음 주 화요일에 해주세요"처럼 한 발화에 여러 의도가 섞이는 경우도 있었습니다.
이는 명시적인 선행 의도를 먼저 처리하고, 후순위 의도는 버퍼에 보관했다가 순차적으로 소비하는 방식으로 처리했습니다. 뒤의 의도를 버리지 않으니 사용자가 같은 말을 반복하지 않아도 됐습니다. 그리고 라우팅이 헷갈리는 케이스는 별도 예외 라벨 체계를 만들어 오분류를 줄였습니다.
6. 실험 결과
이 재작성 파이프라인은 앞서 정리한 상태 관리·페이로드 최적화와 함께 적용되어 전체 지표에 기여했습니다.
| 측정 항목 | 개선 전 | 개선 후 |
|---|---|---|
| 답변 성공률 | 78% (단일턴) | 98%+ (단일·멀티턴 평균) |
| 검증 범위 | 단일턴 | 멀티턴·비선형 흐름 포함 |
| 부정형·수치 왜곡 | 발생 | 하드룰로 고정 |
성공률 자체보다 의미 있었던 건 검증 범위를 넓혔다는 점입니다. 단일 질문만 테스트할 때는 문안 보였습니다. 멀티턴과 비선형 흐름까지 시나리오에 넣고 나서야 실제 사용 환경의 품질을 측정할 수 있었습니다.
7. 결론 및 시사점
검색 품질 문제의 상당수는 검색 엔진이 아니라 질의에 있었습니다. 초기에는 검색이 안 되면 색인이나 임베딩을 의심했습니다. 실제 원인은 검색에 들어가기 전 질의가 이미 망가져 있는 것인 경우가 많았습니다. 이후로는 RAG를 붙일 때 최종 답변보다 실제로 검색 엔진에 들어간 질의 문자열을 먼저 찍어봅니다.
LLM에게 시킬 일을 쪼개면 통제할 수 있습니다. "알아서 잘 재작성해줘"는 편하지만 틀렸을 때 손댈 곳이 프롬프트밖에 없습니다. 유형 판별과 문맥 복원과 검증으로 나누니, 어느 단계가 틀렸는지 특정하고 그 단계만 고칠 수 있게 됐습니다.
자연스러움과 정확성은 다른 도구가 담당해야 합니다. 문장을 매끄럽게 다시 쓰는 건 LLM의 강점입니다. 특정 단어가 반드시 살아남게 하는 건 규칙의 영역입니다. 하나에 둘 다 요구하면 둘 다 어중간해집니다. 역할을 나누고 각각에 맞는 수단을 붙이는 것이 이 프로젝트 전반에서 반복적으로 옳았던 판단이었습니다.