RAG(검색 증강 생성) 기술로 회의록 검색의 정확도 높이기

대형 언어 모델(LLM)의 등장은 정보 검색과 요약 업무에 혁신적인 변화를 가져왔습니다. 자연어로 질문하면 자연어로 답하는 인터페이스는 누구에게나 직관적이고 편리합니다. 그러나 LLM에는 치명적인 약점이 하나 있습니다. 바로 "환각(Hallucination)" 현상입니다. 모델이 학습 데이터에서 패턴을 기억하는 방식으로 동작하기 때문에, 학습 시점 이후에 발생한 사건이나 특정 기관 내부 문서에 대해서는 그럴듯하지만 틀린 답변을 자신 있게 생성합니다. 회의록처럼 "누가 언제 무슨 말을 했는지"가 법적·행정적으로 중요한 문서에서는 이 문제가 더욱 치명적입니다. RAG(Retrieval-Augmented Generation) 기술은 이 딜레마를 해결하기 위해 등장한 핵심 아키텍처입니다.

LLM 환각 현상이란?

환각 현상은 LLM이 학습 데이터에 없는 정보나 사실관계를 창작해 내는 현상을 말합니다. 모델은 언어 패턴과 확률 분포를 기반으로 다음 토큰을 예측하므로, "그럴듯한" 문장을 만들어내는 능력은 뛰어나지만 "정확한" 사실을 보장하지는 않습니다. 특히 파인튜닝 없이 범용 LLM을 사용할 경우, 특정 회의에서 A위원이 발언한 내용을 물어보면 모델은 관련 없는 다른 회의 내용이나 완전히 가공된 내용을 답변으로 제시할 수 있습니다. 이런 오답이 회의록으로 기록되거나 의사결정 근거로 활용된다면 기관의 신뢰성과 법적 책임에 심각한 위험이 초래됩니다.

• •날짜·수치 오류: 예산 심의 결과나 의결 날짜를 실제와 다르게 생성하는 경우
• •화자 혼동: A 위원이 발언한 내용을 B 위원의 것으로 잘못 기술하는 경우
• •존재하지 않는 안건 생성: 실제로 논의되지 않은 사항을 회의에서 결정된 것처럼 서술
• •맥락 단절: 여러 회의에 걸친 연속된 논의를 하나의 회의로 통합하여 혼동을 유발
• •법적 분쟁 위험: 잘못된 회의록이 행정처분이나 계약의 근거로 사용될 경우 책임 문제 발생

RAG의 등장: 검색으로 LLM을 제어하다

RAG(Retrieval-Augmented Generation)는 2020년 Facebook AI Research(현 Meta AI)가 발표한 아키텍처로, LLM이 답변을 생성하기 전에 외부 지식 저장소에서 관련 문서를 먼저 검색하여 컨텍스트로 제공하는 방식입니다. 이를 통해 LLM은 학습된 파라미터만으로 답변하는 것이 아니라, 실제 문서의 내용을 참조하여 팩트 기반의 답변을 생성합니다. 마치 시험을 볼 때 교재를 참고할 수 있게 해주는 것과 같습니다. 회의록 시스템에 적용하면, 사용자의 질문에 가장 관련성 높은 실제 회의록 구절을 먼저 검색하고, 그 내용을 근거로 LLM이 답변을 구성하므로 환각 발생이 구조적으로 억제됩니다.

RAG의 핵심 기술: 벡터 검색

RAG의 성능은 검색 품질에 의해 결정됩니다. 전통적인 키워드 검색은 "예산"이라는 단어가 포함된 문서를 찾지만, 의미론적으로 유사한 "재정 계획"이나 "세출 조정" 같은 표현은 놓칩니다. 반면 벡터 검색(Vector Search)은 텍스트를 고차원 벡터 공간의 숫자 표현(임베딩)으로 변환하여 의미적 유사도를 수치로 계산합니다. 임베딩 모델(예: text-embedding-3-large, BGE-M3 등)은 문장의 의미를 768~4096차원의 벡터로 인코딩하며, 코사인 유사도나 내적(dot product)을 통해 질문과 가장 관련성 높은 문서 조각(청크)을 밀리초 단위로 검색합니다. 이 방식은 다국어 지원, 문체 변형, 동의어 처리에 모두 강인합니다.

플러스랩스의 회의록 RAG 시스템

플러스랩스의 회의록 RAG 시스템은 회의록이 생성되는 즉시 자동으로 청킹(Chunking) — 문장 또는 발언 단위로 분할 — 하여 임베딩 벡터를 생성하고 내부 벡터 DB(pgvector 또는 Milvus 기반)에 색인합니다. 사용자가 자연어로 질문을 입력하면, 시스템은 질문을 동일한 임베딩 공간에 변환하여 Top-K 관련 청크를 검색하고, 이를 LLM의 컨텍스트 윈도우에 삽입하여 최종 답변을 생성합니다. 재순위화(Reranking) 단계에서는 Cross-encoder 모델을 통해 검색된 청크의 실제 관련성을 재평가하여 정확도를 추가로 높입니다. 전체 파이프라인은 온프레미스 환경에서 동작하며, 외부 API 호출 없이 평균 2~3초 내에 답변을 생성합니다.

• •"지난 6개월간 예산 관련 안건을 모두 요약해줘" — 기간 필터링 + 주제 검색 결합
• •"A 위원이 이 법안에 대해 찬성했나요, 반대했나요?" — 특정 화자의 입장 추출
• •"작년 12월 회의에서 결정된 사항들을 나열해줘" — 의결 정보 시계열 검색
• •"우리 기관이 환경 정책에 대해 논의한 모든 내용을 보여줘" — 주제 기반 통합 검색
• •"홍길동 위원장이 발언한 시간과 내용을 정리해줘" — 화자별 발언 통계 집계

RAG 도입 시 주의사항과 최적화 전략

RAG 시스템의 성능은 청크 사이즈 설계에 크게 좌우됩니다. 청크가 너무 작으면 문맥이 잘려 LLM이 올바른 답변을 생성하기 어렵고, 너무 크면 검색 정밀도가 떨어집니다. 플러스랩스는 회의록 특성상 발언 단위(평균 50~150 토큰)를 기본 청크로 사용하고, 슬라이딩 윈도우(Sliding Window) 기법으로 전후 맥락을 보존합니다. 임베딩 모델은 한국어 처리 특화 모델(KLUE-RoBERTa, KoSimCSE 등)을 우선 평가하되, 다국어 혼합 회의의 경우 multilingual-e5 계열을 활용합니다. 또한 최신 문서일수록 검색 우선순위를 높이는 시간 가중치(Temporal Weighting)를 적용하여 구식 정보가 우선 검색되는 문제를 방지합니다.