내 문서를 찾고 답하는 로컬 RAG 입문

사용자 질문을 벡터로 바꾸고, 미리 벡터화한 문서 조각 중 가까운 항목을 찾은 뒤, 그 원문을 생성 모델의 입력에 포함합니다. 모델 가중치를 바꾸지 않으므로 문서 추가·삭제가 비교적 쉽습니다.

모델이 문서를 실제로 이해했다기보다 검색된 문맥을 참고해 답하는 구조입니다. 검색 결과에 정답이 없으면 더 큰 생성 모델을 써도 없는 근거를 만들 수 있습니다.

PDF의 읽기 순서, 표, 머리말, 스캔 이미지가 잘못 추출되면 이후 단계는 모두 오염됩니다. 원문 일부와 추출 텍스트를 나란히 비교하고 페이지 번호나 파일 경로 같은 출처 메타데이터를 보존하세요.

암호화 파일, 중복 버전, 오래된 규정 문서를 섞기 전에 범위와 최신성부터 정리합니다. 접근 권한이 다른 문서를 하나의 인덱스에 합치지 않는 것이 중요합니다.

• 지원 파일 형식 정의
• OCR 필요 문서 분리
• 중복·구버전 제거
• 페이지·제목·경로 메타데이터 보존
• 문서 권한별 인덱스 분리

너무 짧으면 문맥이 끊기고 너무 길면 관련 없는 내용이 함께 들어갑니다. 고정 글자 수만 사용하기보다 제목과 문단 경계를 우선하고, 겹침은 앞뒤 문맥이 꼭 필요할 때만 추가합니다.

하나의 정답 문장이 어느 청크에 들어갔는지 사람이 확인할 수 있어야 합니다. 청크 ID와 원문 위치를 저장하면 검색 실패를 재현하기 쉽습니다.

Ollama의 `/api/embed`는 텍스트를 검색용 벡터로 바꿉니다. 공식 문서는 embeddinggemma, qwen3-embedding, all-minilm 등을 예로 들며 인덱싱과 질문에 같은 임베딩 모델을 사용하라고 안내합니다.

코사인 유사도로 가까운 청크를 찾되 상위 몇 개를 무조건 정답으로 보지 않습니다. 필터, 키워드 검색, 재순위화를 더하기 전 작은 데이터셋에서 기본 검색 결과를 눈으로 확인하세요.

curl http://localhost:11434/api/embed -d '{
  "model": "embeddinggemma",
  "input": ["환불 규정은 구매 후 7일입니다."]
}'

검색된 청크만 근거로 답하고, 근거가 부족하면 모른다고 말하며, 파일명과 페이지를 표시하도록 프롬프트를 설계합니다. 인용 표시는 원문 위치와 실제로 연결되어야 합니다.

생성 답변만 저장하지 말고 사용한 청크 ID와 검색 점수도 기록하면 오류를 검색 문제와 생성 문제로 나눌 수 있습니다.

• 제공된 문맥 밖의 추측 금지
• 답마다 출처 파일·페이지 표시
• 근거 부족 상태 정의
• 검색 청크와 답변 함께 저장
• 사용자가 원문을 열 수 있게 연결

정답 위치를 아는 사실 질문, 여러 청크를 조합해야 하는 질문, 문서에 답이 없는 질문을 섞습니다. 먼저 정답 청크가 검색 상위에 있는지 보고, 다음으로 답변이 그 근거를 정확히 사용했는지 평가합니다.

검색 실패와 생성 실패를 하나의 점수로 합치면 개선 지점을 찾기 어렵습니다. 문서를 갱신할 때 같은 질문 세트를 다시 실행해 회귀를 확인하세요.

원본 파일만 지워도 청크, 임베딩, 캐시, 대화 로그에 내용이 남을 수 있습니다. 문서 ID를 기준으로 모든 파생 데이터를 찾아 삭제하고 재검색으로 제거 여부를 확인합니다.

업무 문서라면 보존 기간, 접근 통제, 백업 복구 시 재등장하는 데이터까지 운영 절차에 포함하세요.