AI 에이전트 함대(fleet)를 구축하고 운영하는 시리즈의 일부로, hexisteme notes에 처음 게시되었습니다.

AI 리서치 또는 RAG (Retrieval-Augmented Generation) 에이전트가 자신의 추론을 검색된 사실인 것처럼 제시하는 것을 방지하려면, LLM이 무엇이 사실인지 결정하지 않도록 작업을 분리해야 합니다. LLM은 추출 및 요약만 수행하게 하고, 결정론적(deterministic)인 비(non)-LLM 파이프라인이 모든 점수 매기기, 교차 검증 및 라벨링을 수행하도록 하십시오. 2개 이상의 독립적인 소스에 의한 확인 또는 하나의 공식 API와 같은 규칙이 충족될 때만 주장을 FACT로 태그하고, 그 외의 모든 것은 INFERENCE로 격하시킵니다. 라벨링이 규칙 기반(rule-based)이기 때문에, 에이전트는 추측을 사실로 세탁할 수 없으며 동일한 쿼리에 대해 매 실행마다 동일한 라벨을 생성합니다.

정보를 수집하는 AI 에이전트는 서로 뒤섞인 두 가지 종류의 출력을 가집니다: 에이전트가 검색한(retrieved) 것과 에이전트가 결론을 내린(concluded) 것입니다. 웹 페이지에서 시장 규모가 1.2조 원이라고 말하면 (검색됨), 에이전트는 시장이 "빠르게 성장하고 있다"고 추론합니다 (결론). 이 두 가지 모두 동일하게 자신감 있는 문체로 출력됩니다. 당신이 실제로 행동에 옮길 모든 것에 있어, 이러한 혼합이 바로 문제입니다. 어떤 문장이 근거가 있고 어떤 문장이 모델이 공백을 메우기 위해 만든 것인지 구분할 수 없기 때문입니다.

해결책은 더 나은 프롬프트("인용할 수 있는 사실만 말하세요")가 아닙니다. 프롬프트는 확률적(probabilistic)입니다. 압박을 받으면 모델은 원래대로 돌아갑니다. 해결책은 구조적입니다: 사실/추론에 대한 결정권을 모델로부터 완전히 빼앗아 코드에 넣는 것입니다.

분리: LLM은 추출하고, 코드는 판단한다

파이프라인에 명확한 선을 그으십시오:

LLM은 지저분한 텍스트를 읽고 구조화된 주장 (Claim)을 추출하는 데는 탁월합니다. 하지만 그 주장을 _판단(judging)_하는 데는 신뢰할 수 없습니다. LLM에게 "신뢰도를 0~1 사이로 평가하라"고 요청하면, 추측을 0.85와 같은 숫자로 바꾸어 버리고, 다음 실행 시에는 다른 숫자를 내놓을 것입니다. 따라서 추출 (Extraction) 이후의 모든 단계에서는 LLM 호출이 허용되지 않습니다. 점수는 토큰 일치 (Token matches), 출처 개수 (Source counts), 최신성 계산 (Recency math)을 통해 산출됩니다. 라벨 (Labels)은 규칙 (Rule)의 출력값입니다. 이를 통해 두 가지를 동시에 얻을 수 있습니다: 재현성 (Reproducibility) (동일한 쿼리 → 동일한 라벨, 즉 유닛 테스트가 가능함)과 세탁 방지 (No laundering) (모델이 라벨링 과정에서 직접 펜을 들지 않으므로, 모델 자신의 추론 (Inference)을 사실 (Fact)로 격상시킬 수 없음).)

재현성은 결정적인 증거입니다. 만약 리서치 에이전트가 동일한 질문에 대해 실행할 때마다 서로 다른 신뢰도를 제공한다면, 파이프라인 어딘가에서 LLM이 점수를 매기고 있는 것입니다. 그것을 찾아 함수 (Function)로 교체하십시오. 목표는 다음과 같습니다: 정확히 동일한 쿼리를 다시 실행했을 때, 정확히 동일한 FACT/INFERENCE 분할 결과를 얻는 것입니다.

6단계 파이프라인

각 단계가 독립적으로 테스트 가능하도록 단계를 명시적으로 만드십시오:

PLAN → HARVEST → NORMALIZE → CORROBORATE → SCORE → RENDER

• PLAN — 질문을 구체적인 하위 쿼리 (Sub-queries)와 시도할 출처들로 변환합니다.
• HARVEST — 여러 경로를 통해 가져옵니다 (아래 참조). LLM을 사용하지 않으며, 오직 수집 (Collection)만 수행합니다.
• NORMALIZE — LLM이 가져온 각 항목에서 구조화된 주장 (Structured claims)을 추출합니다. 모델이 데이터에 직접 관여하는 유일한 지점입니다.
• CORROBORATE — 주장들을 그룹화하고, 각 주장당 독립적인 출처의 개수를 계산합니다.
• SCORE — 규칙 (Rule)에 따라 라벨과 점수를 할당합니다.
• RENDER — FACT, INFERENCE, 그리고 명시적인 공백 목록 (Gap list)을 출력합니다.

