전처리부터 사후 검증까지: 단순 RAG의 한계를 넘어서는 심화 기술과 실전 구현 가이드입니다.
작성일: 2026년 8월 4일
목차
- 서론: 단순 RAG는 왜 한계에 부딪히는가
- Advanced RAG의 전체 아키텍처 이해
- 검색 전 단계 최적화: 쿼리 재작성과 라우팅
- 검색 단계 심화: 하이브리드 검색과 융합 검색
- 검색 후 단계 심화: 재순위화와 컨텍스트 압축
- 자기 성찰형 RAG: Self-RAG와 Corrective RAG
- 에이전틱 RAG: 검색을 에이전트 루프 내부로
- 설치 및 환경 구성 완전 가이드
- 종단 간 구현: Python 실습 코드
- 평가 방법론과 실전 고려사항
- 결론 및 향후 발전 방향
1. 서론: 단순 RAG는 왜 한계에 부딪히는가
검색 증강 생성(Retrieval-Augmented Generation, RAG)은 대규모 언어 모델의 환각(Hallucination) 문제를 완화하고 최신 정보 및 도메인 특화 지식을 응답에 반영하기 위한 표준적인 기법으로 자리 잡았습니다. 그러나 문서를 청크로 분할하고, 임베딩을 생성하여 벡터 데이터베이스에 저장한 뒤, 쿼리와 가장 유사한 상위 K개의 청크를 검색하여 언어 모델에 주입하는 단순한 형태의 “나이브 RAG(Naive RAG)”는 실제 프로덕션 환경에서 여러 구조적 한계를 드러냅니다.
2024년에 수행된 포괄적인 RAG 벤치마크 연구에 따르면, 고도화된 기법을 적용하지 않은 단순 검색 방식은 사실 관계 질의에 대해 44퍼센트 수준의 정답률에 그친 반면, 최신 고급 기법을 적용한 RAG 시스템은 63퍼센트 수준까지 정답률을 끌어올린 것으로 보고되었습니다. 이러한 격차는 검색 전 단계의 쿼리 처리, 검색 단계의 정확도, 검색 후 단계의 정제라는 파이프라인 전 구간에 걸친 체계적인 개선이 실질적인 성능 향상으로 이어진다는 것을 시사합니다.
이 기록에서는 Advanced RAG를 구성하는 핵심 기법들을 검색 전(Pre-Retrieval), 검색(Retrieval), 검색 후(Post-Retrieval)의 세 단계로 구분하여 체계적으로 설명하고, 나아가 모델이 스스로 검색 결과를 평가하고 재시도하는 자기 성찰형(Self-Reflective) 패턴과, 검색을 에이전트의 추론 루프 내부에 통합하는 에이전틱(Agentic) 패턴까지 박사 연구자의 관점에서 심층적으로 다루도록 하겠습니다.
2. Advanced RAG의 전체 아키텍처 이해
2.1 나이브 RAG와 Advanced RAG의 구조적 차이
나이브 RAG는 “쿼리 임베딩 생성 → 벡터 유사도 검색 → 상위 K개 청크 반환 → LLM 프롬프트 삽입”이라는 선형적이고 단방향적인 파이프라인으로 구성됩니다. 이 구조의 근본적 문제는 사용자의 쿼리가 항상 검색에 최적화된 형태로 입력된다는 비현실적인 가정에 있으며, 검색된 문서의 품질을 사후적으로 검증하는 절차가 전무하다는 점입니다.
Advanced RAG는 이러한 선형 파이프라인의 각 단계에 최적화 절차를 삽입한 확장된 구조입니다. 검색 전 단계에서는 쿼리 재작성과 라우팅을 통해 검색 품질을 사전에 개선하며, 검색 후 단계에서는 재순위화와 압축을 통해 언어 모델에 전달되는 컨텍스트의 정밀도를 높입니다.
2.2 세 단계 파이프라인 개요
| 단계 | 주요 기법 | 목적 |
|---|---|---|
| 검색 전 | 쿼리 재작성, 쿼리 확장, 쿼리 라우팅, HyDE | 검색에 최적화된 쿼리 형태로 변환 |
| 검색 | 하이브리드 검색, 융합 검색, 다중 벡터 검색 | 재현율과 정밀도를 동시에 확보 |
| 검색 후 | 재순위화, 컨텍스트 압축, 노이즈 필터링 | 최종 컨텍스트의 신호 대 잡음비 향상 |
3. 검색 전 단계 최적화: 쿼리 재작성과 라우팅
3.1 쿼리 재작성(Query Rewriting)
쿼리 재작성은 사용자가 입력한 원본 질의를 검색에 더 적합한 형태로 변환하는 기법입니다. 이는 맞춤법 교정, 구어체 표현의 정형화, 그리고 검색에 필요한 추가적인 맥락 정보를 보강하는 과정을 포함합니다. 예를 들어 “그거 어떻게 고쳐요?”와 같은 지시대명사 중심의 모호한 쿼리는 대화 이력을 참조하여 “Milvus 컬렉션 로드 오류를 어떻게 해결합니까?”와 같이 구체화될 수 있습니다.
3.2 HyDE(Hypothetical Document Embeddings) 기법
HyDE는 사용자의 쿼리에 대해 언어 모델이 먼저 가상의 답변 문서를 생성하고, 이 가상 문서를 임베딩하여 검색에 사용하는 독창적인 접근법입니다. 이는 짧은 쿼리와 상대적으로 긴 문서 간의 임베딩 공간 불일치 문제를 완화하는 효과가 있습니다. 실제 검색 대상 문서와 유사한 형태와 길이를 가진 가상 문서를 생성함으로써, 벡터 유사도 검색의 정확도를 개선할 수 있습니다.
3.3 쿼리 확장과 다중 쿼리 생성
쿼리 확장은 하나의 원본 쿼리로부터 의미적으로 관련된 여러 개의 하위 쿼리를 생성하여 병렬로 검색을 수행하고, 그 결과를 통합하는 기법입니다. 이는 단일 쿼리로는 포착하기 어려운 다양한 표현 방식과 관점을 검색 과정에 반영할 수 있게 합니다.
3.4 쿼리 라우팅(Query Routing)
쿼리 라우팅은 들어오는 쿼리의 성격을 분석하여 가장 적합한 검색 경로나 데이터 소스로 분기시키는 기법입니다. 예를 들어 정형화된 수치 데이터에 대한 질의는 SQL 데이터베이스로, 비정형 텍스트에 대한 질의는 벡터 데이터베이스로, 관계 중심의 질의는 그래프 데이터베이스로 라우팅하는 방식입니다. 이는 여러 이질적인 데이터 소스를 통합적으로 활용해야 하는 엔터프라이즈 환경에서 특히 중요한 역할을 합니다.
4. 검색 단계 심화: 하이브리드 검색과 융합 검색
4.1 하이브리드 검색의 필요성
밀집 벡터 기반의 시멘틱 검색만으로는 정확한 용어 매칭이 필요한 경우에 취약하다는 한계가 재차 부각되며, 이에 따라 키워드 기반의 BM25 검색과 결합한 하이브리드 검색이 Advanced RAG의 핵심 구성 요소로 자리 잡았습니다.
4.2 앙상블 검색기(Ensemble Retriever)
LangChain 프레임워크는 EnsembleRetriever라는 구성 요소를 통해 서로 다른 검색기의 결과를 결합하는 기능을 제공합니다. 실무에서는 FAISS를 활용한 시멘틱 검색과 BM25를 활용한 키워드 검색을 결합하는 구성이 널리 채택됩니다.
4.3 융합 검색(Fusion Retrieval)
LlamaIndex의 QueryFusionRetriever는 상호 순위 융합(Reciprocal Rank Fusion, RRF) 알고리즘을 통해 여러 검색기의 결과를 통합하는 기능을 제공합니다. 하이브리드 검색을 지원하는 벡터 데이터베이스(Weaviate, Qdrant, Milvus 등)를 사용하는 경우, 쿼리 엔진의 매개변수 두 가지만 변경하는 것으로 손쉽게 하이브리드 검색을 활성화할 수 있다는 점이 실무적 이점으로 언급됩니다.
5. 검색 후 단계 심화: 재순위화와 컨텍스트 압축
5.1 크로스 인코더 재순위화
초기 검색 단계는 일반적으로 재현율을 우선시하여 넉넉한 수의 후보 문서를 반환하도록 설계됩니다. 이후 크로스 인코더(Cross-Encoder) 기반의 재순위화 모델이 쿼리와 각 후보 청크를 함께 인코딩하여 실제 관련성을 정밀하게 재평가합니다. 크로스 인코더 재순위화 계층을 추가하는 것만으로 어려운 검색 조건(Hard Set)에서 평균 역순위(Mean Reciprocal Rank, MRR) 지표가 5에서 15포인트가량 개선되는 것으로 보고되고 있습니다.
5.2 LLM 기반 관련성 채점
크로스 인코더 모델 외에도, 언어 모델 자체에 각 검색된 청크의 관련성을 채점하도록 지시하는 방식이 활용됩니다. 이는 크로스 인코더보다 계산 비용이 높지만, 복잡한 의미적 관련성 판단이 필요한 경우 더 정교한 필터링이 가능하다는 장점이 있습니다.
5.3 컨텍스트 압축과 노이즈 필터링
검색된 청크 중 실제로 답변 생성에 기여하지 않는 불필요한 문장이나 단락을 제거하는 컨텍스트 압축 기법도 중요한 후처리 단계입니다. 이는 언어 모델의 컨텍스트 윈도우를 효율적으로 활용하고, 무관한 정보로 인한 주의 분산(Attention Dilution) 문제를 완화하는 효과가 있습니다.
6. 자기 성찰형 RAG: Self-RAG와 Corrective RAG
6.1 Self-RAG의 핵심 원리
Self-RAG는 언어 모델이 자신의 검색 결과와 생성된 답변의 품질을 스스로 평가하는 반사적(Reflective) 패턴입니다. 모델은 검색된 근거가 충분한지, 그리고 생성된 응답이 근거에 의해 실제로 뒷받침되는지를 특수한 반사 토큰(Reflection Token)을 통해 판단하고, 근거가 불충분하다고 판단될 경우 추가적인 검색을 요청하거나 쿼리를 재작성합니다.
6.2 Corrective RAG(CRAG)의 작동 방식
Corrective RAG는 검색된 문서의 신뢰도를 평가하는 경량 평가기(Evaluator)를 파이프라인에 추가하여, 검색 결과가 부정확하거나 관련성이 낮다고 판단될 경우 대체 검색 전략(예: 웹 검색으로 전환)을 실행하는 패턴입니다. 이러한 자기 수정 메커니즘은 특히 높은 신뢰도가 요구되는 의료, 법률, 금융과 같은 고위험 도메인에서 환각 발생률을 유의미하게 낮추는 것으로 나타났습니다.
6.3 FLARE: 능동적 검색 시점 결정
FLARE(Forward-Looking Active REtrieval)는 언어 모델이 답변을 생성하는 도중 신뢰도가 낮은 토큰을 생성하려는 시점을 감지하여, 그 순간에만 능동적으로 추가 검색을 트리거하는 기법입니다. 이는 매 응답마다 일률적으로 검색을 수행하는 대신, 실제로 정보가 부족한 지점에서만 선택적으로 검색을 수행함으로써 효율성과 정확성을 동시에 향상시킵니다.
7. 에이전틱 RAG: 검색을 에이전트 루프 내부로
7.1 에이전틱 RAG의 정의와 배경
에이전틱 RAG는 검색 기능을 다중 에이전트 시스템의 내부 구성 요소로 편입시킨 아키텍처로, 2026년 기준 엔터프라이즈 AI 에이전트 구축의 주류 패턴으로 부상하고 있습니다. 이 구조에서는 쿼리 분해, 검색 실행, 결과 검증, 최종 답변 합성이라는 각 역할을 전담하는 특화된 에이전트들이 병렬적으로 협업합니다.
7.2 검색을 루프 앞이 아닌 루프 내부로
전통적인 RAG 구조에서 검색은 생성 이전에 단 한 번 수행되는 전처리 단계로 취급되었습니다. 반면 Self-RAG, FLARE, 그리고 프로덕션 수준의 에이전틱 패턴들은 검색을 에이전트의 반복적인 추론 루프 내부로 이동시킵니다. 이를 통해 모델은 추론 과정 중 언제든지 추가적인 근거를 요청하거나, 쿼리를 재작성하거나, 충분한 정보가 확보되었다고 판단되면 조기에 검색을 종료할 수 있는 능동적 통제권을 갖게 됩니다.
7.3 다중 에이전트 협업 구조의 이점
쿼리 분해를 전담하는 에이전트는 복잡한 다단계 질의를 하위 질의로 분할하고, 검색 에이전트는 각 하위 질의에 대해 최적화된 검색을 병렬로 수행하며, 검증 에이전트는 취합된 근거의 일관성과 신뢰도를 교차 검증하고, 최종적으로 합성 에이전트가 통합된 답변을 생성하는 구조입니다. 이러한 역할 분리는 각 단계의 오류를 조기에 포착하고 격리할 수 있다는 시스템 설계상의 강점을 제공합니다.
8. 설치 및 환경 구성 완전 가이드
8.1 사전 요구사항
Advanced RAG 파이프라인 구축을 위해서는 Python 3.9 이상, 최소 8GB 메모리, 그리고 OpenAI, Anthropic, Cohere 등 외부 API를 활용하는 경우 해당 서비스의 API 키가 필요합니다.
8.2 핵심 패키지 설치
# LangChain 핵심 프레임워크 및 관련 패키지 설치 pip install -q langchain langchain-community langchain-openai # 임베딩 및 재순위화 모델 관련 패키지 pip install -q sentence-transformers cohere # 벡터 검색 라이브러리 (시멘틱 검색용) pip install -q faiss-cpu # 키워드 검색 라이브러리 (BM25 알고리즘) pip install -q rank_bm25 # LlamaIndex 프레임워크 (선택적, 융합 검색용) pip install -q llama-index llama-index-retrievers-bm25
명령어 상세 설명입니다:
-q플래그는 quiet 모드로, 설치 과정의 상세 로그 출력을 생략하여 콘솔을 간결하게 유지합니다.faiss-cpu는 Facebook AI Research가 개발한 고성능 유사도 검색 라이브러리로, GPU 없이도 로컬 환경에서 밀집 벡터 검색을 수행할 수 있게 합니다. GPU 가속이 필요한 경우faiss-gpu로 대체 설치가 가능합니다.rank_bm25는 순수 Python으로 구현된 경량 BM25 알고리즘 라이브러리로, 별도의 서버 없이 인메모리에서 키워드 검색을 수행할 수 있습니다.cohere는 별도의 재순위화 전용 API를 제공하는 서비스의 공식 SDK로, 자체 크로스 인코더 모델을 호스팅하지 않고도 고품질 재순위화 기능을 활용할 수 있게 합니다.
8.3 API 키 환경변수 설정
# Linux/macOS 환경 export OPENAI_API_KEY=”your-api-key-here” export COHERE_API_KEY=”your-cohere-key-here” # Windows PowerShell 환경 $env:OPENAI_API_KEY=”your-api-key-here” $env:COHERE_API_KEY=”your-cohere-key-here”
API 키를 코드에 직접 하드코딩하지 않고 환경변수로 관리하는 것은 자격 증명 유출을 방지하기 위한 보안 모범 사례이며, export 명령은 현재 셸 세션 및 그 하위 프로세스에서 해당 변수를 참조할 수 있도록 설정합니다.
8.4 설치 검증
import langchain import faiss from rank_bm25 import BM25Okapi print(f”LangChain 버전: {langchain.__version__}”) print(f”FAISS 정상 로드 확인: {faiss.__version__ if hasattr(faiss, ‘__version__’) else ‘OK’}”) print(“BM25Okapi 클래스 로드 성공”)
9. 종단 간 구현: Python 실습 코드
9.1 문서 준비 및 청킹
from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.docstore.document import Document raw_texts = [ “리튬이온 배터리의 열관리 시스템은 전기차 안전성의 핵심 요소입니다.”, “Advanced RAG는 검색 전, 검색, 검색 후 세 단계의 최적화를 포함합니다.”, “하이브리드 검색은 밀집 벡터와 희소 벡터를 결합한 검색 방식입니다.”, “Self-RAG는 모델이 스스로 검색 결과의 품질을 평가하는 기법입니다.”, ] # 재귀적 문자 분할기를 통한 청킹 splitter = RecursiveCharacterTextSplitter( chunk_size=200, chunk_overlap=20 ) documents = [Document(page_content=t) for t in raw_texts] chunks = splitter.split_documents(documents) print(f”총 {len(chunks)}개의 청크가 생성되었습니다.”)
chunk_overlap=20은 인접한 청크 사이에 20자 분량의 중복 구간을 두는 설정으로, 청크 경계에서 문맥이 단절되어 중요한 정보가 손실되는 것을 방지하는 역할을 합니다.
9.2 앙상블 검색기 구성 (하이브리드 검색)
from langchain_community.vectorstores import FAISS from langchain_community.retrievers import BM25Retriever from langchain.retrievers import EnsembleRetriever from langchain_community.embeddings import HuggingFaceEmbeddings # 밀집 벡터 검색기 (FAISS 기반) embeddings = HuggingFaceEmbeddings(model_name=”BAAI/bge-m3″) faiss_store = FAISS.from_documents(chunks, embeddings) dense_retriever = faiss_store.as_retriever(search_kwargs={“k”: 5}) # 희소 벡터 검색기 (BM25 기반) bm25_retriever = BM25Retriever.from_documents(chunks) bm25_retriever.k = 5 # 앙상블 검색기: 두 결과를 가중치 기반으로 결합 ensemble_retriever = EnsembleRetriever( retrievers=[dense_retriever, bm25_retriever], weights=[0.6, 0.4] ) results = ensemble_retriever.invoke(“배터리 안전 관리 방법”) for r in results: print(r.page_content)
주요 매개변수 설명입니다:
search_kwargs={"k": 5}는 밀집 검색기가 반환할 상위 문서의 개수를 지정합니다.weights=[0.6, 0.4]는 밀집 검색과 희소 검색 결과를 결합할 때의 상대적 가중치로, 도메인 특성에 따라 조정이 필요한 하이퍼파라미터입니다.
9.3 크로스 인코더 재순위화 적용
from sentence_transformers import CrossEncoder # 크로스 인코더 재순위화 모델 로드 reranker = CrossEncoder(“BAAI/bge-reranker-v2-m3”) query = “배터리 안전 관리 방법” pairs = [[query, doc.page_content] for doc in results] # 관련성 점수 계산 scores = reranker.predict(pairs) # 점수 기준 내림차순 정렬 reranked = sorted(zip(results, scores), key=lambda x: x[1], reverse=True) for doc, score in reranked[:3]: print(f”점수: {score:.4f} | 내용: {doc.page_content}”)
CrossEncoder는 쿼리와 문서를 별도로 인코딩하는 바이 인코더(Bi-Encoder) 방식과 달리, 쿼리와 문서 쌍을 하나의 입력으로 함께 인코딩하여 두 텍스트 간의 상호작용을 직접적으로 모델링하므로, 초기 검색 단계보다 훨씬 정밀한 관련성 판단이 가능합니다. 다만 쿼리-문서 쌍마다 별도의 순전파 연산이 필요하므로, 초기 검색으로 후보군을 충분히 좁힌 뒤 재순위화 단계에 적용하는 2단계 구조가 일반적입니다.
9.4 Corrective RAG 패턴 구현
from langchain_openai import ChatOpenAI llm = ChatOpenAI(model=”gpt-4o”, temperature=0) def evaluate_relevance(query, document_text): “””검색된 문서의 관련성을 LLM으로 평가하는 경량 평가기””” prompt = f”””다음 문서가 질문에 답하는 데 관련이 있습니까? 질문: {query} 문서: {document_text} “관련있음” 또는 “관련없음”으로만 답하십시오.””” response = llm.invoke(prompt) return “관련있음” in response.content def corrective_rag_search(query, retriever, fallback_search_fn): “””1차 검색 결과가 부실할 경우 대체 검색으로 전환하는 CRAG 패턴””” docs = retriever.invoke(query) relevant_docs = [d for d in docs if evaluate_relevance(query, d.page_content)] if len(relevant_docs) < 2: print(“검색 품질이 낮아 대체 검색을 실행합니다.”) relevant_docs = fallback_search_fn(query) return relevant_docs
위 코드는 1차로 검색된 문서 중 실제로 관련성이 있다고 평가된 문서의 수가 임계치(위 예시에서는 2건) 미만일 경우, 웹 검색과 같은 대체 검색 함수로 전환하는 Corrective RAG의 핵심 로직을 단순화하여 보여줍니다. 실제 프로덕션 구현에서는 관련성 평가에 경량 분류 모델을 활용하여 LLM 호출 비용을 절감하는 것이 일반적입니다.
10. 평가 방법론과 실전 고려사항
10.1 RAG 시스템 평가 지표
Advanced RAG 파이프라인의 효과를 정량적으로 검증하기 위해서는 RAGAS와 같은 전용 평가 프레임워크의 활용이 권장됩니다. 주요 지표로는 검색된 컨텍스트가 실제로 관련성이 있는지를 측정하는 컨텍스트 정밀도(Context Precision), 필요한 정보가 검색 결과에 충분히 포함되었는지를 측정하는 컨텍스트 재현율(Context Recall), 그리고 생성된 답변이 검색된 근거에 실제로 기반하는지를 측정하는 충실도(Faithfulness)가 있습니다.
10.2 단계별 기법 도입의 우선순위
모든 고급 기법을 한꺼번에 도입하기보다는, 자체 평가 지표를 기준으로 병목 구간을 식별한 후 단계적으로 기법을 추가하는 접근이 바람직합니다. 일반적으로 하이브리드 검색과 재순위화의 조합이 투자 대비 효과가 가장 높은 1차 개선 대상으로 꼽히며, 이후 자기 성찰형 패턴과 에이전틱 구조는 도메인의 정확도 요구 수준이 매우 높거나 다단계 추론이 필수적인 경우에 한하여 추가하는 것이 합리적입니다.
10.3 지연시간과 비용의 트레이드오프
재순위화, 자기 평가, 다중 에이전트 협업과 같은 고급 기법은 예외 없이 추가적인 연산 단계를 수반하므로 지연시간과 API 호출 비용이 증가합니다. 따라서 실시간성이 중요한 서비스에서는 캐싱 전략, 경량 평가 모델의 활용, 그리고 조건부 실행(예: 1차 검색 신뢰도가 낮을 때만 재순위화 수행)과 같은 최적화 기법을 병행하는 것이 중요합니다.
11. 결론 및 향후 발전 방향
이 기록에서는 나이브 RAG의 구조적 한계에서 출발하여, 검색 전 최적화, 하이브리드 검색, 재순위화, 자기 성찰형 패턴, 그리고 에이전틱 RAG에 이르는 Advanced RAG의 전체 스펙트럼을 살펴보았습니다. 핵심적인 결론은 단일 기법의 도입만으로는 유의미한 성능 향상을 기대하기 어려우며, 파이프라인 전 구간에 걸친 체계적이고 단계적인 최적화가 실질적인 개선으로 이어진다는 점입니다.
향후 발전 방향으로는 다음을 전망할 수 있습니다. 첫째, 검색과 생성이 명확히 분리된 파이프라인에서 벗어나, 모델의 추론 과정 자체에 검색 능력이 내재화되는 방향으로의 진화입니다. 둘째, 다중 에이전트 협업 구조가 보편화되면서 각 에이전트의 역할과 상호작용 프로토콜을 표준화하려는 시도가 확대될 것으로 예상됩니다. 셋째, 텍스트를 넘어 이미지, 표, 그래프 구조 데이터까지 통합적으로 검색하고 추론하는 멀티모달 Advanced RAG로의 확장이 활발해질 것입니다.
RAG 기술은 언어 모델 생태계에서 가장 빠르게 발전하는 영역 중 하나이므로, 실무에 적용할 때는 자체 도메인에 대한 지속적인 평가와 함께 최신 연구 동향을 꾸준히 반영해 나가는 자세가 필요합니다.
참고 자료 및 출처
본 글은 다음의 자료를 기반으로 작성되었습니다:
- 12 Advanced RAG Techniques: Beyond Naive Retrieval [2026] | Atlan
- What Is RAG? How Retrieval-Augmented Generation Works in 2026 | Atlan
- RAG Architecture 2026: Patterns, Code, and Eval | Future AGI
- Agentic RAG Explained: Self-Correcting Retrieval | Let’s Data Science
- RAG Techniques Compared: A Practical Guide to RAG in 2026 | Starmorph
- Advanced Retrieval-Augmented Generation: From Theory to LlamaIndex Implementation
- Advanced RAG Implementation using Hybrid Search and Reranking | Medium
- Advanced RAG techniques for high-performance LLM applications | Neo4j
- GitHub – NirDiamant/RAG_Techniques
Takeaway
- 단순 RAG 실패는 모델 교체보다 청킹·쿼리 재작성·리랭크 순서로 고칩니다.
- 인용되지 않은 문장은 답에서 빼는 규칙을 생성 프롬프트에 명시하십시오.
- 사후 검증(엔티티 일치, 조항 번호) 없는 RAG는 데모입니다.
- 파이프라인 층이 늘수록 지연이 늘어납니다. SLA를 먼저 적고 층을 추가하십시오.