8.8 오라클 기반의 자동 수정(Self-Correction) 및 피드백 루프

검색 증강 생성(RAG) 시스템 내에 견고한 오라클(Oracle)을 구현하는 것의 진정한 엔지니어링 가치는, 단순히 AI의 응답이 “틀렸다“며 차단(Reject)하는 방어적 수문장에 머무르는 데 있지 않다. 현대의 지능형 에이전트(Autonomous Agent) 파이프라인에서 오라클은 오류를 감지함과 동시에, 그 오류의 근본 원인(Root Cause)을 분석하여 검색기(Retriever)나 생성기(Generator)가 스스로 정답을 찾아가도록 유도하는 **‘자동 수정(Self-Correction) 피드백 루프’**의 트리거 핀 역할을 수행해야 한다.

RAG 시스템은 본질적으로 다단계 파이프라인(Query → Retrieval → Prompt Injection → Generation)을 거치기 때문에, 한 번의 런타임(Runtime) 요청이 실패했을 때 에러를 바로 던지고(Exception Throw) 포기하는 것은 컴퓨팅 리소스의 심각한 낭비이다.

본 단원에서는 오라클이 감지한 각기 다른 실패 유형에 따라 시스템이 어떻게 스스로 쿼리를 재구성(Query Reformulation)하고 파라미터를 동적으로 변경하며, 기계적으로 생성 품질을 복구해 내는지 그 자율적인 피드백 아키텍처를 상세히 해부한다.

1. 검색 실패 오라클 감지 시: 쿼리 재구성(Query Reformulation) 루프

질문: “최근 3분기 미국 연준의 금리 변동이 애플의 주가에 미친 영향은?”
오라클 결과: [Fail: Low Context Relevance] - 검색된 문서들(Chunks)이 질문의 핵심 의도(Fed 금리)를 포함하고 있지 않음.

오라클이 코사인 유사도(Cosine Similarity) 임계값 미달이나 키워드 검색 실패를 선언했을 때, 시스템은 즉각적인 실패를 반환하지 않고 쿼리 재구성 루프로 진입한다.

Hypothetical Document Embeddings (HyDE) 변환: 오라클의 피드백을 받은 소형 조정 모델(Router LLM)은 사용자의 원본 쿼리를 기반으로 가상의 이상적인 답변 문서(Fake Document)를 먼저 생성해 내고, 이 가상 문서의 임베딩(Embedding) 벡터로 벡터 DB를 재검색한다.
Query Expansion (쿼리 확장): 원본 쿼리에 동의어나 상위/하위 개념의 기술 용어를 자동으로 덧붙여 다중 쿼리(Multi-Query)를 생성한 후 병렬로 검색을 재시도한다.
오라클은 이 재시도 루프를 최대 N회(Max Retries)까지 반복 허용하며, 검색된 토큰의 지식 밀도(Knowledge Density)가 기준선을 돌파할 때만 다음 생성(Generation) 루프로 제어권을 넘긴다.

graph TD
    A[User Query] --> B[Retriever]
    B --> C{Context Relevance Oracle}
    C -->|Pass > 0.8| D[LLM Generator]
    C -->|Fail < 0.8| E[Query Reformulator LLM]
    E -->|Expanded/HyDE Query| B
    E -->|Max Retries Exceeded| F[Fallback: Answer Refusal]

2. 생성 실패 오라클 감지 시: 충실성(Faithfulness) 강압 루프

만약 위의 1단계를 통과하여 지식 소스는 완벽히 주입되었으나, 생성된 최종 텍스트가 환각(Hallucination)을 내포하여 **충실성 검증 오라클(Faithfulness Oracle)**에 의해 Fail 판정을 받았다면 어떻게 할 것인가?

이때 오라클은 단순한 False 값을 반환하는 것을 넘어, **“무엇이, 왜 틀렸는지”**에 대한 기계적 해명(Reasoning)을 덧붙인 메타 프롬프트(Meta-prompt) 에러 객체를 생성하여 생성기(Generator)에게 재귀적으로(Recursively) 피드백한다.

오라클의 피드백 예시: “너의 이전응답 2번째 문장인 ’연준은 금리를 0.5% 인하했다’는 주입된 Context 문서 어디에도 나타나지 않는 치명적인 환각이다. 해당 문장을 삭제하거나 ’문서에 언급되지 않음’으로 교정하여 다시 출력하라.”
생성기는 이 구체적인 Negative Constraint 프롬프트를 컨텍스트 상단에 추가로 얹고(Append), 이전 응답 내역과 함께 2차 생성을 시도한다. 이를 통해 모델은 자신의 무결성 오류를 스스로 교정(Self-heal)하며 최종적으로 오라클의 문턱을 넘어서게 된다.

3. 무한 루프 방지 및 안전한 폴백(Fallback) 거부 프로토콜

위와 같은 강력한 피드백 순환 구조에도 불구하고 주의해야 할 아키텍처 안티 패턴(Anti-pattern)이 있다. 불가능한 문제에 대해 시스템이 끝없는 반복(Infinite Loop)에 빠져 무의미한 API 클라우드 비용을 폭증시키는 현상이다.

서킷 브레이커(Circuit Breaker) 패턴: 시스템 설계자는 반드시 피드백 루프의 카운팅 변수(예: retry_count <= 3)를 강제해야 한다. 루프가 허용 횟수를 초과하면, 오라클은 시스템의 연쇄적인 붕괴를 막기 위해 서킷 브레이커를 작동시킨다.
의도된 거절(Intentional Refusal): 서킷 브레이커가 작동하면, 시스템은 어설픈 추측성 환각 답변을 던지는 대신 “현재 제공된 내부 지식 베이스만으로는 해당 질문에 대해 신뢰할 수 있는 답변을 자동 구성할 수 없습니다. 관련 문서를 수동으로 확인해 주십시오.“라는 하드코딩된 인간 응대용 표준 응답(Standard Protocol)을 반환해야 한다.

오라클과 결합된 피드백 루프는 단방향으로 흐르던 RAG 파이프라인을 유기적으로 박동하는 다이나믹(Dynamic) 시스템으로 진화시킨다. 실패를 두려워하지 않고, 실패 자체를 정답을 조각해 나가기 위한 이정표로 재활용하는 이 자동 수정 메커니즘이야말로 진정한 결정론적 소프트웨어 공학의 정수라 할 수 있다.