복습 음성 · 45분 13초 · RAG Family · 18장 · 파일에 1.1배속 적용

RAG의 기본 흐름은 문서를 준비해 질문과 관련된 조각을 찾고 답변의 근거로 건네는 것이다. 검색에서 엉뚱한 자료가 선택되거나 필요한 조건이 빠지거나 생성한 답이 근거와 달라질 수 있다.

RAG Family의 개선 방법은 문제가 생기는 위치에 따라 나눌 수 있다. 질문 재작성, 여러 검색 결과의 결합, 문맥 압축, 반복 검색은 각각 바꾸는 단계가 다르다.

위 음성은 RAG Family 전체를 다루는 18장 구성의 복습용 생성 음성이다. 파일에 1.1배속이 적용돼 있으므로 플레이어는 1.0배속으로 두면 된다. 본문은 개념과 설명용 예시를 다룬다. 아래 카페 규정과 검색 순위는 이해를 돕기 위해 만든 가상 자료다.

1. 관련된 문서를 찾았는데도 답이 틀리는 이유

Naive RAG(기본 RAG)는 문서를 나누고 저장한 뒤, 질문에 맞는 조각을 검색해 LLM(Large Language Model, 대규모 언어 모델)에 전달한다. 벡터 검색은 텍스트의 의미적 관련성을 비교할 수 있다. 다만 관련성이 높아도 질문에 답할 근거가 빠져 있을 수 있다.

카페 직원이 “휴일에도 무료 음료를 받을 수 있나요?”라고 묻는다고 하자. 검색 결과에 직원 할인 규정이 들어왔다. 직원 혜택이라는 주제는 맞지만 무료 제공과 휴일 적용 여부를 알려면 그 조건이 적힌 문장이 필요하다.

검색에서는 Precision(정밀도)과 Recall(재현율)을 나눠 본다. 다섯 조각을 가져왔고 그중 세 조각이 관련 있다면 정밀도는 3/5다. 저장소 전체의 관련 조각이 여섯 개라면 재현율은 3/6이다. 가져온 결과의 비율과 찾아야 할 자료 중 찾은 비율을 각각 계산한다.

생성 단계에서는 다른 문제가 생긴다. 모델이 할인 규정과 무료 제공 규정을 섞거나, 자료에 없는 적용일을 덧붙일 수 있다. 이런 근거 없는 내용을 사실처럼 생성하는 현상을 Hallucination(환각)이라고 한다. 자료 자체의 편향, 여러 문서의 충돌, 반복되는 문장도 답변에 영향을 준다.

따라서 답을 볼 때는 두 가지를 확인한다. 필요한 조건을 검색했는지, 답변이 그 조건을 정확히 사용했는지다.

2. Naive·Advanced·Modular RAG는 무엇을 바꾸나

구분 살펴보는 부분 카페 예시
Naive RAG 문서 준비 → 검색 → 생성의 기본 흐름 직원 규정을 찾아 답변에 넣는다.
Advanced RAG 인덱싱과 검색 전후의 품질 개선 시행일로 거르고 질문을 다시 쓰고 결과 순위를 조정한다.
Modular RAG 기능을 나누고 연결·분기·반복을 구성 규정은 문서 검색으로, 매출 합계는 데이터베이스 조회로 보낸다.

Advanced RAG(고도화된 RAG)는 기본 흐름에서 검색 품질을 손보는 관점이다. Indexing(인덱싱)에서는 문서의 단위와 구조를 정리한다. Pre-retrieval(검색 전 처리)에서는 질문을 명확히 만들고 검색 대상을 좁힌다. Post-retrieval(검색 후 처리)에서는 찾은 결과를 다시 평가하고 답변에 넣을 문맥을 정리한다.

Modular RAG(모듈형 RAG)는 검색기, 생성기, 라우터 같은 기능을 나눠 연결하는 관점이다. 질문에 따라 경로를 바꾸거나, 여러 검색을 병렬로 수행하거나, 근거가 부족하면 앞 단계로 돌아갈 수 있다. 조건 분기와 반복을 포함하는 구조는 Modular RAG 논문에서도 다룬다.

