'다음 주'는 검색으로 못 찾습니다 — RAG 사내 채팅 앞에 LLM 라우터를 붙인 기록

한 고객사의 사내 채팅은 문서 검색(RAG)으로 답합니다. 어느 날 직원이 '다음 주 주간보고 관련해서 요약해 달라'는 취지로 물었습니다. 채팅은 주간보고 **작성 가이드 공지**를 근거로 '이렇게 쓰면 된다'를 답했습니다. 이어서 '작성된 것들로 사람들이 하는 일을 정리해 달라'고 묻자, 이번엔 1년 전 업무 흐름 캡처를 근거로 가져왔습니다.

지난번 고친 뒤에도 같은 자리에서 또 틀린 것입니다. 앞서 '이번달 주간보고'를 물었더니 2년 전 문서를 요약한 일이 있었고, 그때 주간업무 전용 조회 도구와 낱말로 질문을 알아보는 장치를 붙였습니다. 그런데 '다음 주(차주)'라는 말 앞에서 그 장치는 질문을 알아보지 못했습니다.

'차주'는 찾을 낱말이 아니라 계산할 날짜였습니다

원인은 단순했습니다. '차주'는 문서에서 찾을 낱말이 아니라 계산해야 할 조건입니다. 오늘이 며칠인지 알아야 다음 주가 어느 날부터 어느 날까지인지 정해집니다. 검색은 '무엇이 적혀 있나'를 찾을 뿐 '언제인가'를 계산하지 못합니다.

그래서 검색은 낱말 '주간보고'가 들어간 문서를 위로 올렸습니다. 작성 가이드 공지와 옛 캡처가 그것입니다. 실제 답은 문서 색인이 아니라 업무 DB 의 주간보고 표에 있었습니다. 낱말이 겹치는 문서가 그럴듯하게 올라오는 것이 가장 알아채기 어려운 실패입니다. 답이 엉뚱해도 근거가 붙어 있어서 그럴듯해 보입니다.

정규식을 늘릴지, 모델에게 한 번 물을지

고칠 길은 두 가지였습니다. 이미 있는 낱말 장치에 표현을 더하는 길과, 검색 앞에서 LLM 에게 한 번 물어 질문을 조건으로 바꾸는 길입니다.

라우터를 골랐습니다. 다만 판단 규칙을 어디에 둘지가 먼저였습니다. 문서 검색 서비스는 문서와 색인만 갖고 있고, 업무 DB 는 다른 서비스에 있습니다. 그래서 어떤 질문을 어떤 도구로 보낼지는 **업무 데이터를 가진 서비스**가 정하게 했습니다. 모델 호출 API 는 문서 검색 서비스가 맡습니다. 기존 '질문 풀어쓰기'가 쓰던 API 를 그대로 쓰고, 기본은 OpenAI 의 luna 모델, 막히면 사내 GPU 서버로 넘어가며, 용도 값으로 사용량을 구분합니다.

질의 API 에는 '검색어' 칸을 하나 추가했습니다. 라우터가 검색어를 정해 넘기면 풀어쓰기 단계를 건너뜁니다. 주 기준은 주간보고 화면과 같게 '오늘이 든 주의 일요일'로 맞췄습니다. 차주는 거기서 +1주 칸 하나입니다.

라우터는 한 번만 부르고, 틀리면 물러섭니다

업무 조회 도구 8개를 한 파일에 모았고, 라우터 프롬프트도 그 목록에서 만들게 했습니다. 도구를 하나 더하면 프롬프트가 따라서 바뀝니다. 라우터는 LLM 을 한 번만 부릅니다. 아래 셋 중 하나라도 해당하면 '없음'을 반환하고, 기존 낱말 장치로 물러섭니다.

모델 호출이 실패했을 때

목록에 없는 도구를 골랐을 때

조건의 모양(주·사람 칸)이 틀렸을 때

답 기록에는 어느 경로로 왔는지(route) 칸을 남겼습니다. 채팅 평가 도구에도 두 경로를 나란히 비교하는 칸을 붙였습니다. 라우터가 맞게 보냈는지, 물러선 질문은 무엇이었는지를 기록으로 확인할 수 있습니다.

