Chapter 06

문서를 지식으로: RAG와 지식 그래프

회사의 지식은 대부분 문서에 있다. 공유 폴더의 품질 보고서 PDF, 설비 매뉴얼 스캔본, 회의록 HWP, 결정이 묻힌 메일 첨부 PPT. 생성형 AI가 이 지식을 근거로 답하게 만드는 가장 실용적인 방법이 검색 증강 생성(RAG)이다. 이 장에서는 문서를 쪼개고 색인해 검색하고, 권한과 최신성을 지키며, 출처와 함께 답하게 하는 전 과정을 브라우저 안의 미니 RAG로 직접 돌려 본다.

RAG 파이프라인(파싱 → 청킹 → 색인 → 검색 → 재순위화 → 생성 → 출처 표시)의 각 단계가 하는 일과 흔한 실패를 설명할 수 있다.
청크 크기·오버랩의 트레이드오프와, 한국어 문서에서 키워드 검색(BM25)과 임베딩 검색을 함께 쓰는 이유를 이해한다.
권한(ACL) 필터, 문서 최신성, 출처 표시가 왜 선택이 아니라 필수인지 설명할 수 있다.
GraphRAG·지식 그래프·롱 컨텍스트를 언제 쓰는지 구분하고, 검색 재현율·근거성으로 RAG를 평가할 수 있다.

"지난번 비슷한 불량, 어떻게 해결했더라?"

입사 2년 차 공정 엔지니어가 프레스 라인의 버(burr) 불량 증가를 맡았다. 선배가 "작년에도 비슷한 일이 있었는데, 그때 보고서 찾아봐"라고 한다. 공유 드라이브의 품질 폴더에는 하위 폴더가 수백 개, 파일명은 QR_버불량_분석_최종.pdf, 프레스 이슈 정리(김책임 수정).pptx, 회의록_0312.hwp 같은 식이다. 파일 탐색기 검색은 PDF 안의 글자를 못 찾고, 스캔본은 아예 그림이다. 결정적인 내용은 결국 선배의 메일함에 있는 첨부 파일이었고, 그 선배는 다음 달 다른 사업부로 옮긴다.

이 엔지니어가 사내 AI 챗봇에 "펀치 연마 주기 바뀌었어?"라고 물으면 어떻게 될까. 일반 LLM은 회사 문서를 본 적이 없으므로 그럴듯한 일반론을 말하거나, 더 나쁘게는 존재하지 않는 수치를 지어낸다(환각). 모델을 사내 문서로 다시 학습시키는 방법도 있지만, 비용이 크고 문서가 바뀔 때마다 다시 해야 하며, 무엇보다 어느 문서를 근거로 답했는지 알 수 없다.

검색 증강 생성(RAG, Retrieval-Augmented Generation)은 질문이 들어오면 먼저 사내 문서에서 관련 부분을 찾아오고, 그 부분을 LLM에게 "이 자료만 근거로 답하라"며 함께 건네는 방식이다. 문서가 바뀌면 색인만 갱신하면 되고, 답에는 근거 문서가 붙는다.

그림 6-1. RAG 파이프라인. 위는 문서를 미리 처리해 색인하는 단계, 아래는 질문마다 실행되는 단계다. 권한 필터는 검색 전에 적용한다. 실패의 대부분은 LLM이 아니라 앞 단계(파싱, 청킹, 메타데이터)에서 시작된다.

RAG의 품질은 문서 정리 수준을 넘지 못한다

같은 주제의 보고서가 최종, 최종_v2, 진짜최종으로 세 개 있으면 RAG는 셋 중 아무거나 근거로 가져온다. 폐기된 매뉴얼이 현행 매뉴얼과 섞여 있으면 폐기된 수치로 답한다. 2장의 정보 인벤토리와 4장의 용어 사전이 RAG의 실제 선행 과제다.

파싱: 파일 형식마다 다른 함정

RAG의 첫 단계는 파일에서 글자를, 가능하면 구조와 함께 꺼내는 일이다. 제조 현장의 문서는 형식이 다양하고, 각 형식에 고유한 함정이 있다.