세 이름을 성능 순위로 외우기보다는 지금 어떤 부분을 바꾸는지에 붙여보면 이해하기 쉽다. 질문 재작성과 리랭킹을 사용하는 시스템을 모듈로 나눠 구성할 수도 있다. RAG Survey

3. 문서를 나눌 때 검색 단위와 답변 단위를 구분한다

Chunking(청킹)은 문서를 검색할 조각으로 나누는 작업이다. “직원은 하루 한 잔을 무료로 받는다”와 “근무일에 한한다”가 떨어지면 조건을 놓칠 수 있다. 반대로 규정 전체를 하나로 저장하면 질문과 무관한 내용까지 따라온다.

Sliding Window(슬라이딩 윈도우)는 조각 사이에 일부 내용을 겹치게 남긴다. 경계 주변의 문맥을 보존하는 데 도움이 되지만 검색 결과에 중복이 늘 수 있다. Semantic Chunking(의미 기반 청킹)은 문장 사이의 의미 변화를 이용해 경계를 잡는다. 분할 결과가 원문의 조건과 예외를 함께 담는지 직접 읽어볼 필요가 있다.

Small-to-Big(작은 단위 검색 후 문맥 확장)는 찾는 단위와 읽히는 단위를 다르게 둔다. 짧은 자식 조각으로 검색하고 연결된 부모 문단이나 절을 답변 문맥으로 가져온다. “근무일에 한한다”를 찾았다면 무료 제공 대상과 수량이 적힌 앞 문장도 함께 건네는 식이다.

Hierarchical Index(계층형 인덱스)는 요약과 상세 내용을 연결한다. 먼저 문서나 절의 요약에서 범위를 좁히고 상세 조각으로 내려갈 수 있다. 검색된 자식의 부모를 확장하는 방식과, 상위 요약부터 아래로 탐색하는 방식을 구분해두면 흐름을 읽기 편하다.

4. 메타데이터와 데이터 형식이 검색을 바꾼다

Metadata(메타데이터)에는 출처, 제목, 작성일, 시행일, 버전, 지점 같은 정보를 담는다. 같은 규정의 구버전과 신버전이 함께 있다면 문장 유사도만으로 선택하기 어렵다. 적용 날짜와 지점을 먼저 좁히면 검색할 범위가 줄어든다.

Time-aware RAG(시간을 고려한 RAG)에서는 질문의 기준 시점과 자료의 유효 기간을 함께 본다. “작년 휴일 규정”을 묻는 질문에는 당시 시행되던 문서가 필요하다. 최신 문서에 높은 가중치를 주는 설정도 질문의 시간 조건에 맞춰야 한다.

문서로부터 예상 질문을 미리 만들어 원문과 연결해둘 수도 있다. 무료 음료 규정에 “휴일에도 무료인가?”라는 질문을 붙여두고 사용자 질문과 비교하는 방식이다. 학습 자료에서 Reverse HyDE(역방향 HyDE)로 소개한 아이디어다. 예상 질문과 요약은 검색을 돕는 표현이며 실제 답변의 조건은 연결된 원문에서 확인한다.

자료의 형태에 따라서도 읽는 방법이 달라진다.

데이터 준비할 때 볼 것 검색·조회 방법의 예
Unstructured Data(비정형 데이터) 문장과 문단의 경계, 출처 안내문·설명서의 텍스트 검색
Semi-structured Data(반정형 데이터) 제목, 표의 행·열, 문서 배치 표를 구조화하거나 설명문으로 변환
Structured Data(정형 데이터) 열의 의미, 키, 관계, 자료형 SQL 조회나 지식 그래프 탐색