라우터 자료만 넣었더니 잃는 것이 생겼습니다

첫 구현은 라우터가 성공하면 라우터가 가져온 자료만 모델에게 넘겼습니다. 그러자 일부 질문에서 답이 오히려 얇아졌습니다. 기존 낱말 장치는 고객사 표, 관계, 판본 같은 자료를 덤으로 붙여 주고 있었습니다. 라우터 경로로 바뀌면서 그 맥락이 사라진 것입니다.

그래서 **라우터 자료와 낱말 장치 자료를 함께 넣도록** 고쳤습니다. 라우터는 기존 장치를 대체하지 않고 그 위에 더해집니다. 라우터가 실패하면 예전 동작 그대로이고, 성공하면 예전 자료에 라우터 자료가 더해집니다. 어느 질문도 전보다 나빠지지 않는 쪽을 설계 조건으로 둔 것입니다.

앞 대화의 '2025년'을 따라갔습니다

회귀 문항만 실행했을 때는 보이지 않던 문제가, 앞 대화까지 포함한 실제 채팅 38문항을 재생하자 나왔습니다. 앞 대화에 '2025년'이 나온 뒤 '9월 둘째 주'를 물으면, 라우터가 연도를 앞 대화에서 가져와 잘못 잡았습니다. 대화형 질의에서는 앞에서 나온 연도와 대상이 다음 질문의 해석에 그대로 영향을 줍니다.

고친 방법은 규칙 한 줄입니다. '연도를 말하지 않으면 올해'로 정해 라우터 프롬프트에 넣었습니다. 모델이 날짜를 스스로 짐작하게 두면 엉뚱한 해로 가는 일이 이번이 처음은 아니었습니다.

결과와 감수한 것

회귀 21문항과 실제 채팅 38문항으로 확인했습니다. 차주 요약, 사람별 정리, '9월 둘째 주 + 한 직원' 질문이 모두 주간보고 표에서 맞게 답했습니다. API 테스트 550개도 통과했습니다. 날짜·사람·주 단위가 든 업무 질문은 이제 문서가 아니라 DB 의 표에서 답합니다.

감수한 것은 지연입니다. luna 의 첫 글자까지 1.5~1.8초, 라우터 전체로 약 2초가 질문마다 더 듭니다. 생각 깊이를 low 로 낮춰도 달라지지 않았습니다. 라우터 호출을 더 작은 모델로 바꾸면 빨라질 것 같지만, 앞서 같은 기대로 측정한 결과는 이득이 없었습니다.

한계도 남아 있습니다.

형식 검사는 내용이 맞는지까지 보장하지 않습니다. 라우터가 모양은 맞지만 엉뚱한 사람이나 주를 내면 물러서지 않습니다

'연도 생략 = 올해'는 연초에 '12월 넷째 주'를 물으면 틀릴 수 있습니다

주 기준은 그 조직의 화면을 따른 것입니다. 월요일 시작 조직이면 차주 계산이 하루 밀립니다

측정은 59문항이라 표본이 크지 않습니다

상대 날짜가 든 질문을 받는 채팅이라면

질문에 차주·지난달·이번 분기 같은 상대 날짜가 자주 나오는지 먼저 확인합니다. 거의 다 문서형 질문이면 라우터 2초는 비용만 늘립니다

답이 문서가 아니라 표에 있는 질문이 있는지 봅니다. 있다면 판단 규칙은 그 데이터를 가진 서비스에 둡니다

라우터가 실패했을 때 물러설 기존 경로가 있는지 확인합니다

라우터 자료만 넘기지 말고 기존 경로의 자료도 함께 넘기는지 봅니다

회귀 문항 외에 앞 대화를 포함한 실제 채팅을 재생해 봅니다

이번 수정에서 라우터는 기존 검색을 바꾸지 않았습니다. 앞에 한 번 묻는 단계를 더했고, 그 단계가 틀리면 예전 동작으로 물러서게 했습니다. 상대 날짜를 검색어로 다루고 있다면, 낱말을 더 늘리기 전에 그 질문의 답이 문서에 있는지 표에 있는지부터 확인해 보시길 권합니다.