형식	흔한 문서	함정	대응
PDF(텍스트)	품질 보고서, 사양서	2단 편집이 한 줄로 섞임, 머리말·꼬리말 반복, 표가 글자 나열로 깨짐	레이아웃 인식 파서, 머리말 제거, 표는 별도 추출
PDF(스캔)	옛 매뉴얼, 서명된 성적서	글자가 아니라 그림. 도장·손글씨·기울어짐	OCR + 신뢰도 기록, 중요 문서는 사람이 검수
PPT	이슈 보고, 회의 자료	텍스트 상자 읽는 순서가 뒤죽박죽, 핵심이 그림·차트 안에, 슬라이드 노트에 숨은 설명	슬라이드 단위 청킹, 제목 보존, 노트 포함, 이미지 캡션 생성
엑셀	불량 집계, 작업 일지	병합 셀, 2~3줄 머리글, 숨은 시트, 수식 결과만 남음, 한 시트에 표 여러 개	표는 문서가 아니라 데이터로 — 정형 처리(5장)나 행 단위 텍스트화
한글(HWP/HWPX)	공문, 사내 규정, 회의록	전용 형식이라 범용 파서가 못 읽는 경우가 많음, 표 안의 표	XML 기반 HWPX나 PDF로 변환 후 파싱, 변환 품질 샘플 검수
메일	고객 클레임, 협력사 공지	답장마다 인용문이 반복, 서명·면책 문구, 결정은 첨부에	인용·서명 제거, 스레드 단위 묶기, 첨부를 같은 문서 ID로 연결

메타데이터가 검색의 절반이다

본문만 색인하면 "3월 B사 클레임 회의록"을 찾을 때 날짜와 고객이 본문에 우연히 적혀 있기를 바라야 한다. 파싱 단계에서 다음 메타데이터를 함께 뽑아 두면 검색 필터, 권한 통제, 최신성 판단이 가능해진다.

문서 유형: 품질 보고서 / 8D / 매뉴얼 / 작업 표준 / 회의록 / 메일
작성 부서·작성일·개정 번호, 그리고 상태(현행 / 폐기 / 초안)
업무 키: 제품·품번, 설비 ID, 고객 코드, 불량 코드(4장의 정준 코드로)
보안 등급과 접근 그룹(ACL): 원본 저장소의 권한을 그대로 가져온다
원본 위치: 출처 링크로 사용자가 원문을 열어 확인할 수 있게

청킹: 얼마나 잘게 자를 것인가

문서를 통째로 검색 대상으로 삼으면 50쪽짜리 매뉴얼 전체가 "관련 문서"로 걸려 LLM에게 너무 많은 글을 건네게 된다. 그래서 문서를 청크(chunk)라는 조각으로 나눠 색인한다. 나누는 방식은 크게 세 가지다.

그림 6-2. 청킹 전략 세 가지. 실무에서는 구조 기반을 기본으로, 너무 긴 구간은 고정 길이로 다시 나누고, 각 청크 앞에 문서 제목과 상위 제목을 붙이는 혼합 방식이 흔하다.

크기는 트레이드오프다. 청크가 너무 작으면 "조치 순서: ①… ②…"의 ③이 다음 청크로 잘려 답이 반쪽이 된다(맥락 손실). 너무 크면 관련 없는 내용이 섞여 검색 점수가 희석되고, LLM에게 잡음을 건넨다(정밀도 저하). 오버랩(overlap)은 인접 청크가 일부를 겹치게 해 경계에서 잘리는 문제를 줄이지만, 청크 수와 저장·임베딩 비용을 늘린다.

INTERACTIVE

청크 크기 실험 — 맥락 완결성 vs 집중도

청크 크기 s 오버랩 답에 필요한 맥락 길이 L

문서 성격(L 예시)

맥락 완결성 C집중도 P종합 F

완결성 C—

집중도 P—

종합 F—

이 조건의 최적 s—

청크 수(문서 100만 자)—

교육용 단순 모델이다. 답에 필요한 연속 구간(길이 L)이 문서 안 임의 위치에 있다고 할 때, 완결성 C는 그 구간이 한 청크 안에 온전히 들어갈 확률 $\min(1, (s-L)/t)$ (보폭 $t = s(1-\text{오버랩})$), 집중도 P는 청크 중 필요한 부분의 비율 $\min(1, L/s)$, 종합 F는 둘의 조화평균이다. 오버랩 0%에서 최적은 $s = 2L$ 근처이고, 오버랩을 늘리면 더 작은 청크로도 완결성을 얻지만 청크 수(비용)가 늘어난다. 답의 길이가 문서마다 다르므로, 한 가지 크기를 고집하기보다 문서 유형별로 다르게 자르는 것이 낫다.

