AI 연구 제품들은 종종 인용(citations)을 표시하지만, 답변 하단에 나열된 링크의 행만으로는 그 답변이 어떻게 구축되었는지 알려주지 않습니다. 인용은 옆에 있는 문장을 뒷받침하지 않으면서도 해당 주제와는 관련이 있을 수 있습니다. 여러 개의 링크가 동일한 근거 소스를 반복할 수도 있습니다. 또한 모델은 노트를 유창한 산문으로 변환하는 과정에서 중요한 불확실성(uncertainty)을 누락할 수도 있습니다.

데이터 모델은 URL 이상의 것을 보존해야 합니다. 원래의 질문에서 연구 쿼리(research queries), 검색된 자료(retrieved material), 주장별로 그룹화된 증거(evidence), 그리고 최종 보고서에 이르는 경로를 보존해야 합니다. 우리는 그 경로를 증거 체인(evidence chain)이라고 부릅니다.

이 글은 이러한 체인을 재구성 가능하게 만드는 데이터베이스 및 파이프라인 경계(boundaries)에 초점을 맞춥니다.

흔한 지름길: 하나의 거대한 JSON 결과

가장 빠른 구현 방식은 보통 입력 질문과 그 외의 모든 것을 포함하는 하나의 JSON 컬럼을 가진 작업 테이블(job table)을 만드는 것입니다. 이는 제품이 운영상의 질문에 답해야 할 필요가 생기기 전까지는 작동합니다:

• 어떤 연구 쿼리(research query)가 이 소스를 찾아냈는가?
• 어떤 소스가 이 주장을 뒷받침했는가?
• 두 개의 인용이 동일한 도메인에서 왔는가?
• 이 페이지가 이전 크롤링(crawl)에서 재사용되었는가?
• 어떤 모델 단계(model stage)에서 문구가 변경되었는가?
• 크롤링을 반복하지 않고 요약을 다시 생성할 수 있는가?

단일 블롭(blob) 구조는 이러한 질문들을 비용이 많이 들고 취약하게 만듭니다. 모든 쿼리는 맞춤형 JSON 순회(traversal)가 되어야 하며, 키(keys)에 의해 강제되어야 할 관계들이 오직 관례(convention)에 의해서만 존재하게 됩니다.

더 나은 접근 방식은 원래의 실행(run)을 부모로 유지하면서, 중요한 산출물(artifacts)들에게는 각각의 레코드를 부여하는 것입니다.

1. 검색 실행(search run)부터 시작하기

검색 실행(search run)은 하나의 연구 질문과 그 생명주기(lifecycle)를 나타냅니다. 이는 상태(status), 타임스탬프(timestamps), 최종 보고서, 콘텐츠 메타데이터(content metadata), 그리고 게시 결정(publication decision)을 소유합니다.

실행(run)은 생성이 원자적(atomic)인 것처럼 가장해서는 안 됩니다. 실제 연구 워크플로우(research workflow)는 키워드를 확장하고, 여러 제공자(provider)를 검색하며, 페이지를 크롤링하고, 페이지 수준의 사실(page-level facts)을 추출하며, 증거를 집계하고, 보고서를 합성하고, 콘텐츠를 분류하며, 색인 가능성(indexability) 결과를 계산할 수 있습니다. 이러한 모든 단계는 동일한 실행 ID(run ID)를 참조해야 합니다.

이 부모 키(parent key)는 운영자가 관련 없는 로그 스트림(log streams) 간의 타임스탬프를 상관 분석(correlating)하지 않고도 하나의 실행을 재구성할 수 있게 해줍니다.

2. 연구 쿼리를 순서대로 저장하라

생성된 연구 쿼리(research queries)는 그 자체로 순서가 있는 레코드(ordered records)를 가질 가치가 있습니다. 순서가 중요한 이유는 시스템이 시도한 전략을 보여주며, 안정적인 인덱스(indices)는 재시도(retries)를 결정론적(deterministic)으로 만들기 때문입니다.

최소한의 쿼리 레코드에는 실행 ID(run ID), 쿼리 인덱스(query index), 그리고 쿼리 텍스트(query text)가 필요합니다. 또한 이를 생성한 프롬프트 버전(prompt version), 사용된 제공자(provider), 그리고 쿼리가 실행되었는지 또는 건너뛰어졌는지 여부도 포함하고 싶을 수 있습니다.

