챗봇이 제 문서를 못 찾아요

1. 챗봇이 관련 없는 답변을 하는 이유: RAG 검색 과정

• 챗봇이 이상한 답변을 하거나 분명히 있는 문서를 못 찾는 경우가 많아요.

  • 예를 들어 최신 환불 정책 문서를 제공했는데도 이전 정책을 알려주거나 “관련 자료가 없다”고 말하는 경우입니다.

• 이런 문제는 대부분 LLM 자체의 문제가 아니에요.

  • LLM은 질문에 대한 답을 생성하는 두뇌와 같지만, 정확한 정보가 전달되지 않으면 올바른 답변을 생성하기 어렵습니다.

• 챗봇이 제대로 답변하려면 두 가지 단계가 중요해요.

  • 검색: 질문에 맞는 문서를 찾아오는 단계입니다.

  • 생성: 찾은 문서를 바탕으로 LLM이 답변을 생성하는 단계예요.

• 검색 단계에서 답이 적힌 문서를 찾지 못하면 아무리 좋은 LLM이라도 올바른 답변을 생성할 수 없어요.

  • 잘못된 정보가 들어가면 잘못된 답변이 나오기 때문에, 답변 모델보다 검색 결과를 먼저 확인해야 합니다.

2. 답이 적힌 문서를 못 찾는 세 가지 주요 원인

• 챗봇이 답이 적힌 문서를 못 찾는 데는 크게 세 가지 이유가 있어요.

• 1. 어휘 불일치: 단어 검색의 한계

  • 사용자가 “상품을 환불하고 싶어요”라고 물었는데 문서에는 “결제 취소 및 청약 철회”라고만 적혀 있는 경우입니다.

  • 단어 검색은 ‘환불’이라는 단어가 없으면 해당 문서를 놓칠 수 있어요. ‘사과’를 찾는데 ‘애플’이라고 적힌 상자를 찾지 못하는 것과 같습니다.

• 2. 식별자와 조항 번호 무시: 의미 검색의 한계

  • 단어 검색의 한계를 보완하려고 의미 검색을 사용하기도 합니다. 문장 전체의 뜻이 비슷한 문서를 찾는 방식이에요.

  • 그런데 사용자가 “환불 규정 제7조 2항을 보여줘”처럼 정확한 조항 번호를 물어볼 때 문제가 생길 수 있습니다.

  • 의미 검색은 내용이 비슷한 다른 문단을 먼저 보여주고 정확한 ‘제7조 2항’ 문단은 뒤로 밀 수 있어요.

• 3. 여러 저장소에 흩어진 정보

  • 챗봇 문서 정보를 여러 저장소에 분리해 저장하면 관리가 복잡해져요.

    • 관계형 데이터베이스: 문서의 제목, 작성자, 권한 같은 정보를 관리합니다.

    • 벡터DB: 문서의 의미를 숫자로 바꾸어 저장해요.

    • 검색 엔진: 문서의 단어를 빠르게 찾을 수 있도록 색인을 관리합니다.

  • 여러 저장소에 정보를 분리해 저장하면 수정 상태와 검색 조건이 서로 달라질 수 있어요.

    • 동기화 지연: 문서를 수정해도 일부 저장소에는 이전 정보가 남을 수 있습니다.

    • 정보 누락: 권한이나 공개 상태가 검색 과정에 제대로 적용되지 않아 필요한 문서가 빠지거나 보여주면 안 되는 문서가 검색될 수 있어요.

3. UQA로 RAG 검색 문제를 해결하는 방법

• UQA는 여러 저장소를 오가며 발생하는 검색 문제를 줄여주는 시스템이에요.

  • 흩어진 문서 정보와 검색에 필요한 데이터를 UQA에서 함께 관리할 수 있습니다.

• 1. 하나의 SQL로 단어 검색·의미 검색·권한 조건을 처리해요.

  • 예전에는 검색 종류와 권한 조건마다 서로 다른 명령과 연결 코드를 관리해야 했습니다.

  • UQA에서는 익숙한 SQL로 단어 검색, 의미 검색, 권한 조건을 함께 실행할 수 있어요.

• 2. 단어 검색과 의미 검색 결과를 같은 기준으로 정리해요.

  • 단어 검색 점수와 의미 검색 점수는 계산 기준이 달라서 그대로 더하면 검색 순서가 어긋날 수 있습니다.

  • UQA는 서로 다른 검색 결과를 비교할 수 있게 정리한 뒤 관련성 높은 문서부터 보여줘요.