검색: 키워드, 임베딩, 그리고 하이브리드

청크를 찾는 방법은 크게 두 가지다. 하나는 질문과 청크에 같은 단어가 얼마나 나오는지로 점수를 매기는 키워드 검색, 다른 하나는 문장을 숫자 벡터로 바꿔 뜻이 가까운 청크를 찾는 임베딩(벡터) 검색이다.

키워드 검색: TF-IDF와 BM25

키워드 검색의 기본 생각은 두 가지다. 청크 안에 질문 단어가 많이 나올수록(TF, term frequency) 관련성이 높고, "하다", "있다"처럼 모든 문서에 흔한 단어보다 "E-2041", "펀치"처럼 드문 단어가 일치할수록(IDF, inverse document frequency) 더 중요하다. 이를 다듬은 BM25는 지금도 검색 엔진의 표준적인 기본 점수 함수다.

$$ \mathrm{BM25}(D,Q) = \sum_{q \in Q} \mathrm{IDF}(q)\cdot \frac{f(q,D)\,(k_1+1)}{f(q,D) + k_1\left(1 - b + b\,\frac{|D|}{\overline{|D|}}\right)}, \qquad \mathrm{IDF}(q) = \ln\!\left(1 + \frac{N - n_q + 0.5}{n_q + 0.5}\right) $$

$f(q,D)$: 청크 $D$에서 단어 $q$의 출현 수, $|D|$: 청크 길이, $\overline{|D|}$: 평균 길이, $N$: 전체 청크 수, $n_q$: $q$가 나오는 청크 수. $k_1$(보통 1.2~2.0)은 같은 단어가 반복될 때 점수가 포화되는 정도, $b$(보통 0.75)는 긴 청크를 얼마나 깎을지 정한다.

한국어는 띄어쓰기로 자르면 안 된다

한국어는 조사와 어미가 단어에 붙는다. 문서에는 "펀치의 마모", 질문에는 "펀치를 연마"라고 쓰면, 띄어쓰기 단위로 자른 "펀치의"와 "펀치를"은 다른 단어가 된다. 실무 검색 엔진은 형태소 분석기로 조사를 떼어 내지만, 간단하고 의외로 강력한 방법이 글자 2-그램(bigram)이다. "펀치를" → "펀치", "치를"로 자르면 "펀치"가 일치한다. 아래 미니 RAG가 이 방식을 쓴다.

임베딩 검색과 하이브리드

임베딩 검색은 "슬러리가 잘 안 나와요"라는 질문으로 "슬러리 유량 저하" 문서를 찾는 것처럼 표현이 달라도 뜻이 같으면 찾아낸다. 반면 제조 문서에 많은 코드·번호·고유명사(알람 E-2041, 품번 12345-A, LOT A2603-L2-0414)는 임베딩이 잘 구별하지 못하는 경우가 많다. 그래서 둘을 함께 쓰는 하이브리드 검색이 실무 기본값이 되었다. 두 결과 목록을 합치는 간단하고 널리 쓰이는 방법이 순위 역수 결합(RRF)이다.

$$ \mathrm{RRF}(d) = \sum_{i \in \{\text{키워드},\,\text{벡터}\}} \frac{1}{k + \mathrm{rank}_i(d)} $$

$\mathrm{rank}_i(d)$: 검색 방식 $i$에서 문서 $d$의 순위. $k$는 상위 몇 개에 과도하게 쏠리지 않게 하는 상수로, 60이 흔히 쓰인다. 점수의 척도가 달라도 순위만으로 합칠 수 있다는 것이 장점이다.

마지막으로 재순위화(reranking)는 1차 검색으로 뽑은 후보 20~50개를, 질문과 청크를 함께 읽는 더 정밀한(대신 느린) 모델로 다시 정렬해 상위 몇 개만 LLM에 넘기는 단계다.