PDF는 파일 형식이므로 안에 무엇이 있는지부터 본다. 본문과 표, 스캔 이미지가 섞여 있으면 추출 방법도 달라진다. 표를 문장으로 풀 때는 행 이름, 열 이름, 단위를 함께 보존한다. Vision Language Model(시각 언어 모델)로 페이지를 읽는 방법도 있지만 작은 숫자와 복잡한 표는 원문 대조가 필요하다.

Text-to-SQL(자연어를 SQL로 변환)은 구조화된 표를 조회하는 방법이다. TableGPT 같은 연구는 표를 다루는 모델의 방향을 보여준다. “지난달 매출 합계”를 묻는다면 날짜 조건과 합계 대상 열을 정해 조회하고 그 결과를 답변에 사용한다.

5. 질문을 다시 쓰고 나누고 검색 경로를 정한다

“쉬는 날도 돼요?”라는 질문만으로는 무엇을 찾을지 모호하다. 앞선 대화가 직원 음료 혜택에 관한 것이었다면 “휴일에도 직원 무료 음료를 받을 수 있나요?”로 풀어 쓸 수 있다. Query Rewriting(질문 재작성)은 이렇게 생략된 대상을 복원하거나 검색에 맞는 표현으로 정리한다.

Multi-Query(다중 질문)는 같은 의도를 여러 표현으로 검색한다. “휴일 무료 음료”, “비근무일 직원 혜택”처럼 어휘를 바꾸면 한 표현으로 놓친 자료를 찾을 여지가 생긴다. 다만 원래 질문에 없던 조건까지 만들어 넣으면 검색 방향이 달라진다.

Sub-Query(하위 질문)는 복합 질문을 나눈다. “A지점과 B지점의 휴일 음료 혜택을 비교해줘”라면 각 지점의 적용 규정을 따로 찾고 비교한다. Least-to-Most(작은 문제부터 해결하기)는 이런 문제 분해를 이해하는 데 연결할 수 있다. 앞선 조회 결과가 다음 질문을 결정하는 경우도 있다.

Step-back Prompting(상위 개념으로 물러서기)은 구체적인 질문과 관련된 일반 원리나 상위 개념을 함께 살핀다. Query2doc은 LLM이 만든 가상 문서를 원래 질문에 더해 검색 표현을 확장한다. 문서에 등장할 만한 어휘를 보충하는 방식이다. Query2doc 논문

질문에서 주요 Entity(개체)를 찾아 정의나 설명을 덧붙이는 방법도 있다. 이때 이름이 같은 다른 제품이나 지점을 연결하지 않도록 개체의 식별 정보를 확인한다.

Routing(라우팅)은 질문을 보낼 곳을 정한다. 지점 규정은 문서 저장소로, 매출 계산은 관계형 데이터베이스로 보낼 수 있다. 메타데이터 조건, 의미 유사도, LLM의 도구 선택 등으로 경로를 구성한다. 재작성 모델을 작게 두는 선택은 비용과 지연 시간을 줄이려는 방법 중 하나이며 질문 의도를 얼마나 잘 보존하는지도 함께 평가해야 한다.

6. RAG-Fusion은 여러 검색 목록의 순위를 합친다

RAG-Fusion은 질문을 여러 표현으로 만들고 각각 검색한 결과를 합친다. 이때 사용하는 RRF(Reciprocal Rank Fusion, 역순위 결합)는 문서가 각 목록에서 몇 위에 있었는지를 점수로 바꾼다. RAG-Fusion 논문

질문 → 여러 검색 질문 → 각 질문의 검색 결과
     → 같은 문서의 순위 점수 합산 → 상위 문서 → 답변

문서 점수 = 등장한 각 목록의 1 / (k + 순위)를 모두 더한 값

아래는 설명용으로 만든 두 검색 목록이다. 순위는 1부터 세고 상수 k는 60으로 둔다. 여기의 k는 최종 검색 결과 개수와 구분해야 한다.

문서 첫 번째 검색 두 번째 검색 RRF 점수
A 1위 3위 1/61 + 1/63 ≈ 0.03227
B 2위 1위 1/62 + 1/61 ≈ 0.03252
C 3위 없음 1/63 ≈ 0.01587
D 없음 2위 1/62 ≈ 0.01613

