문맥 추출과 자기교정 루프의 실제 — 트레이스가 말해주는 것

관련성 판정을 항상 no로 고정한 스텁을 붙이고 자기교정 루프를 돌리면 무슨 일이 일어날까. 정확히 10회 재검색한 뒤 Agent stopped due to max iterations.만 출력하고 끝난다. 답변이 아예 없다. 그리고 10회 동안 생성된 쿼리는 어순과 수식어만 바뀐 동의어 나열이다.

이 글은 검증 루프를 실제로 돌렸을 때 관측되는 것들을 다룬다. 루프가 왜 중간에 멈추는지 프롬프트·도구·실행기 세 층으로 나눠 진단하고, 압축기에서 생성 권한을 제거하는 설계, 두 도구를 결합할 때의 트레이드오프, 그리고 RAG 품질을 계층별 지표로 관리하는 체계까지 이어진다. 설계와 프롬프트 개정 기록은 앞 편에 있다.

세 가지 조합

같은 retriever와 같은 질문을 쓰고 도구 구성과 프롬프트만 바꾼 세 가지 구성이 있다. 실험 변수는 "어떤 검증 도구를 어떤 순서로 붙이는가" 하나다.

용어 정리

검증 루프를 실제로 돌리면

공통 기반은 이렇다.

loader = PyPDFLoader("data/report.pdf")
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
split_docs = loader.load_and_split(text_splitter)

vector = FAISS.from_documents(split_docs, OpenAIEmbeddings())
retriever = vector.as_retriever()

agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(
    agent=agent, tools=tools, verbose=True, max_iterations=20
)

강제 no 상황의 트레이스

판정을 항상 no로 고정한 스텁을 붙이고 실행한 결과다.

관측된 사실 셋이 전부 실무에 직결된다.

루프가 중간에 멈추는 이유 — 세 층으로 나눠 본다

관련성 판정이 no인데도 재검색하지 않고 종료되는 일이 있다. 원인 후보는 다섯이다.

진단의 요령은 층을 가르는 것이다. 트레이스에 판정 도구 호출 기록이 없으면 프롬프트 층, 호출은 됐는데 결과를 안 따르면 도구 층(스키마·description), 정상 동작인데 끊기면 실행기 층(상한) 문제다.

쿼리 재작성 부실은 별도로 손봐야 한다. 트레이스의 쿼리 10개는 같은 어휘의 어순만 바뀐 변형이라 같은 문서를 계속 검색한다. 재시도가 의미를 갖지 못한다.

문맥 추출기 — 압축기가 거짓말할 수 없게 만든다

검색은 성공했는데 청크가 크다. chunk_size=1000이면 한 청크에 목차·출처·머리말 같은 무관한 줄이 대량으로 섞인다. 그대로 넣으면 F2(노이즈 희석)가 발생한다.

핵심 기법은 두 줄이다.

contexts = []
for doc in retriever.invoke("삼성전자가 개발한 생성형 AI 관련된 정보를 문서에서 찾아줘"):
    contexts.extend(doc.page_content.split("\n"))

indexed_contexts = [f"[{i+1}] {contexts[i]}" for i in range(len(contexts))]

• 청크(문서 단위)를 줄 단위로 분해한다 → 근거의 최소 단위를 잘게 만든다.
• 각 줄에 [index] 번호를 붙인다 → LLM이 원문 대신 번호로 답할 수 있게 한다.

실제로 검색된 청크 4개가 61줄로 펼쳐졌고, 그중 다수가 목차·행동강령 조항·출처 표기였다.

llm_context_extractor = (
    load_prompt("prompts/context-extractor.yaml")
    | ChatOpenAI(model="gpt-4o-mini", temperature=0)
    | StrOutputParser()
)

llm_context_extractor.invoke(
    {"question": "...", "contexts": indexed_contexts}
)
# '3,4,5,9,10,15,17,19,21,23'

인덱스만 반환하게 한 것이 핵심이다

프롬프트의 결정적 지시는 이 두 줄이다.

- Your response should be only the relevant context for the user's query, nothing else.
- Only return the index of the relevant context.

이 설계의 진짜 값어치는 토큰 절감이 아니라 압축기가 거짓말할 수 없게 만든 것이다.

LLM에게 요약을 시키면 요약 자체가 새로운 할루시네이션 발생원이 된다. 출력을 인덱스로 제한하면 압축기의 역할이 "선택"으로 축소되고 생성 권한이 제거된다.

이것이 검증 단계 설계의 일반 원칙이다. 판정·선별 컴포넌트에는 생성 권한을 주지 않는다.