방식	강점	약점	제조 문서 예
키워드(BM25)	코드·번호·고유명사 정확 일치, 설명 가능, 빠름	동의어·다른 표현에 약함	"E-2041", "SOP-QC-012", "PR-07"
임베딩(벡터)	표현이 달라도 뜻으로 찾음, 다국어	정확한 코드 구별에 약함, 왜 걸렸는지 설명이 어려움	"슬러리가 잘 안 나옴" → "유량 저하"
하이브리드 + 재순위화	둘의 장점 결합, 실무 기본값	구성 요소가 늘어 튜닝·평가 필요	대부분의 사내 문서 검색
동의어 사전 확장	사내 은어·약어 해결	사전 유지 관리 필요	"긁힘" → SCR-01 (4장)

브라우저 안의 미니 RAG

아래는 가상의 A사 문서 13건(품질 보고서, 설비 매뉴얼, 회의록, 8D 요약, 메일 요약, 작업 표준서)을 문단 단위로 청킹해 BM25로 검색하는 작은 RAG다. 실제 LLM 대신, 상위 청크에서 질문과 가장 많이 겹치는 문장을 뽑아 출처 번호를 붙이는 추출식 답변으로 생성 단계를 흉내 낸다. 모든 계산은 이 페이지 안에서 일어나며 어떤 서버에도 전송되지 않는다.

먼저 프리셋 질문을 눌러 보고, 사용자 역할을 바꿔 같은 질문의 결과가 어떻게 달라지는지 확인해 보자. 설비 엔지니어로 "NC-5 양산 일정"을 물으면 연구소 대외비 문서는 검색 대상에서 아예 빠진다. "폐기된 문서 포함"을 켜고 CMP 패드 교체 기준을 물으면 개정 2판의 옛 수치가 섞여 들어오는 것도 볼 수 있다.

INTERACTIVE

미니 RAG — 검색, 근거, 권한

사용자 역할 상위 k개 청크 폐기된 문서도 포함(위험) 권한 필터 끄기(사고 재현용)

검색 대상 청크—

권한으로 제외된 관련 문서—

1위 BM25 점수—

응답 상태—

토크나이저: 한글은 글자 2-그램, 영문·숫자 코드는 통째로(하이픈이 있으면 조각도 함께). 청크 색인에는 문서 제목을 앞에 붙였다. 노란 표시는 질문과 일치한 2-그램이다. 질문 단어의 25% 미만만 근거에서 확인되면 답하지 않는다(환각 방지 규칙의 단순화). 문서와 수치는 모두 교육용 가상 자료다.

권한, 최신성, 출처: 믿을 수 있는 RAG의 세 조건

권한(ACL)은 검색 전에 건다

사내 RAG의 가장 큰 사고는 틀린 답이 아니라 보면 안 되는 답이다. 생산 작업자가 물었는데 경영 회의록의 투자 결정이나 연구소 대외비 일정이 근거로 나오면, 그 순간 문서 보안 체계가 무력화된다. 원칙은 단순하다. 원본 저장소의 접근 권한(ACL)을 색인에 그대로 복제하고, 사용자가 볼 수 있는 청크 안에서만 검색한다.

위험한 설계

모든 문서를 하나의 색인에 넣고 검색 → 생성 후 "답변에서 민감 정보 가리기"
LLM에게 "권한 없는 내용은 말하지 마"라고 프롬프트로 지시
권한 변경(퇴사·전보)이 색인에 반영되지 않음

안전한 설계

검색 단계에서 사용자 그룹으로 먼저 필터 → 볼 수 없는 청크는 후보에도 오르지 않음
권한은 원본 시스템이 진실의 원천, 색인은 주기적으로 동기화
질문·검색 결과·답변을 감사 로그로 남김(12장)

프롬프트로 "말하지 마"라고 지시하는 방식은 프롬프트 주입 같은 공격이나 모델의 실수에 취약하다. LLM에게 건네지 않은 정보는 새어 나갈 수 없다. 이것이 필터를 생성 뒤가 아니라 검색 앞에 두는 이유다.

최신성: 폐기된 문서가 현행 문서를 이기는 순간

미니 RAG에서 "폐기된 문서 포함"을 켜면 CMP 패드 교체 기준으로 "800매"(개정 2판)와 "500매"(개정 3판)가 함께 나온다. 키워드 점수만으로는 어느 쪽이 현행인지 알 수 없다. 문서 상태(현행/폐기), 개정 번호, 시행일을 메타데이터로 관리하고, 기본 검색에서는 현행만, 이력 조회가 필요할 때만 구버전을 포함하게 한다. 같은 주제의 문서가 여럿이면 최신 개정본에 가산점을 주는 규칙도 흔히 쓴다.

