하이브리드 RAG 실전: Docling·PostgreSQL·로컬 LLM으로 멀티모달 비용 줄이기

핵심 메시지

• 문서를 LLM에 바로 드래그앤드롭하면 질문도 하기 전에 토큰을 소모하고, 청킹 방식이 보이지 않아 품질을 통제하기 어렵다.
• 로컬 CPU에서 Docling으로 문서를 마크다운으로 먼저 변환해 두면 청킹이 깔끔해지고 비용도 크게 줄어든다.
• 키워드 검색(BM25)과 의미 검색(벡터)을 함께 쓰는 하이브리드 검색이 정확도를 높인다.
• 에이전트를 LLM 루프 대신 파이썬 함수로 처리하면 속도가 빠르고 환각이 줄며 통제가 쉬워진다.
• 데이터를 잘 정제하면 가장 작은 모델로도 충분한 답을 얻을 수 있다.

쉽게 이해하기

Ogilvy의 백엔드 개발자 아베드 마티니는 AI Engineer World Fair 2026 온라인 트랙에서, 별도의 유료 프레임워크 없이 동작하는 하이브리드 RAG 시스템을 라이브 데모와 함께 소개했다. 예시는 사내 인사 정책을 답해 주는 'FAQ 어시스턴트' 챗봇으로, 휴가·병가·육아휴직 같은 직원들의 반복 질문을 처리하는 상황을 가정한다.

그는 문서를 챗봇에 그대로 올리는 방식의 두 가지 문제를 지적한다. 첫째, 업로드만으로 질문 전부터 토큰을 소모한다. 둘째, 문서가 어떻게 청킹되어 저장·검색되는지 보이지 않아 표가 잘못 읽히는 등 품질 위험이 생긴다. 대안은 '구조 우선' 방식으로, 로컬 CPU에서 Docling이 PDF·워드·파워포인트·이미지를 마크다운으로 변환한 뒤 청킹해 PostgreSQL 벡터 DB에 적재하는 것이다.

청킹 전략으로는 제목(heading) 기반, 문단(paragraph) 기반, 512자 고정 길이에 64자 중첩을 두는 방식, 문장 기반 네 가지를 제시한다. 핸드북 전체를 통째로 올리면 서명란·날짜처럼 의미 없는 청크가 섞여 정확도가 떨어지고 환각이 늘기 때문에, 데이터를 질문·답변 형태로 정리하거나 제목 단위로 끊어 출처 추적이 쉽게 만드는 것이 핵심이다.

검색 단계에서는 의미가 비슷한 벡터를 코사인 거리로 찾는 의미 검색과, 제품명·SKU·브랜드처럼 정확히 일치해야 하는 키워드 검색(BM25)을 함께 쓴다. 두 결과를 섞어 상위 결과만 재정렬(re-rank)해 돌려주며, 의료처럼 책임이 큰 분야는 적게, 제품 카탈로그처럼 폭이 넓은 분야는 많이 가져오도록 반환 개수를 조절한다.

스택은 파이썬·FastAPI·React·PostgreSQL·Docker에 로컬 추론용 Ollama를 더했다. 채팅 모델은 약 400MB 크기의 Qwen 2.5 0.5B, 임베딩은 BGE 계열을 써서 GPU 없이 CPU만으로 돌린다. 관측에는 무료인 LangFuse를 붙여 대화 ID·지연시간·반환 청크 수를 추적한다.

주요 인사이트

• 가드레일은 LLM 프롬프트가 아니라 코드에서 먼저 처리한다. 의료 상담이나 프롬프트 인젝션처럼 응답하면 안 되는 질문은 LLM에 보내기 전에 의도 거부·용어 사전·분류기로 차단해, 무엇을 왜 막았는지 테스트로 검증할 수 있게 한다.
• 에이전트를 LLM으로 여러 번 호출하면 20~30초씩 기다리게 되어 사용자가 흥미를 잃는다. 현재 날짜 조회나 계산처럼 함수로 끝낼 수 있는 일은 파이썬 함수로 처리해 속도와 통제력을 모두 확보한다.
• 발표자의 경험상 가장 큰 모델이 꼭 필요한 것은 아니었다. 보내기 전 데이터를 잘 검증하면 가장 작은 모델로도 좋은 답이 나오고, 정보가 없으면 '모른다'고 답해 환각이 줄어든다.
• Docling이 무거운 변환 작업을 맡고 PostgreSQL이 저장을 담당하므로, 특정 유료 프레임워크에 묶이지 않고도 문서 카탈로그나 고객 서비스 등 다른 제품으로 확장할 수 있다.

자주 묻는 질문

관련 AI 소식