FACT 게이트: 라벨을 획득하라

FACT는 기본값이 아닙니다. 그것은 주장이 반드시 획득해야 하는 상태이며, 타입 불변성 (Type invariant)으로서 강제됩니다:

# 증거 없이 FACT로 구성된 주장은 경고가 아니라 버그입니다.
Claim(provenance=FACT, evidence_ids=[])   # -> 에러 발생

...

"Independent"는 실제로 작동하고 있습니다: 한 블로그가 다른 블로그를 인용하는 것은 _하나_의 출처이지, 두 개가 아닙니다. 서로 다른 두 개의 도메인, 또는 단일 권위 있는 API(정부 데이터셋, 거래소 자체 엔드포인트 등)는 기준을 통과합니다. 그 외의 모든 것은 INFERENCE(추론)로 렌더링되며, 독자에게 정확히 그 상태로 보여집니다.

⚠️ 순서 의존성(order-dependence)을 주의하세요. 초기 버전에서는 점수가 처리 순서에 의존했기 때문에, 교차 검증된 FACT(사실)가 단일 출처의 INFERENCE(추론)보다 낮은 점수를 받는 경우가 있었습니다. 이는 재현성(reproducibility)을 조용히 깨뜨립니다. 점수는 주장(claim)이 처리된 순서와 무관하게, 주장과 그 증거(evidence)의 순수 함수(pure function)여야 합니다.

중복 없는 다중 경로 수집 (Multi-path harvest, without redundancy)

출처의 다양성은 상호 확인(corroboration)을 의미 있게 만들지만, 모든 출처를 동시에 가동하는 것은 낭비적이고 노이즈가 많습니다. 방송(broadcast)이 아닌 단계적 격상(escalation)을 사용하세요: 기본 검색을 시도하고, 첫 번째 경로가 불충분할 때만 다음 경로로 격상합니다.

동일한 쿼리를 세 개의 엔진에 동시에 보내지 마세요. 첫 번째 결과를 읽은 다음 격상 여부를 결정하십시오. 그리고 출처가 실패하거나 속도 제한(rate-limited)에 걸리면, 실패와 격상 과정을 로그로 남기세요. 누락된 가져오기(fetch)를 추측으로 대체해서는 절대 안 됩니다.

신선도(Freshness)와 공백(Gaps)은 일급 시민(first-class)입니다

두 가지 규칙이 출처(provenance)의 그림을 완성합니다. 신선도(Freshness): 모든 데이터는 확인 날짜를 포함하며, 임계값을 넘어서면 stale(오래된)로 표시하는 규칙이 적용됩니다. 지난 분기에 유효했던 사실은 현재의 사실로 조용히 제시되는 것이 아니라, 그 상태 그대로 표시됩니다. 공백(Gaps): 렌더링 단계에서는 요청되었으나 발견되지 않았거나 상호 확인되지 않은 항목의 명시적인 목록을 출력합니다. 침묵하는 공백은 완결성으로 오해받을 수 있으며, 이는 리서치 에이전트가 생성할 수 있는 가장 위험한 출력물입니다. 이를 표면화하는 것이 바로 FACT(사실) 목록을 신뢰할 수 있게 만드는 핵심입니다.

왜 이 구조가 가치가 있는가

그 결과물은 독자(또는 다운스트림 AI)가 각 주장(claim)별로 신뢰할 수 있는 리서치 결과물이 됩니다. 모든 FACT(사실)는 해당 사실을 도출해낸 독립적인 출처를 가리키며, 모든 INFERENCE(추론)는 에이전트 자체의 도약(leap)으로 표시됩니다. 데이터가 오래되었다면 그렇게 명시하며, 공백(gaps) 또한 이름이 붙여집니다. 모델은 여전히 자신이 잘하는 일인 읽기와 추출을 수행하지만, 무엇이 진실인지 결정하는 단계에는 결코 도달하지 않습니다. AI의 답변이 그 자체로 출처로 인용되는 시대에, 인용할 가치가 있는 에이전트는 규칙에 따라, 재현 가능하게, 그리고 자신의 확신도를 정직하게 라벨링하는 에이전트입니다.

AI 에이전트 플릿(fleet) 구축에 관한 추가 노트 — falsifier-driven AI decisions, reusable decision units, a file-based agent work-bus — hexisteme.github.io/notes에서 확인하세요.