출처 표시: "어디에 그렇게 써 있어?"에 답하기

현장 엔지니어는 AI의 답을 그대로 믿지 않는다. 그래야 한다. 답의 각 문장에 근거 청크 번호를 붙이고, 클릭하면 원문의 해당 위치가 열리게 하면 검증 비용이 크게 줄어든다. 근거가 없으면 "찾지 못했다"고 말하게 하는 것도 출처 설계의 일부다. 모르는 것을 모른다고 말하는 RAG가 그럴듯하게 지어내는 RAG보다 훨씬 오래 쓰인다.

GraphRAG, 지식 그래프, 롱 컨텍스트: 언제 무엇을

청크 검색 기반 RAG는 "답이 문서 어딘가에 한두 문단으로 적혀 있는" 질문에 강하다. 하지만 이런 질문은 어렵다. "협력사 D사의 레진 등급 변경이 영향을 줄 수 있는 고객 제품과, 그 제품의 최근 클레임 이력은?" 답이 한 문서에 있지 않고, 메일(레진 변경) → BOM(레진을 쓰는 부품) → 출하 기록(고객) → 8D 보고서(클레임)로 관계를 여러 번 건너야 한다.

그림 6-3. 문서에서 개체(원자재, 부품, 고객, 불량, 문서)와 관계를 추출해 지식 그래프로 연결하면, 여러 문서에 흩어진 사실을 관계를 따라 이어 붙일 수 있다. 개체 이름이 4장의 정준 코드로 정리되어 있어야 노드가 하나로 합쳐진다.

GraphRAG는 문서에서 개체와 관계를 추출해 그래프를 만들고, 검색할 때 그래프의 연결 구조와 요약을 함께 활용하는 접근의 총칭이다. 2024년 Microsoft 연구진이 같은 이름의 방법을 공개하면서 널리 알려졌다. 이미 BOM, 설비 계층, LOT 계보처럼 관계가 정형 데이터로 존재한다면, 문서에서 추출하기 전에 그것부터 그래프로 연결하는 편이 훨씬 정확하다.

롱 컨텍스트 모델은 수십만 토큰을 한 번에 읽을 수 있어 "RAG가 필요 없어지는가"라는 질문이 자주 나온다. 매뉴얼 한 권 전체를 넣고 묻는 것은 실제로 좋은 방법이 될 수 있다. 하지만 회사 문서 전체는 여전히 어떤 컨텍스트보다 크고, 매 질문마다 전부를 넣는 것은 비용과 지연이 크며, 권한 필터와 최신성 판단은 어차피 검색 단계에서 해야 한다. 또한 긴 입력의 중간에 있는 정보를 모델이 덜 활용하는 경향이 연구로 보고된 바 있다. 실무에서는 검색으로 후보 문서를 좁히고, 좁힌 문서는 넉넉하게 통째로 넣는 조합이 많이 쓰인다.

질문 유형	예	잘 맞는 방식
사실 조회(한 문서 안)	"E-2041 조치 순서는?"	하이브리드 RAG
코드·번호로 찾기	"SOP-QC-012의 스크래치 기준"	키워드(BM25) + 메타데이터 필터
한 문서 깊이 읽기	"이 8D 보고서의 약점은?"	롱 컨텍스트(문서 통째로)
관계를 건너는 질문	"레진 변경의 영향 고객과 클레임 이력"	지식 그래프 / GraphRAG + 정형 데이터
집계·통계	"지난 분기 SCR-01 건수"	RAG가 아니라 데이터베이스 질의(5장)
전체 경향 요약	"올해 설비 회의록의 주요 이슈"	그래프 기반 요약 또는 문서별 요약의 계층 요약

"지난 분기 불량 몇 건?"은 RAG에게 묻지 말 것

RAG는 문서 조각을 찾아 읽는 방식이라 숫자를 세는 일에 약하다. 집계 질문은 정형 데이터(골드 테이블)에 대한 질의로 보내고, 문서 질문만 RAG로 보내는 라우팅이 필요하다. 에이전트가 이 판단을 하게 만드는 방법은 10장에서 다룬다.

