리서치 에이전트를 붙였는데도 임원이 다시 사람에게 확인을 시킨다. 검색은 많이 한다. 출처도 붙인다. 그런데 회의실에서는 “이 근거가 최신인가”, “다른 자료와 모순 아닌가”, “왜 이 출처를 믿었나”가 남는다. 문제는 검색 성능이 아니다. 검색 결과를 운영 가능한 증거 장부로 만들지 않은 것이다.
검색 결과는 문장이 아니라 증거 상태다
일반 RAG는 검색 결과를 상위 문서 묶음으로 다룬다. 리서치 에이전트는 그렇게 운영하면 무너진다. 같은 질문이라도 규제, 가격, 제품 사양, 논문, 내부 정책은 시간과 권위가 다르다.
2026년에 공개된 LedgerRAG 논문은 dynamic RAG에서 시스템이 무엇을 검색할지뿐 아니라 언제 갱신하고, 충돌을 어떻게 중재하고, 어떤 증거를 썼는지 감사 로그로 남겨야 한다고 정리한다. 이 관점은 기업 리서치 에이전트 설계의 출발점이다. (mdpi.com)
AX Ops에서는 검색 결과를 답변 직전의 재료가 아니라 운영 중 계속 갱신되는 상태로 본다. 최소 단위는 문서가 아니라 claim이다.
| 구성요소 | 저장 대상 | 운영 질문 |
|---|---|---|
| citation graph | claim-source-evidence 관계 | 이 답변은 어떤 근거망 위에 서 있는가 |
| contradiction queue | refute·outdated·ambiguous 항목 | 사람이 먼저 봐야 할 충돌은 무엇인가 |
| freshness budget | 재검색 한도와 만료 기준 | 어디까지 최신성을 사야 하는가 |
citation graph는 출처 목록이 아니라 경로다
출처를 나열한다고 검증 가능해지지 않는다. 중요한 것은 “어떤 claim이 어떤 evidence span으로 지지되고, 그 evidence가 어떤 상위 문서와 연결되는가”다.
TechGraphRAG는 단일 검색 후 답변하는 구조를 넘어서 query classification, evidence sufficiency scoring, external search, knowledge graph traversal, citation verification, quality check를 한 파이프라인으로 묶는다. 특히 논문·저자·주제·방법·citation 관계를 그래프로 구성해 근거 탐색 경로를 남긴다. (arxiv.org)
이 구조를 기업 검색에 적용하면 답변 UI도 바뀐다. “출처 5개”가 아니라 “핵심 주장 7개 중 5개 verified, 1개 stale, 1개 contested”가 보여야 한다. 리더가 필요한 것은 예쁜 요약이 아니라 의사결정 가능한 근거 상태다.
리서치 에이전트의 산출물은 답변이 아니라, 답변을 낳은 증거 장부까지 포함한 패키지다.
contradiction queue는 실패가 아니라 작업목록이다
검색 결과가 서로 충돌하는 것은 예외가 아니다. 현장에서는 최신 공지와 오래된 매뉴얼, 본사 정책과 지역 예외, 벤더 문서와 실제 릴리스 노트가 동시에 잡힌다.
2025년 ContraGen 논문은 기업 문서의 모순이 계약, 재무 공시, 컴플라이언스 보고서, 정책 매뉴얼처럼 문맥이 긴 자료에서 더 복잡하게 발생한다고 지적한다. unresolved conflict가 출력으로 흘러 들어가면 신뢰 문제가 아니라 운영 리스크가 된다. (arxiv.org)
따라서 contradiction queue는 “모델이 알아서 판단할 문제”가 아니다. 다음 네 가지 상태로 분류해 사람과 시스템의 역할을 나눠야 한다.
- Refuted: 같은 claim을 직접 반박하는 근거
- Superseded: 더 최신 근거가 기존 근거를 대체
- Scope conflict: 지역, 제품군, 기간 조건이 다름
- Authority conflict: 출처 권위가 충돌
큐에 올라간 항목은 답변에서 숨기지 않는다. “현재 답변은 A 기준이며, B 출처는 기간 조건이 달라 제외했다”라고 남긴다. 이것이 에이전트 신뢰의 실제 형태다.
freshness budget은 검색 깊이의 예산이다
최신성은 공짜가 아니다. 더 검색하면 비용, 지연, 노이즈가 같이 늘어난다. 그래서 리서치 에이전트에는 freshness budget이 필요하다.
Microsoft의 2026년 Azure OpenAI Responses API 문서는 web search가 실시간 정보로 답변을 grounding하고 inline citation을 반환할 수 있으며, agentic search는 모델이 검색 과정을 관리하고 추가 검색 여부를 판단한다고 설명한다. 동시에 tool call 비용, 도메인 제한, reasoning 모델에서만 가능한 page open/find 제약도 명시한다. (learn.microsoft.com)
운영 설계는 단순하다. 모든 질문에 deep research를 쓰지 않는다. claim별로 freshness half-life를 둔다. 가격·규제·제품 버전은 짧게, 역사·방법론·내부 원칙은 길게 둔다. 만료된 claim만 재검색한다. 답변 전체를 다시 만들지 않는다.
답변 전에 장부를 먼저 설계한다
Agentic search evidence ledger의 핵심은 검색을 많이 시키는 데 있지 않다. claim을 쪼개고, 근거 관계를 그래프로 남기고, 충돌을 큐로 올리고, 최신성 예산을 claim별로 쓰는 데 있다.
이 구조가 없으면 리서치 에이전트는 빠른 조사 보조 도구에 머문다. 이 구조가 있으면 답변, 검토, 재검색, 감사가 같은 운영 루프에 들어온다. AX LABS가 에이전트 설계를 PoC가 아니라 운영 체계로 다루는 이유가 여기에 있다.
참고
- LedgerRAG: Governance-Driven Agentic Chain of Retrieval for Dynamic Knowledge Scenarios, 2026 — https://www.mdpi.com/2079-9292/15/7/1376
- TechGraphRAG: An Agentic Graph-Augmented RAG Framework for Technical Literature Reasoning, 2026 — https://arxiv.org/abs/2606.01613
- ContraGen: A Multi-Agent Generation Framework for Enterprise Contradictions Detection, 2025 — https://arxiv.org/abs/2510.03418
- VeriCite: Towards Reliable Citations in Retrieval-Augmented Generation via Rigorous Verification, 2025 — https://arxiv.org/abs/2510.11394
- Microsoft Learn, Web search with the Responses API, 2026 — https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/web-search
에이전트를 답변 생성기가 아니라 운영 가능한 증거 시스템으로 설계하려면 AX Ops 방법론 →