이 예에서는 B가 A보다 조금 높은 점수를 얻는다. 목록에 없는 문서는 그 목록에서 점수를 더하지 않는다. 같은 문서인지 판별할 ID도 필요하다.

RRF는 순위 정보를 이용한다. 질문과 문서의 본문을 다시 읽어 점수를 매기는 Reranker(리랭커)와 평가 방식이 다르다. 순위를 합친 뒤 별도의 리랭커를 둘 수도 있다. 여러 질문이 같은 오해를 담고 있으면 잘못된 결과가 함께 올라올 수 있으므로 원질문과의 관련성도 확인한다.

7. HyDE는 검색에 쓸 가상 문서를 만든다

HyDE(Hypothetical Document Embeddings, 가상 문서 임베딩)는 질문을 받은 LLM이 가상 답변 문서를 먼저 만들고 이를 임베딩해 실제 문서를 찾는 방법이다. 질문은 짧고 실제 문서는 설명문인 경우, 검색할 문서와 비슷한 표현을 중간에 만드는 셈이다. HyDE 논문

질문 → 가상 문서 생성 → 가상 문서 임베딩
     → 실제 문서 검색 → 검색된 근거로 답변

“휴일에도 무료 음료를 받을 수 있나요?”에 대해 모델이 직원 음료 제공 기준을 설명하는 글을 만든다고 하자. 그 글에 들어간 “적용 대상”, “근무일”, “제공 기준” 같은 표현이 검색에 쓰일 수 있다.

가상 문서의 조건과 수치는 모델이 지어낸 것일 수 있다. 따라서 최종 답변의 근거는 검색한 실제 규정에서 가져온다. 가상 문서가 엉뚱한 조건을 강조하면 검색 결과도 빗나갈 수 있고 생성 호출에 따른 시간과 비용도 추가된다.

HyDE와 앞서 본 Query2doc을 구분할 때는 생성 문서가 들어가는 위치를 본다. HyDE는 가상 문서의 임베딩으로 실제 코퍼스를 탐색한다. Query2doc은 생성한 문서로 원래 질문의 검색 표현을 확장한다.

8. Self-RAG는 검색과 근거 평가를 학습한다

Self-RAG는 검색 필요성과 검색 결과, 생성한 답변을 평가하는 Reflection Tokens(성찰 토큰)를 생성하도록 모델을 학습하는 방법이다. 원논문에서는 검색 여부, 문서 관련성, 답변의 근거 충실도와 유용성을 다룬다. 이 점에서 일반 모델에 자기검토 문장을 덧붙이는 방식과 구현 조건을 구분해야 한다. Self-RAG 논문

카페 규정을 묻는 질문이라면 외부 문서가 필요한지 판단하고 찾은 규정이 질문과 관련 있는지 살핀다. 답변에 “휴일에도 무료”라고 썼다면 문서가 그 내용을 뒷받침하는지도 평가한다. 추론 때는 성찰 토큰의 신호를 이용해 출력 후보를 선택하거나 행동을 조절할 수 있다.

평가를 모델이 맡는 만큼 그 평가도 틀릴 수 있다. 실제로 사용할 자료와 질문으로 검색 누락, 잘못된 인용, 근거 밖 주장을 점검해야 한다. 검색 호출 수가 줄어드는 경우와 평가 계산이 늘어나는 경우를 함께 봐야 비용을 비교할 수 있다.

CoVe(Chain-of-Verification, 검증의 연쇄)는 초안을 만든 뒤 검증 질문을 계획하고 그 질문에 독립적으로 답한 다음 최종 응답을 작성하는 연구다. 답변 검증의 흐름으로 이해할 수 있다. 확장 검색 질문을 검사하는 기능으로만 외우면 연구의 범위를 좁게 이해하게 된다. CoVe 논문