RAG 평가: 감이 아니라 숫자로

RAG를 시연하면 대개 잘 되는 질문 몇 개를 보여 준다. 운영에 들어가면 사용자는 시연과 전혀 다른 질문을 한다. 그래서 실제 현업 질문으로 평가 세트(golden set)를 만들고, 바꿀 때마다 같은 세트로 점수를 재야 한다. 평가는 두 층으로 나눈다.

RETRIEVAL

검색 품질

재현율@k(정답 문서가 상위 k개 안에 있는 비율), MRR(첫 정답 순위의 역수 평균). 검색이 못 찾으면 LLM이 아무리 좋아도 답할 수 없다.

GENERATION

답변 품질

정확도(답이 맞는가), 근거성(답의 각 주장이 검색된 근거에 실제로 있는가), 인용 정확도, 그리고 근거가 없을 때 거절하는가.

OPERATION

운영 지표

응답 시간, 질문당 비용, "도움 안 됨" 피드백 비율, 근거 원문 클릭률, 권한 위반 0건.

아래 벤치는 미니 RAG의 문서로 만든 평가 질문 12개다. 질문은 일부러 문서와 다른 어미·조사로 썼다. 토크나이저와 점수 함수를 바꿔 가며 재현율@k와 MRR이 어떻게 달라지는지 보자. 평가는 권한 필터 없이(관리자 관점) 현행 문서만으로 했다.

$$ \mathrm{Recall@}k = \frac{1}{|Q|}\sum_{q\in Q} \mathbb{1}\left[\text{정답 문서} \in \text{상위 }k\right], \qquad \mathrm{MRR} = \frac{1}{|Q|}\sum_{q\in Q} \frac{1}{\mathrm{rank}_q} $$

여기서는 질문당 정답 문서가 하나 이상 있고, 그중 하나라도 상위 k 청크 안에 있으면 적중으로 센다. $\mathrm{rank}_q$는 첫 정답 청크의 순위(못 찾으면 0으로 계산).

INTERACTIVE

검색 평가 벤치 — 토크나이저와 점수 함수 비교

토크나이저

점수 함수

상위 k 동의어 사전으로 질문 확장

재현율@k—

MRR—

놓친 질문—

막대는 네 가지 조합(토크나이저 × 점수 함수)의 재현율@k를 한꺼번에 보여 주고, 현재 선택을 강조한다. 띄어쓰기 토크나이저는 "펀치를"과 "펀치"를 다른 단어로 보기 때문에 한국어 질문에서 크게 떨어진다. 동의어 사전 확장은 "구부러짐"→"휨", "흠집"→"스크래치"처럼 사내 표현을 질문에 덧붙이는 단순한 규칙이다. 질문 12개짜리 장난감 벤치이므로 차이는 경향으로만 읽자. 이렇게 작은 문서 집합에서는 BM25와 TF-IDF가 거의 같은 결과를 내며, 차이는 청크 길이가 제각각인 큰 색인에서 커진다. 실제 평가 세트는 현업 질문 수십~수백 개로 만든다.

도입 체크리스트

대상 문서 범위를 정했고, 중복·구버전·개인 사본을 정리했다(정보 인벤토리, 2장).
문서 유형별 파싱 품질을 샘플 검수했다(특히 스캔 PDF, HWP, 표가 많은 엑셀).
문서 유형·부서·개정 번호·상태·보안 등급·ACL 메타데이터를 추출한다.
권한 필터가 검색 단계에서 적용되고, 원본 권한과 주기적으로 동기화된다.
키워드와 벡터를 함께 쓰고, 사내 동의어 사전(4장)을 검색에 연결했다.
답변의 문장마다 출처가 붙고, 근거가 없으면 거절한다.
현업 질문 50개 이상으로 평가 세트를 만들고, 변경 때마다 재현율·근거성을 잰다.
집계·통계 질문은 RAG가 아니라 데이터 질의로 보낸다.

핵심 정리