효과 — 총 토큰이 줄어드는 게 아니다

마지막 행이 중요하다. 추출기는 61줄을 전부 읽어야 하므로 그 단계에서 입력 토큰을 온전히 쓴다. 절감은 하류(답변 생성, 그리고 이후 모든 루프 반복)에서 발생한다.

따라서 추출기가 이득이 되는 조건은 ① 답변 생성 모델이 추출 모델보다 비싸거나 ② 압축된 문맥이 여러 번 재사용될 때다. 단발 호출에서는 오히려 손해일 수 있다.

정확도 측면의 효과는 별개로 존재한다.

도구화와 그 취약점

@tool
def filter_context(input: str, context: list[Document]) -> list[str]:
    """This is a tool for filtering the retrieved context."""
    contexts = []
    for doc in context:
        contexts.extend(doc.page_content.split("\n"))

    indexed_contexts = [f"[{i+1}] {contexts[i]}" for i in range(len(contexts))]

    answer = llm_context_extractor.invoke(
        {"question": input, "contexts": indexed_contexts}
    )

    selected_contexts = [contexts[int(index) - 1] for index in answer.split(",")]
    return "\n".join(selected_contexts)

int(index)는 LLM 출력이 정확한 숫자 CSV일 때만 동작한다.

모델이 3, 4, 5(공백 포함)나 없음, 혹은 범위를 벗어난 인덱스를 반환하면 예외가 난다. 실무 이식 시에는 strip()·범위 검사·빈 결과 폴백을 반드시 넣어야 한다.

조건 분기가 없다는 점에 주목한다. 이 구성에는 판정 도구가 없으므로 되돌아가는 화살표가 존재하지 않는다. 검색이 통째로 빗나가면 무관한 문서에서 "그나마 관련 있는 줄"을 골라 답을 만든다.

즉 압축만으로는 F1(검색 실패)을 잡지 못하며, 오히려 무관한 근거를 정제해 더 그럴듯한 오답을 만들 위험이 있다. 실제 트레이스도 도구 호출 2회 후 그대로 끝난다.

압축과 검증을 결합하면

실제 실행에서는 첫 시도에 yes가 나와 루프 없이 끝났다. 도구 호출 3회다.

정상 케이스에서는 검증 루프의 비용이 거의 없다. 관련성이 통과되면 판정 1회분(저비용 모델) 비용만 추가된다.

루프 비용은 검색이 실패했을 때만 발생하므로, 검증 도입의 비용 구조는 **"평상시 소액 고정비 + 실패 시 변동비"**다. 이것이 검증 루프가 실무에서 성립하는 이유다.

결합의 트레이드오프

압축과 판정을 한 번의 LLM 호출로 합치는 확장도 생각할 수 있다. 그런데 이 거래는 손해다.

지연이 치명적인 서비스가 아니라면 분리 유지가 낫다. 통합의 이득은 왕복 1회 단축뿐인데, 잃는 것은 "어느 단계가 고장났는지 아는 능력"이다.

RAG 품질 개선은 결국 단계별 지표를 보고 하는 일이라, 관측 가능성을 파는 거래는 손해다. 다만 압축기와 판정기가 같은 문맥을 두 번 읽는 낭비는 실재하므로, 압축기가 인덱스와 함께 근거 충분성 플래그를 부수적으로 내는 절충안은 검토할 만하다.

세 구성 종합

F3·F4는 셋 중 어느 구성도 잡지 못한다. 답변을 대상으로 하는 B·C축 판정이 필요하고, 그것은 요청 경로가 아니라 오프라인 샘플링에 배치하는 것이 기본형이다.

운영으로 옮길 때 채워야 할 것

품질을 무엇으로 관리하는가

운영 계층의 두 지표를 신호로 읽는 방법이 특히 유용하다. 재검색률이 오르면 검색 품질 신호로, 상한 도달률이 오르면 폴백 설계 신호로 읽는다.

관측이 먼저다

세 구성 모두 가장 먼저 하는 일이 트레이스 설정이다.

import os

os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_PROJECT"] = "agentic-rag"

Agentic RAG는 실행 경로가 매번 다르므로 트레이스 없이는 디버깅이 불가능하다.

"어떤 쿼리로 몇 번 재검색했고, 판정이 어디서 뒤집혔는가"는 로그가 아니라 트레이스에 있다. 관측을 먼저 깔고 기능을 붙이는 순서가 이 구조에서 특히 중요한 이유다.

검증 루프 설계에서 반복해 부딪히는 판단은 RAG 품질 Q&A에 문답으로 모았다.