• 3. 데이터 중복과 별도 동기화 작업을 줄여요.

  • 여러 저장소에 정보를 분리해 저장하면 데이터를 옮기고 수정 상태를 동기화하는 작업이 필요합니다.

  • UQA에 문서와 검색 데이터를 함께 저장하면 단어 검색과 의미 검색에 필요한 정보를 한곳에서 관리할 수 있어요.

  • 문서를 수정할 때 검색에 사용하는 정보도 함께 변경할 수 있어 서로 다른 버전이 검색되는 문제를 줄입니다.

4. 챗봇 답변 오류를 추적하고 고치는 방법

• 챗봇이 잘못된 답변을 했을 때는 어디서부터 문제가 시작됐는지 찾아내는 게 중요해요.

  • UQA는 문서에 원본 문서 ID(source_id), 버전 ID(version_id), 청크 ID(chunk_id)를 함께 저장합니다.

  • 이 번호를 확인하면 답이 적힌 문단이 어느 단계에서 사라졌는지 추적할 수 있어요.

• 추적 과정

  • 1. 원본 문서: PDF 글자가 제대로 추출됐는지, 문서가 지나치게 큰 단위로 저장됐는지 확인합니다.

  • 2. UQA 청크 데이터: 최신 문서가 올바른 단위로 저장되고 수정됐는지 확인해요.

  • 3. UQA 검색 결과: 답이 적힌 문단이 상위 결과에 표시됐는지, 권한이나 점수 때문에 빠지지 않았는지 확인합니다.

  • 4. LLM 입력 문단: UQA가 찾은 문서가 LLM에 전달될 때 누락되거나 잘리지 않았는지 확인해요.

  • 5. 최종 답변과 출처: 답변 내용이 정확하고 출처가 올바르게 표시됐는지 확인합니다.

5. 문서 구조를 알맞게 나누는 방법(청킹)

• 검색 시스템이 좋아도 문서를 어떤 단위로 분리해 저장할지가 중요해요.

  • 문서를 너무 큰 단위로 분리하면 필요한 정보만 찾기 어렵고, 너무 작은 단위로 분리하면 앞뒤 문맥을 이해하기 어려워집니다.

• 문서 유형별 권장 분할 방법

  • FAQ와 Q&A: 질문과 답변 한 쌍을 하나의 청크로 구성합니다.

  • 서비스 약관과 정책 문서: ‘제N조 N항’처럼 조항 단위로 분리하는 게 좋아요.

  • 긴 매뉴얼과 기술 문서: 하나의 절차나 조건을 설명하는 문단 단위로 분리합니다.

    • 짧은 문단을 검색하되 LLM에는 해당 문단의 상위 소제목과 주변 문단을 함께 전달하면 문맥을 이해하기 쉬워져요.

  • 표 중심 문서와 PDF: 표 제목, 열 이름, 각 행의 데이터를 하나의 청크로 구성합니다.

6. UQA로 문서 검색 누락을 진단하고 챗봇 답변 고치기

• UQA와 클로드·코덱스를 사용하면 챗봇이 답변하지 못한 원인을 찾고 수정할 수 있어요.

• 1단계: 답이 적힌 문단이 빠진 단계 찾기

  • 답변하지 못한 질문과 답이 적힌 문단을 제공하고 답이 적힌 문단이 처음 빠진 위치를 확인합니다.

  • 문서 ID, 버전, 청크 ID, 권한, 검색 점수를 함께 확인해 원인 후보를 찾아요.

• 2단계: 빠진 단계만 수정

  • 앞에서 확인한 단계에 필요한 수정 방법을 요청합니다.

  • 문서 저장 방식이 문제라면 청킹 방식을 바꾸고, 검색 순서가 문제라면 단어 검색과 의미 검색 기준을 조정해요.

• 3단계: 수정 전후 다시 확인

  • 이전에 실패했던 질문과 원래 잘 답변하던 질문을 함께 다시 실행합니다.

  • 수정한 부분이 다른 질문의 답변을 바꾸지 않았는지 확인해요.

• 이 과정을 거치면 LLM을 바꾸기 전에 검색 과정의 문제를 먼저 진단하고 수정할 수 있어요.

현재 UQA는 로컬 설치와 운영이 기본이고 UQA Cloud는 준비 중입니다. 아래 프롬프트는 로컬 개발 환경에서 챗봇 검색 오류를 점검하고 수정할 때 사용해요.

# UQA 및 스킬 설치
curl -fsSL https://releases.uqa-cloud.cognica.io/install.sh | sh &&
export PATH="${UQA_INSTALL_DIR:-$HOME/.local/bin}:$PATH" &&
uqa llm install skills

1단계: 답이 적힌 문단이 빠진 단계 찾기

2단계: 빠진 단계만 수정

3단계: 수정 전후 다시 확인