RAG는 질문마다 사내 문서에서 근거를 찾아 LLM에게 건네는 방식이다. 재학습 없이 최신 문서를 반영하고, 답에 출처를 붙일 수 있다.
실패의 대부분은 생성이 아니라 앞 단계에서 시작된다. 파싱(PDF·PPT·엑셀·HWP·스캔·메일), 메타데이터, 문서 정리가 품질의 상한을 정한다.
청크가 작으면 맥락이 잘리고, 크면 잡음이 섞인다. 구조 기반 청킹 + 제목 붙이기 + 적당한 오버랩이 출발점이며, 문서 유형별로 다르게 자른다.
BM25는 드문 단어 일치에 가중치를 주는 키워드 점수다. 한국어는 띄어쓰기 대신 형태소 분석이나 글자 2-그램으로 자른다. 코드·번호에는 키워드, 표현 차이에는 임베딩 — 하이브리드(RRF)와 재순위화가 실무 기본값이다.
권한(ACL)은 검색 전에 걸어야 한다. LLM에게 건네지 않은 정보는 새지 않는다. 문서 상태·개정 번호로 최신성을 관리하고, 근거가 없으면 답하지 않게 한다.
관계를 여러 번 건너는 질문은 지식 그래프·GraphRAG, 한 문서 깊이 읽기는 롱 컨텍스트, 집계는 데이터베이스 질의가 맞다.
RAG는 현업 질문으로 만든 평가 세트로 검색(재현율@k, MRR)과 생성(정확도, 근거성, 거절)을 나눠 숫자로 관리한다.

확인 퀴즈

1. 한국어 문서 검색에서 띄어쓰기 단위 대신 글자 2-그램(또는 형태소 분석)을 쓰는 주된 이유는?

한국어는 교착어라 같은 명사에 여러 조사가 붙는다. 2-그램으로 자르면 "펀치를" → "펀치"·"치를"이 되어 "펀치"가 일치한다. 대신 색인은 커지고 "치를" 같은 잡음 조각이 생기므로, IDF와 불용 2-그램 처리로 보완한다.

2. BM25에서 IDF 항이 하는 역할은?

IDF는 단어가 등장하는 청크 수가 적을수록 커진다. 그래서 어디에나 있는 "하다"보다 특정 문서에만 있는 알람 코드나 설비 ID의 일치가 점수를 크게 좌우한다. 길이 보정은 $b$, 반복 포화는 $k_1$이 담당한다. 동의어는 BM25가 해결하지 못해 임베딩이나 동의어 사전이 필요하다.

3. 사내 RAG에서 권한(ACL)을 적용하는 위치로 가장 안전한 것은?

LLM에게 건네지 않은 정보는 새어 나갈 수 없다. 프롬프트 지시나 사후 마스킹은 모델의 실수나 프롬프트 주입에 뚫릴 수 있다. 원본 권한을 색인에 복제하고 주기적으로 동기화하는 것이 기본이다.

4. 청크 크기를 지나치게 크게 잡았을 때 생기는 주된 문제는?

맥락이 잘리는 것은 청크가 너무 작을 때의 문제이고, 청크 수가 늘어나는 것은 작은 청크나 큰 오버랩의 비용이다. 큰 청크는 집중도(정밀도)를 떨어뜨린다. 청크 크기 실험에서 최적점이 답에 필요한 맥락 길이에 따라 달라지는 것을 확인할 수 있다.

5. 사용자가 "E-2041"이라는 알람 코드만 입력했다. 임베딩 검색만 쓰는 시스템보다 하이브리드 검색이 유리한 이유는?

제조 문서에는 알람 코드, 품번, LOT ID, 설비 ID처럼 한 글자만 달라도 다른 대상인 식별자가 많다. 키워드 검색은 이런 정확 일치에 강하고 왜 걸렸는지 설명도 쉽다. 임베딩은 표현이 다른 질문에 강하므로 둘을 RRF 등으로 합친다.

6. "협력사의 레진 등급 변경이 영향을 줄 수 있는 고객 제품과 그 제품의 최근 클레임 이력"을 묻는 질문에 가장 잘 맞는 접근은?

답이 여러 문서·시스템에 흩어져 있고 관계를 여러 번 건너야 하는 질문이다. 비슷한 글을 찾는 벡터 검색보다 연결된 것을 따라가는 그래프 탐색이 맞다. BOM과 출하처럼 이미 정형 데이터로 있는 관계는 문서 추출보다 그대로 그래프에 연결하는 것이 정확하다.