쿼리를 분리해 두면 답변 품질(answer quality)과 독립적으로 쿼리 품질(query quality)을 평가할 수 있습니다. 만약 보고서에서 중요한 관점이 누락되었다면, 그 공백이 쿼리 생성(query generation) 단계에서 발생했는지 아니면 이후의 검색(retrieval) 단계에서 발생했는지 파악할 수 있습니다.

3. 크롤링된 페이지를 아티팩트(artifacts)로 취급하라

검색 결과와 크롤링된 페이지는 입력값(inputs)이지, 아직 증거(evidence)가 아닙니다. 페이지 아티팩트(page artifact)는 실행(run), 아티팩트 유형(artifact type), 쿼리 또는 키워드, URL, 검색 메타데이터(retrieval metadata), 그리고 이후 단계에서 필요한 원시(raw) 또는 정규화된(normalized) 페이로드(payload)를 기록해야 합니다.

이러한 구분은 위험한 지름길을 방지합니다. 즉, 검색된 모든 페이지가 답변을 뒷받침한다고 가정하는 오류를 막아줍니다. 대부분의 검색 결과는 후보(candidates)일 뿐입니다. 어떤 것은 중복이며, 어떤 것은 주제만 언급하고, 어떤 것은 도출되고 있는 결론과 모순되기도 합니다.

페이지 아티팩트는 또한 깔끔한 캐싱 경계(caching boundary)를 생성합니다. 시스템은 새로운 질문에 대해 신선한 증거 추출(evidence extraction)을 실행하면서도, 동일한 URL에 대해서는 최근의 크롤링 데이터를 재사용할 수 있습니다. 검색의 신선도(retrieval freshness)와 주장 관련성(claim relevance)은 서로 다른 관심사이며 하나의 캐시 키(cache key)를 공유해서는 안 됩니다.

4. 주장을 중심으로 증거를 모델링하라

증거는 주장(claim)과 연결될 때 유용해집니다. 증거 레코드(evidence record)는 다음을 포함할 수 있습니다:

• 부모 실행 ID (parent run ID)
• 안정적인 증거 인덱스 (stable evidence index)
• 해당 증거가 뒷받침하거나 반박하는 주장 (claim)
• 연구 키워드 또는 쿼리 (research keyword or query)
• 출처 제목, 요약 및 URL
• 정규화된 도메인 (normalized domain)
• 관련성에 대한 설명
• 여러 구절이 하나의 항목을 뒷받침할 경우의 중첩된 출처 상세 정보 (nested source details)

주장 (claim) 필드가 핵심적인 부분입니다. 이는 검토자에게 검사 가능한 단위를 제공합니다. 검토자들은 단순히 출처가 "주제에 관한 것인가"를 묻는 대신, 해당 출처가 보고서에 나타날 특정 진술을 뒷받침하는지를 물을 수 있습니다.

이러한 구조는 렌더링된 마크다운 (Markdown)을 파싱하지 않고도 도메인 다양성 체크 (domain-diversity checks) 및 출처 개수 산출을 가능하게 합니다. 품질 규칙 (Quality rules)은 최종 페이지가 생성되기 전, 증거 레코드 (evidence records) 단계에서 작동해야 합니다.

5. 모델 호출 출처 (model-call provenance)를 콘텐츠 출처 (content provenance) 옆에 보관하라

콘텐츠 출처 (Content provenance)는 사실이 어디에서 왔는지를 설명합니다. 모델 호출 출처 (Model-call provenance)는 시스템이 해당 사실을 어떻게 변환했는지를 설명합니다. 재현성 (reproducibility)을 위해서는 이 두 가지가 모두 필요합니다.

각 단계마다 요청 메시지 (request messages), 구조화된 입력 (structured inputs), 가공되지 않은 제공자 응답 (raw provider response), 파싱된 출력 (parsed output), 모델 및 추론 설정 (model and reasoning configuration), 토큰 사용량 (token usage), 지연 시간 (latency), 프롬프트 버전 (prompt version), 그리고 오류 (errors)를 유지하십시오. 모든 호출을 동일한 실행 (run)에 연결하십시오.