9. 키워드 검색과 임베딩 검색을 함께 본다

Dense Retrieval(밀집 벡터 검색)은 표현이 달라도 의미가 가까운 자료를 찾는 데 쓰인다. 하지만 제품 번호처럼 한 글자 차이가 중요한 질문에서는 정확한 식별자를 확인해야 한다. AB-120을 찾는 질문에 비슷한 설명의 AB-210 문서가 들어오면 답변 근거로 쓰기 어렵다.

BM25는 단어의 출현과 문서 내 빈도 등을 이용하는 키워드 검색 방법이다. Hybrid Search(하이브리드 검색)는 이런 검색과 벡터 검색의 결과를 함께 활용한다. 서로 다른 점수를 단순히 더하기 전에 점수의 범위를 맞추거나 RRF처럼 순위를 결합하는 방법을 선택한다.

임베딩 모델이 업무 분야의 표현을 충분히 구분하는지도 살펴본다. Fine-tuning(미세조정)으로 질문과 관련 문서의 관계를 학습시키는 도메인 적응을 고려할 수 있다. 우선 실패한 질문이 용어 차이 때문인지, 문서 추출이나 청킹 때문인지 확인해야 변경 대상을 정하기 쉽다.

REPLUG는 언어 모델을 고정한 채 검색한 문서를 입력에 붙여 활용하고 언어 모델의 예측 신호로 검색기를 학습하는 방법도 제안한다. 검색 문서가 실제 생성에 얼마나 도움이 되는지를 검색기 학습에 연결하는 관점이다. 운영 중 매 질문마다 자동으로 가중치가 갱신된다고 가정하면 안 된다. REPLUG 논문

10. 검색한 문서를 고르고 압축한다

검색 후보를 넉넉히 모은 다음 Reranking(리랭킹)으로 질문과의 관련성을 다시 평가할 수 있다. 예를 들어 후보 50개에서 답변에 넣을 5개를 고르는 구성이다. 이 숫자는 설명용이며 실제 개수는 검색 누락과 지연 시간을 함께 보며 정한다. 리랭커가 이미 빠진 문서를 되살릴 수는 없으므로 첫 검색의 범위도 중요하다.

문서를 고른 뒤에는 Context Compression(문맥 압축)으로 필요한 부분을 남긴다. 무료 음료의 대상과 적용일을 남기고 같은 페이지의 유니폼 안내를 덜어내는 식이다. 압축 결과에서도 예외, 부정 표현, 단위와 날짜가 보존됐는지 확인한다.

LLMLingua는 프롬프트 압축을 연구한 방법이다. RECOMP는 유용한 문장을 고르는 추출형 압축과 여러 문서를 종합해 요약하는 생성형 압축을 제안한다. 검색 자료가 도움이 되지 않을 때 빈 결과를 반환하는 선택적 증강도 다룬다. LLMLingua 논문, RECOMP 논문

Lost in the Middle(긴 문맥 중간의 정보 활용 저하) 연구에서는 답에 필요한 정보의 위치에 따라 성능이 달라지는 현상을 관찰했다. 입력에 자료가 들어 있다는 사실과 모델이 그 자료를 제대로 활용한다는 사실을 나눠 봐야 한다. 문서의 개수와 순서, 압축 정도를 바꿔 비교할 이유가 여기에 있다. 모델과 과제에 따른 차이도 함께 확인한다. Lost in the Middle 논문

작은 모델이 쉬운 사례를 처리하고 큰 모델이 어려운 후보를 평가하는 구성도 가능하다. 학습 자료에 나온 Filter-then-Rerank(필터 후 재평가)의 인용 논문은 정보 추출 과제를 연구했다. RAG에 이 구성을 적용하려면 검색·답변 과제에서 별도로 확인해야 한다. Filter-then-Rerank 논문

11. 여러 문서를 답변으로 묶는 네 가지 방식

