챗봇이 목록을 자꾸 틀린다면: 생성이 아니라 조회를 시키세요

왜 이 주제가 중요한가

사내 데이터에 AI 챗봇을 붙이면 누구나 한 번쯤 이런 질문을 던지게 됩니다.

"이케아 철재장에 있는 물건 전부 표로 정리해줘"

그리고 대부분 이런 답을 받습니다. 목록이 40개여야 하는데 30개만 나오거나, 있지도 않은 물건 이름이 섞여 있거나, 실행할 때마다 개수가 달라집니다. 이쯤 되면 "우리 모델이 작아서 그런가, 더 좋은 LLM을 쓰면 해결되나?"라는 고민으로 이어집니다.

결론부터 말하면, 이 문제는 모델 성능의 문제가 아니라 설계의 문제입니다. 최상위 모델을 붙여도 이 구조로는 보장이 안 되고, 반대로 구조를 바꾸면 소형 오픈소스 모델로도, 심지어 LLM 없이도 100% 정확해집니다.

핵심 개념: 왜 "생성"은 목록에 약한가

일반적인 RAG 챗봇은 이렇게 동작합니다.

질문 → 벡터 검색(상위 k개 조각) → LLM이 조각을 읽고 답 생성

이 구조가 목록 질문에서 무너지는 지점은 두 곳입니다.

1. 검색 단계에서 이미 샙니다. 벡터 검색은 질문과 유사한 상위 k개 조각만 가져옵니다. 물건 48개가 여러 조각에 흩어져 있다면, 그중 일부만 LLM에게 전달됩니다. 애초에 모델이 전체 목록을 본 적이 없으니 전체를 답할 수 없습니다.

2. 모델은 전사(轉寫)에 약합니다. 전체 데이터를 컨텍스트에 다 넣어줘도 문제는 남습니다. 수십 개 항목을 하나도 빠뜨리지 않고, 이름을 한 글자도 바꾸지 않고 옮겨 적는 것은 확률적 생성 모델의 약점입니다. 모델이 클수록 나아지긴 하지만 "정확히 48개"를 보장하는 모델은 없습니다. 목록·개수·집계는 확률과 상성이 가장 나쁜 과제입니다.

실제 적용 포인트: 정형 질문은 DB가 답하게

저희가 사내 도구에 적용한 구조는 간단합니다. 재고처럼 정형화된 질문은 LLM을 거치지 않고 DB가 직접 답하게 하고, LLM은 비정형 지식 질문만 담당합니다.

질문
 ├─ 재고 인텐트 감지됨 → DB 쿼리 → 코드가 표 생성 (LLM 미사용)
 └─ 그 외 → 기존 RAG 파이프라인

구현은 세 단계입니다.

1. 인텐트 감지는 가볍게. 위치 이름 사전(구역·가구·칸 등)을 DB에서 읽어 질문과 대조하고, "뭐가, 목록, 표로, 몇 개" 같은 목록 의도 단어가 함께 있는지만 봅니다. 이 정도는 LLM 없이 규칙으로 충분하고, 결정적이라 오늘 되던 게 내일 안 되는 일이 없습니다.

2. 오타는 편집 거리로 흡수. 사용자는 "철재장"을 "철제장"으로 쓰기 마련입니다. 위치명 매칭에 레벤슈타인 거리 1~2를 허용하면 표기 흔들림 대부분이 잡힙니다. 사전이 100여 개 수준이면 전수 비교해도 비용은 무시할 만합니다.

3. 표는 코드가 만듭니다. 인텐트가 확정되면 ORM으로 해당 위치의 아이템을 전부 조회해서, 마크다운 표를 문자열로 직접 조립합니다. 46종이면 정확히 46행이 나옵니다. LLM이 데이터를 거치지 않으므로 개수도 이름도 수량도 틀릴 수가 없습니다.

역방향 질문("건전지 어디 있어?")도 같은 원리로 처리합니다. 이름 키워드로 아이템을 찾아 위치 경로를 표로 돌려주면 됩니다.

부수 효과도 큽니다. 이 경로는 모델 서버를 아예 호출하지 않으므로 응답이 사실상 즉시이고, AI 서버가 내려가 있어도 재고 질문은 계속 동작합니다.

주의할 점

• 가로채기 오탐을 경계하세요. "철재장 정리하는 방법 추천해줘"는 재고 질문이 아니라 지식 질문입니다. "방법, 팁, 추천, 왜, 비교" 같은 단어가 있으면 인텐트를 포기하고 RAG로 넘기는 부정 규칙이 필요합니다.
• 표가 무한정 길어지지 않게 행 수 상한을 두고, 잘렸다는 사실을 답변에 명시하세요. 조용한 절단은 "전부 보여줬다"로 읽힙니다.
• 답변에 출처 성격을 밝히세요. "DB를 직접 조회한 결과"라고 적어두면 사용자가 생성 답변과 신뢰 수준을 구분할 수 있습니다.
• 이 패턴은 재고에만 국한되지 않습니다. 매출 집계, 일정 목록, 회원 수처럼 정답이 DB에 이미 있는 질문은 전부 같은 방식이 맞습니다. LLM에게는 "말"을 시키고, "사실"은 시스템이 대야 합니다.

듀오랩스가 보는 관점

"AI 도입 = 좋은 모델 고르기"로 접근하면 이런 문제 앞에서 비용만 커집니다. 저희는 반대로 봅니다. 모델이 잘하는 일(비정형 텍스트 이해와 요약)과 시스템이 잘하는 일(정확한 조회와 집계)을 나누는 설계가 먼저고, 모델 선택은 그다음입니다. 실제로 위 구조는 사내 GPU에서 도는 소형 오픈소스 모델과 조합해도 상용 최상위 모델 못지않은 체감을 냅니다. 정확해야 하는 부분이 모델 밖으로 나갔기 때문입니다.

업무 시스템에 AI를 붙이고 싶은데 "챗봇이 자꾸 틀려서" 망설이고 계시다면, 모델 교체보다 이런 라우팅 설계를 먼저 검토해 보시길 권합니다.