이러한 관계를 통해 검토자는 양방향으로 이동할 수 있습니다:

• 보고서의 문장에서 해당 문장의 주장 (claim) 및 출처로 이동
• 의심스러운 출처에서 해당 출처를 소비한 추출 (extraction) 및 합성 (synthesis) 호출로 이동

이는 일반적인 "AI에 의해 생성됨"이라는 라벨보다 훨씬 더 실행 가능한(actionable) 정보입니다.

6. 최종 보고서를 저장하되, 이를 신뢰할 수 있는 단일 원천 (source of truth)으로 만들지 마라

최종 보고서는 프레젠테이션 산출물입니다. 마크다운 (Markdown)이나 HTML 형식일 수 있으며, 독자를 위한 인라인 링크를 포함할 수 있습니다. 하지만 출처 개수, 도메인 개수, 신뢰도 (confidence), 증거 충분성 (evidence sufficiency) 등은 생성 후 보고서를 스크래핑(scraping)해서 얻는 것이 아니라, 구조화된 데이터 (structured data)로부터 가져와야 합니다.

그러한 분리는 실질적인 이점을 제공합니다. 즉, 출처(provenance)를 파괴하지 않고도 프레젠테이션(presentation)을 변경할 수 있습니다. 동일한 기저의 증거 관계(evidence relationships)를 유지하면서 인용 구성 요소를 재설계하거나, 모바일용 요약을 생성하거나, API를 노출할 수 있습니다.

7. 불충분함(insufficiency)을 유효한 결과로 만들기

증거 체인(evidence chain)은 게시 가능한 답변 없이 종료될 수 있어야 합니다. 만약 검색(retrieval) 결과 소스가 너무 적거나, 도메인들이 독립적이지 않거나, 증거가 서로 충돌하는 경우, 실행은 불충분함 플래그(insufficiency flag)와 명확한 이유를 남긴 채 완료될 수 있습니다.

이것은 파이프라인(pipeline)의 실패가 아닙니다. 하나의 연구 결과입니다. 불충분함을 데이터로 취급함으로써, 시스템이 단순히 성공 상태를 충족시키기 위해 공백을 더 확신에 찬 문장으로 채워 넣는 것을 방지할 수 있습니다.

8. 체인의 충분한 부분을 독자에게 노출하기

내부 로그(internal logs)에는 민감하거나 운영적인 세부 사항이 포함될 수 있으므로, 이를 공개 페이지에 그대로 쏟아내서는 안 됩니다. 독자들은 신중하게 선택된 공개 인터페이스(public surface)를 통해 여전히 이점을 얻을 수 있습니다:

• 가시적인 소스 링크 (visible source links)
• 소스 제목 및 도메인 (source titles and domains)
• 주장 중심의 증거 그룹 (claim-oriented evidence groups)
• 수정 및 출처 표기 채널 (correction and attribution channels)
• 방법론 및 편집 정책 페이지 (methodology and editorial policy pages)

공개된 Omniracle 방법론은 신호 발견(signal discovery), 연구(research), 증거(evidence), 모델 출처(model provenance), 그리고 게시 게이트(publication gates)가 어떻게 서로 맞물려 있는지 설명합니다. 권장 보고서는 해당 아키텍처(architecture)의 독자 지향적인 측면을 보여줍니다.

유용한 멘탈 모델 (Mental Model)

파이프라인을 다음과 같은 유향 체인(directed chain)으로 생각하십시오:

질문(question) → 연구 쿼리(research queries) → 페이지 아티팩트(page artifacts) → 주장 증거(claim evidence) → 합성 호출(synthesis calls) → 최종 보고서(final report) → 게시 결정(publication decision)

각 화살표는 나중에 유사한 텍스트로부터 추론되는 것이 아니라, 지속 가능한 관계(durable relationship)로 표현되어야 합니다. 결과에 이의가 제기되었을 때, 시스템은 가장 중요한 엔지니어링 질문에 답할 수 있어야 합니다. 단순히 "어떤 링크가 보여졌는가?"가 아니라, "이 주장이 원본 자료로부터 게시된 답변에 이르기까지 어떻게 전달되었는가?"라는 질문 말입니다.

그것이 바로 인용 장식(citation decoration)과 감사 가능한 연구 시스템(auditable research system)의 차이입니다.