문서 순위를 정한 뒤에도 여러 조각을 어떻게 모델에 읽힐지 선택해야 한다. Stuff, Refine, Map-Reduce, Map-Rerank는 이 문서 결합과 답변 구성의 흐름을 설명하는 이름이다.

방식 처리 흐름 살펴볼 점
Stuff(한꺼번에 넣기) 문서를 한 입력에 모아 답변을 만든다. 입력 길이와 불필요한 문맥을 확인한다.
Refine(차례로 수정하기) 첫 문서로 만든 답을 다음 문서로 갱신한다. 문서 순서와 앞선 답의 오류가 영향을 준다.
Map-Reduce(개별 처리 후 통합) 문서별 결과를 만든 뒤 종합한다. 통합 전에 조건이나 연결 관계가 빠질 수 있다.
Map-Rerank(답변 후보 평가) 문서별 답과 점수를 만든 뒤 후보를 고른다. 여러 문서의 근거를 합쳐야 하는 질문을 놓칠 수 있다.

Map-Rerank는 문서마다 만든 답변 후보를 평가한다. 앞 절의 문서 리랭킹은 생성에 넣을 문서의 우선순위를 정한다. 무엇에 점수를 붙이는지 보면 차이가 드러난다.

Map 단계는 병렬로 처리할 수 있지만 전체 호출 수와 입력량은 늘 수 있다. Refine은 앞선 답을 다음 단계가 받아야 하므로 순차 처리가 필요하다. 실행 시간을 비교할 때는 동시 호출 제한과 마지막 통합 단계까지 포함한다.

12. Modular RAG에서는 모듈과 연결 방식을 읽는다

Search(검색) 모듈은 문서 저장소, 검색 엔진, 관계형 데이터베이스, 지식 그래프 같은 자료원을 다룬다. Memory(메모리) 모듈은 이전 대화나 작업 결과를 다음 검색에 활용할 수 있게 관리한다. 메모리에 저장한 내용도 출처와 갱신 시점, 보존 범위를 정해야 한다.

Routing은 질문의 경로를 정하고 Predict(예측) 모듈은 필요한 문맥이나 답변 후보를 먼저 만들어볼 수 있다. Task Adapter(작업 적응 모듈)는 과제에 맞는 프롬프트나 검색 구성을 선택한다. 각 모듈의 입력과 출력을 정해두면 검색기를 바꾸더라도 뒤에서 기대하는 자료 형식을 맞추기 쉽다.

연결 패턴도 따로 본다. Rewrite-Retrieve-Read는 질문을 재작성하고 검색하고 읽어 답하는 흐름이다. DSP(Demonstrate-Search-Predict)는 예시 활용·검색·예측을 조합하며 ITER-RETGEN은 검색과 생성을 반복해 앞선 생성 결과를 다음 검색에 활용한다.

질문
  → 라우팅
    → 규정 질문: 문서 검색 → 근거 정리
    → 합계 질문: 데이터베이스 조회 → 계산 결과
  → 답변 생성 → 근거 확인
    → 충분하면 종료
    → 부족하면 질문을 보완해 다시 검색

이 흐름은 개념을 설명하기 위한 구성도다. 모듈을 나누는 만큼 각 단계의 입력과 결과를 기록해야 잘못된 분기나 반복을 추적할 수 있다.

13. 생성한 문맥과 메모리도 출처를 구분한다

검색에 쓸 자료를 모델이 생성하는 연구도 있다. GenRead는 생성한 문맥을 활용해 질문에 답하는 접근이다. Selfmem은 생성 결과를 메모리 풀에 활용하며 SKR은 모델이 아는 질문과 추가 검색이 필요한 질문을 구분하려는 방향을 다룬다.

이런 구성에서 생성 문맥과 확인한 원문을 구별해두어야 한다. 모델이 만든 설명을 저장한 뒤 다시 검색하면, 같은 오류가 반복해서 근거처럼 사용될 수 있다. 어느 부분이 원문이고 어느 부분이 생성 결과인지 남겨야 나중에 되짚을 수 있다.

KnowledGPT는 지식 베이스에 접근하는 코드를 생성해 지식을 조회하고 저장하는 연구다. G-Retriever는 텍스트 속성을 가진 그래프의 검색과 Graph Neural Network(그래프 신경망) 표현을 언어 모델에 연결한다. 그래프를 사용하더라도 추출된 관계와 검색 결과의 정확성은 따로 확인한다.

검색한 지식이 부족할 때 생성한 문맥을 다시 다듬어 검색에 쓰는 Self-Refining Knowledge(지식 자기 정제) 아이디어도 같은 구분이 필요하다. Knowledge Distillation(지식 증류)은 큰 모델이 만든 자료로 작은 모델을 학습시키는 방향이다. 생성 자료의 오류와 편향이 학습으로 전달될 수 있으므로 자료를 고르는 기준이 중요하다.

14. 반복적·재귀적·적응형 검색을 구분한다

Iterative Retrieval(반복적 검색)은 검색과 생성을 여러 번 수행한다. 원두 납품 지연의 영향을 묻는다면 납품 현황을 찾고 그 결과에 등장한 매장의 재고 규정을 다시 찾는 식이다. 앞선 결과를 다음 질문에 반영한다. 여러 근거를 연결하는 Multi-hop(다단계 추론) 질문에서는 각 단계의 자료가 다음 단계와 어떻게 연결되는지도 확인한다.

Recursive Retrieval(재귀적 검색)은 검색 결과에 연결된 더 구체적인 자료를 따라가거나 질문을 단계적으로 좁힌다. 매뉴얼 요약에서 해당 절을 찾은 뒤 상세 문단으로 내려갈 수 있다. 사용하는 프레임워크에 따라 노드 참조를 따라가는 구현을 가리키기도 하므로 실제 연결을 확인한다.

Adaptive Retrieval(적응형 검색)은 언제 검색할지 결정한다. FLARE는 다음 문장을 미리 생성해 낮은 확신의 토큰이 있으면 그 문장으로 검색하고 다시 생성하는 접근이다. Self-RAG는 학습한 성찰 토큰을 활용한다. 토큰의 생성 확률과 문장의 사실성은 서로 다른 평가 대상이다.

반복에는 종료 조건이 필요하다. 필요한 근거가 모였는지, 같은 자료만 돌아오는지, 정한 호출 횟수와 시간을 넘었는지 확인한다. 검색을 더 했는데 새로운 근거가 없으면 추가 조회를 멈추고 현재 자료의 범위를 밝혀야 한다.

15. GraphRAG는 자료 사이의 관계를 검색에 사용한다

Graph RAG(그래프를 활용한 RAG)는 개체와 관계를 연결해 검색에 활용한다. Node(노드)에 개체를, Edge(간선)에 관계를 표현할 수 있다. “공급사 A → 원두 B → 매장 C”처럼 관계를 저장하면 공급사에 문제가 생겼을 때 연결된 원두와 매장을 따라갈 수 있다.

Knowledge Graph Index(지식 그래프 인덱스)는 이런 관계를 검색 가능한 구조로 만든다. KGP(Knowledge Graph Prompting)는 여러 문서의 구조와 연결을 그래프로 활용해 필요한 근거를 탐색하는 연구다. 관계마다 연결된 원문을 보존해야 잘못 추출한 연결을 확인할 수 있다.

Microsoft GraphRAG는 문서에서 개체와 관계를 추출하고 Community(커뮤니티)를 구성하고 커뮤니티 요약을 만든다. 커뮤니티는 서로 밀접하게 연결된 개체들을 묶은 그룹이다. Global Search(전체 관점 검색)는 이런 요약을 이용해 문서 전체의 주제를 다룬다. Local Search(개체 중심 검색)는 특정 개체와 주변의 관계·자료를 탐색한다. Microsoft GraphRAG 공식 문서

예를 들어 “이번 납품 보고서들에 공통으로 나타나는 문제는?”이라는 질문은 전체 자료를 묶어 살펴봐야 한다. “원두 B를 쓰는 매장은?”이라는 질문은 특정 개체의 연결에서 시작할 수 있다.

관계 추출과 요약 과정에도 오류가 생기고 문서가 바뀌면 그래프와 요약도 갱신해야 한다. 구축 비용을 들일 만큼 관계나 전체 주제를 묻는 질문이 많은지부터 확인한다.

16. Agentic RAG는 다음 행동을 선택한다

Agentic RAG(에이전트형 RAG)는 모델이 필요한 검색이나 도구를 선택하고 결과를 보고 다음 행동을 이어가도록 구성한다. 문서 검색, 웹 검색, SQL 조회처럼 역할이 다른 도구를 연결할 수 있다.

카페의 “납품 지연 때문에 이번 주 운영에 어떤 영향이 있나요?”라는 질문을 생각해보자. 납품 현황을 조회하고 해당 원두를 쓰는 매장을 찾고 재고 정보를 확인해야 한다. 앞서 얻은 정보에 따라 다음 조회 대상이 달라진다.

필요한 단계를 정하는 Planner(계획자)와 도구 호출을 수행하는 Executor(실행자)의 역할로 나눠 볼 수 있다. 두 역할을 하나의 흐름으로 구성할 수도 있다.

이때 State(상태)에는 원래 질문, 확인한 근거, 아직 부족한 정보, 수행한 도구 호출 등을 남긴다. 결과가 충분하면 답하고 부족하면 질문이나 검색 대상을 조정한다. 허용한 도구와 종료 조건도 구성에 포함한다.

GraphRAG는 지식의 관계와 검색 구조를, Agentic RAG는 어떤 도구를 언제 호출할지를 살펴보는 관점이다. 에이전트가 그래프 검색을 도구로 사용하는 식으로 둘을 함께 구성할 수 있다.

17. 실패한 질문에서 바꿀 지점을 찾는다

처음부터 모든 기법을 붙이면 무엇이 도움이 됐는지 구분하기 어렵다. 실패한 질문과 검색 결과를 읽고 한 단계씩 바꿔 비교하는 편이 낫다.

관찰한 문제 먼저 살펴볼 부분
규정의 예외 조건이 빠졌다. 청킹 경계, 부모 문맥 확장
옛날 규정이 나온다. 버전·시행일 메타데이터와 필터
제품 번호를 잘못 찾는다. 식별자 조건, 키워드·벡터 검색 결합
비슷한 문서가 반복된다. 중복 제거, 검색 결과 결합, 문맥 선택
질문을 여러 번 바꿔야 찾는다. 질문 재작성, Multi-Query, RAG-Fusion
근거를 찾았는데 답에 쓰지 않는다. 리랭킹, 입력 순서, 문맥 압축, 생성 지시
여러 문서의 관계를 따라가야 한다. 반복 검색, 계층·그래프 구조
질문마다 필요한 자료원이 달라진다. 라우팅과 도구 선택

비교할 때는 같은 질문과 문서 버전을 사용한다. 검색 단계에서는 필요한 근거가 들어왔는지, 생성 단계에서는 답이 근거와 맞는지 확인한다. 응답 시간과 호출 비용도 함께 기록해야 품질 개선의 대가를 알 수 있다.

자료 준비, 질문 처리, 근거 선택, 검색 흐름으로 나눠 보면 각 기법이 바꾸는 입력과 결과를 따라갈 수 있다. 문제를 발견한 단계와 개선할 단계를 연결해두면 다음 실습에서도 무엇을 비교할지 정하기 쉽다.

AIFFEL의 RAG Family 학습 자료와 개인 복습용 음성을 참고해 개념을 다시 설명했다. 주요 연구는 본문의 논문·공식 문서 링크에서 확인할 수 있다. 카페 사례와 순위 계산은 설명용이며 실제 서비스의 검색 성능이나 모델 답변 품질을 측정한 결과는 없다.