RAG가 '빠짐없이 찾기'를 요구할 때: Agentic RAG 경계 탐색과 LLM Wiki 전환

30초 판단: 당신도 "검색 결과는 모두 관련 있어 보이는데 핵심 하위 주제는 항상 빠진다"는 상황을 겪고 있다면, 이 글의 가치는 두 가지다. 우리가 당신을 대신해 프롬프트, 쿼리 확장, facet, 감사, reranker, 섹션 라우팅을 체계적으로 시험해 보았고, 각각이 왜 충분하지 않은지를 명시했다. 동시에 최근 논문을 통해 이것이 단순히 프로젝트 파라미터를 다시 조금 조정하는 것으로 해결되는 문제가 아니라는 점을 설명한다.

누가 읽으면 좋은가: Agentic RAG, 지식 베이스 질의응답, 주제 연구, 장문 답변 검색 또는 LLM Wiki를 만들고 있는 엔지니어와 프로덕트 책임자.

시리즈 위치: 이 글은 05 · Agentic RAG 검색 측 구현에 이어지는 글이다. 앞선 글에서는 블록 수준 도구가 어떻게 신뢰할 수 있는 Agent 검색 체인을 형성하는지를 다루었다. 이번 글은 문제가 "관련 증거 찾기"에서 "주제를 중심으로 빠짐없이 찾기"로 바뀔 때 이 체인이 어디에서 실패하는지를 논의한다.

코드 베이스: lipeidonggz/ai-study-helper-v2

연구 증거: 065 주제 커버리지 실험 · 066 섹션 라우팅 실험 · 동결 tag

증거 표시: ✅ 프로젝트 실측; 🧪 회귀 가능; 🤔 현재 판단.本文에서 인용한 공개 논문과 WeKnora 실험은 이 프로젝트의 실측 결과가 아니며, 해당 문단에서 별도로 표기한다.

1. 결론부터: 방법이 없는 것이 아니라, 합의된 폐쇄 루프가 없는 것이다

Agentic RAG는 쉽게 착각을 일으킨다. Agent에게 더 많은 도구, 더 많은 라운드, 더 많은 쿼리를 주기만 하면 결국 관련 내용을 다 찾아낼 수 있을 것이라는 착각이다.

실측 결과는 그렇지 않다.

Agent는 계속 검색할 수 있지만, 현재의 검색 결과만으로는 다음을 판단할 수 없다.

- 이 주제가 어떤 의미적 면들을 포함해야 하는가;

- 어떤 면이 이미 증거로 커버되었는가;

- 어떤 것이 단지 관련 있지만 중복된 개요일 뿐인가;

- 현재 결과에서 빠진 것이 "지식 베이스에 없는 것"인지 "이번에 못 찾은 것"인지;

- 언제 멈출 수 있는가.

따라서 이 글이 전달하려는 핵심 판단은 "Agentic RAG는 빠짐없이 찾을 수 없다"가 아니라 다음과 같다.

주제 커버리지 유형의 문제에서 Agentic RAG는 이미 후보 회수를 확대할 수 있다. 그러나 우리가 조사한 최근 연구와 엔지니어링 실천에서는 의미적 면 발견, 커버리지 판단, 증거 출처 역추적, 지식 갱신을 동시에 처리하는 합의된 방안이 아직 형성되지 않았다.

이 판단에는 두 가지 근거가 있다.

첫째, 우리는 한 번의 실패에서 멈추지 않고 Agent 프롬프트, 강제 커버리지 설명, 쿼리 확장, 명사별 검색, facet 계획, 결손 감사, 증거 reranker, 섹션 라우팅을 차례로 시험했다. 각 단계는 문제의 일부를 해결했지만 모두 새로운 공백을 남겼다.

둘째, 최근 연구는 각각 커버리지 인지 검색, 집합 커버리지 선택, 커버리지 평가에서 진전을 이루었지만, "주어진 주제에 대해 찾아야 할 면들을 안정적으로 발견하고, 이미 빠짐없이 찾았다는 것을 증명하는" 엔드투엔드 역량을 직접 제공하는 것은 하나도 없었다.

2. 전정: 왜 처음에는 LLM Wiki를 하지 않았는가

프로젝트가 처음에 증강 블록 검색과 Agentic RAG를 채택한 것은 명확한 트레이드오프를 거친 선택이었다.

시스템에는 이미 다음이 있었다.

- SectionTree / BlockSet;

- dense 및 전문 검색 이중 인덱스;

- 동결 collection 스냅샷;

- search_blocks, get_outline, list_blocks, scan_term 등의 도구;

- Agent 다중 라운드 검색과 재조회;

- 원본 block 인용.

이 아키텍처가 제공하는 능력은 프로젝트의 고정 사용 사례에 직접 적용될 수 있다. 전체 18개 사용 사례와 그 골드 스탠더드는 03 · 사용 사례 집합과 골드 스탠더드를 참조하라.

아래에는 원문 질문을 그대로 유지하며改写하지 않는다.

c1-001:

Anthropic《How we contain Claude》에서 MCP를 언급했나요?

c3-001:

"사용자가 권한 알림의 약 93%를 승인했다"라는 문장은 어디에 있고, 앞뒤 맥락은 무엇인가요?

c6-001:

샌드박스, 출구 제어, 가상 머신은 containment에서 각각 무엇을 막고, 서로 어떻게 협력하나요?

c8-001:

OpenAI《Harness engineering》과 Anthropic《How we contain Claude》를 합치면 "에이전트 시대의 엔지니어링"에 대해 어떤 전체 그림을 그리는가?

c14-001:

"MCP는 새로운 공격 표면"이라는 말은 Anthropic《How we contain Claude》에 원문 근거가 있나요? 아니면 모델이 보충한 것인가요?

c15-001:

Anthropic《How we contain Claude》의 세 가지 격리 모드를 표로 정리하라: 모드 / 제품 / 메커니즘 / 위협 모델 / 비용.

이 질문들의 공통점은 검색 목표를 하나 또는 몇 개의 명확한 쿼리로 표현할 수 있다는 것이다. 출처를 넘나드는 종합이 필요하더라도 문서 범위와 비교 대상은 여전히 명확하다. 블록 수준 검색은 증거를 찾는 역할을, Agent는 계속 조회하고 선별하고 종합하는 역할을 맡는다.

저장 및 검색 전략은 따라서 다음과 같이 먼저 선택되었다.

증강 벡터 블록 + Agentic 검색 ↓ 실측에서 "면적형 커버리지 / 페이지 넘나드는 개념 집계" 공백이 나타나고, 기존 방안으로 반복해서 해결되지 않을 때에만 ↓ Wiki 도입

LLM Wiki는 추가 컴파일이 필요하고, 페이지에 "문단 → 원본 block" 출처 역추적 체인을 보충해야 한다. 그것은 기본 출발점이 아니라 트리거 조건이 있는 아키텍처 옵션이다.

3. c13-003: 겉보기엔 정상적이지만 실제로 매우 어려운 문제

트리거 조건은 결국 문서 간 회귀 프로브 c13-003에 의해 충족되었다. 그 전체 문제는 다음과 같다.

현재 지식 베이스에서 샌드박스, 가상 머신, 출구 제어 외에 AI Agent에는 어떤 격리 또는 제어 경계가 있나요? 각각 무엇을 제한하는지 각각 설명하세요.

메인 Agent가 주제 커버리지 도구를 호출할 때 검색 입력은 추가로 다음과 같이 수렴된다.

AI Agent 격리 및 제어 경계

이 단계는 역할을 나누는 것이다. 메인 Agent는 "왜 묻는지, 최종적으로 어떻게 답할지"를 유지하고, 커버리지 도구는 주제를 중심으로 증거를 수집하는 역할만 맡는다.

테스트 지식 베이스는 15편의 HTML로, 총 526개 block, 328개 section-tree 노드이다. 문서 출처는 Anthropic 6편, OpenAI 2편, Lilian Weng 3편, Chip Huyen 1편, Eugene Yan 1편, Hamel 2편을 포함한다. 답변에 필요한 증거는 한 문서에 집중되어 있지 않다.

3.1 첫 번째 필수 판정 기준(R1)은 무엇을 요구하는가

c13-003의 첫 번째 필수 판정 기준(R1)은 "문서 간 핵심 격리 경계 전면 커버"를 요구한다. 답변은 일곱 가지 경계를 의미적으로 커버하고, 각각 제한 대상 또는 제한 위험을 설명해야 한다. 괄호 안의 worktree, checkpoint, 독립 session 등은 선택적 예시일 뿐이다.

- 파일 및 작업 공간 접근 경계: Agent가 접근, 읽기, 수정 또는 삭제할 수 있는 파일과 데이터 범위를 제한한다.

- 자격 증명 및 신원 경계: Agent가 획득하거나 대신 사용할 수 있는 신원 및 자격 증명을 제한한다.

- 도구 및 행동 능력 경계: Agent가 어떤 도구를 호출하고 어떤 작업을 실행할 수 있는지 제한한다.

- 외부 콘텐츠 및 도구 결과 신뢰 경계: 웹페이지, 파일, 도구 결과 등이 검사 전에 컨텍스트 또는 행동에 영향을 미치는 것을 제한한다.

- 병렬 작업 및 작업 상태 경계: 병렬 작업 간의 수정 충돌, 되돌릴 수 없음, 상태 오염을 제한한다.

- 컨텍스트 및 기억 수명주기 경계: 무관하거나 오염된 컨텍스트가 작업 간에 누적되는 것, 그리고 장기 기억의 기록 및 재사용을 제한한다.

- 하위 Agent 위임 경계: 하위 Agent가 얻는 컨텍스트, 도구, 책임, 반환 정보를 제한한다.

후속 실험에서는 그중 세 가지 구체적 block을 회귀 탐침으로 사용한다. 이들은 일곱 가지 경계 그룹과 일대일로 대응하지 않으며, 각각 하나의 그룹 또는 인접한 두 그룹의 증거 의무에 해당한다.

회귀 탐침 / 대응하는 필수 경계 / 구체적 의미 / worktree·작업 공간 격리 / ① 파일 및 작업 공간 접근 경계; ⑤ 병렬 작업 및 작업 상태 경계 / 독립 checkout은 파일 수정 범위와 병렬 세션 간의 수정 충돌을 동시에 제한한다 / checkpoint 복구 / ⑤ 병렬 작업 및 작업 상태 경계 / 긴 작업이 실패 지점부터 계속되게 하여 복구 불가능한 상태를 제한한다. 작업 간 컨텍스트나 장기 기억을 추가로 설명할 때에만 ⑥을 뒷받침할 수 있다 / 복구 정확성 평가 / ⑤ 병렬 작업 및 작업 상태 경계; 부분적으로 ⑥ 관련 / 여러 라운드의 상태 변화 후 최종 상태가 올바른지 검사하지만, 그 자체로는 컨텍스트 및 기억 수명주기를 완전히 커버할 수 없다

이들은 완전한 수동 관련성 라벨링 세트가 아니다. 세 가지 알려진 누락 지점만 검증할 수 있을 뿐, 전체 주제의 재현율을 계산할 수는 없다. 탐침으로 선정한 이유는 초기 버전의 실패가 이미 이들이 구체적이고 검증 가능하며, 단일 문서 개요에 가장 쉽게 가려진다는 것을 입증했기 때문이다. 후속 비교 대상은 이 세 가지 알려진 누락 지점이 각각 되찾아졌는지 여부다.

답안은 자체적인 분류와 표현을 사용할 수 있지만, 명칭만 나열하고 ‘무엇을 제한하는지’ 설명하지 않으면 커버로 인정되지 않는다. R1은 ‘안전 관련 단어가 몇 개 나오면 점수를 주는’ 방식이 될 수 없다.

3.2 왜 금표준이 이렇게 엄격해야 하는가

몇 가지 안전 조치를 나열하기만 요구한다면, Agent가 《How we contain Claude》를 완전히 읽은 후 샌드박스, 가상 머신, 출구 제어, 자격 증명 격리, 도구 권한, 인간 개입(in the loop) 등 꽤 그럴듯한 답안을 제시할 수 있다.

그러나 worktree, checkpoint 복구, 컨텍스트 수명주기, 하위 Agent 위임 등의 메커니즘은 다른 문서에 분산되어 있다. 단일 문서 요약은 유창하고 정직하며 인용도 정확할 수 있지만, 여전히 과업을 완수하지 못한다.

이 판정 기준이 검출하려는 것은 ‘답안이 안전 개요처럼 보이는가’가 아니라 다음과 같다.

- Agent가 ‘현재 지식베이스’라는 넓은 범위에서 관련 문서를 계속 발견하는가;

- 여러 문서가 공동으로 구성하는 증거 면을 찾아냈는가;

- 각 메커니즘이 제한하는 구체적 대상이나 위험을 이해했는가;

- ‘한 편만 읽은 것’을 ‘지식베이스가 이미 커버했다’고 오인했는가.

또한 강조해야 한다. **R1은 최종 답안이 판정 기준을 충족하는지만 보며, Agent에 대한 프롬프트가 아니다.** Agent는 이 일곱 그룹의 답안을 볼 수 없고, 스스로 탐색해 내야 한다.

R1 외에도, 사용 사례는 네 가지 확장 경계 중 최소 두 가지 범주를 커버할 것을 요구하며, ‘지식베이스에는 이것들만 있다’, ‘기타 문서는 모두 다루지 않는다’ 등 검증 근거가 없는 배타적 단정의 사용을 금지한다.

4. 첫 번째 층 시도: Agent가 스스로 조금 더 찾게 하기

가장 자연스러운 발상은 계속 Agentic RAG를 사용하는 것이다. 도구는 모두 갖춰져 있으니, 범위·완전성·정지 조건에 주의하라고 프롬프트하면 스스로 확장할 수 있을 것이다.

4.1 Agent는 모든 문서를 보았지만, 한 편만 읽었다

자연스러운 문제 제시에서의 첫 번째 N=10 실행에서, 10개 trace 모두 다음을 실행했다.

list_documents → get_outline → list_blocks

또한 현재 지식베이스의 15개 문서를 보았지만, 어떤 샘플도 실제로 두 번째 문서를 읽지 않았다. 그 결과 R1 일곱 그룹 핵심 경계는 0/10이었다. 참조 답안은 《How we contain Claude》 한 편에 대한 완전한 요약으로 퇴화했다.

이는 실패 지점이 ‘Agent가 어떤 문서가 있는지 모른다’가 아니라, ‘현재 가장 관련 있는 문서를 이미 다 읽었다’를 ‘넓은 범위의 문제가 이미 커버되었다’로 해석했다는 것을 보여준다.

4.2 일반 범위 프롬프트를 추가해도 행동은 바뀌지 않았다

다음 라운드에서는 키워드 규칙을 더 일반적인 ‘증거 범위와 완전성 책임’으로 바꾸었고, ‘격리’, ‘worktree’, ‘하위 Agent’ 등 사용 사례 용어는 쓰지 않았다.

이것은 막연한 ‘전면적으로 답하세요’ 한 마디가 아니다. chat-v18은 아래 두 단락의 규칙을 명확히 새로 추가했다.

완전성 책임을 지는 자료 집합에 대해, ‘고관련 증거를 한 곳 발견했다’는 정지 조건이 아니다. 후보 집합을 합리적으로 이미 처리했거나, 예산상 계속 검사할 수 없는 후보를 명확히 기록한 후에야 위 조건에 따라 종료할 수 있다.

먼저 후보 집합을 구축한 뒤 증거를 읽는다. 후보 집합은 제목이나 한 번의 검색에서만 나와서는 안 된다. 여러 상호 보완적인 증거 발견 관점을 사용하고, 동일한 표현의 반복 검색을 피한다. 출처별로 집계·중복 제거하고, 어떤 후보가 처리되었는지, 제외되었는지, 아직 처리되지 않았는지 검사한다.

규칙이 이미 ‘후보 집합’, ‘여러 상호 보완적 관점’, ‘어떤 후보가 아직 처리되지 않았는지’의 세밀도까지 직접 쓰여 있었지만, 여전히 Agent가 두 번째 문서를 읽게 하지 못했다.

결과는 다음과 같다.

- R1은 여전히 0/10;

- 10/10 trace가 여전히 한 편만 읽음;

- 다문서 검색 샘플은 여전히 0;

- 입력 token이 약 6% 증가.

프롬프트는 모델이 ‘내 증거 범위가 무엇인지’를 더 잘 설명하게 만들었지만, 후보를 먼저 확장하게 만들지는 못했다.

4.3 종료 근거 설명을 강제해도, 합리화된 이유만 얻었다

더 나아가 ‘종료 근거’를 구조화된 프로토콜의 필수 항목으로 설정하여, 정상 완료와 강등 모두 이유를 설명하도록 요구했다.

원래 finish는 답안만 반환하면 되었다.

{ "type" : "finish" , "answer" : "최종 답안" }

chat-v19는 이를 다음과 같이 바꾸었다.

{ "type" : "finish" , "answer" : "최종 답안" , "decision_summary" : "증거 범위, 그리고 왜 정상 종료할 수 있는지 또는 강등만 가능한지 설명" }

동시에 종료 조건을 더욱 엄격하게 조였다.

완전성 책임을 지는 질문에 대해, ‘고관련 증거를 한 곳 발견했다’는 정지 조건이 아니다. 반드시 후보 범위를 먼저 구축·처리하거나, 명확한 강등 조건이 발동되었음을 확인해야 한다.

결과적으로 세 가지 종료 이유가 나타났다.

- ‘해당 문서 범위 내에서 완전히 커버되었다’;

- ‘기타 문서는 주제가 무관하여 계속 검색할 필요가 없다’;

- ‘기타 문서를 하나하나 검사하지 않았으므로 범위 한정으로 강등한다’.

문제는 이 설명들이 여전히 한 편만 읽었다는 사실에 기반한다는 점이다. self-reflection을 강제해도 후보 발견을 촉진하지 못했고, 오히려 초래한 것은 다음과 같다.

- 3개 제품 프로토콜 실패;

- 약 2배의 입력 token;

- 더 많은 라운드와 도구 호출;

- 그럴듯해 보이지만 실제로는 증거가 없는, 더 많은 중단 사유.

이 규칙은 최종적으로 철회되었다.

이 계층의 탐색은 하나의 중요한 결론을 얻었다:

Agentic RAG에 현재 부족한 것은 '한 번 더 생각하는 것'이나 '한 번 더 설명하는 것'이 아니라, 검사 가능한 커버리지 상태이다. 이 상태표가 없으면, 다중 라운드 루프는 행동만 늘릴 뿐 커버리지를 증명할 수 없다.

전체 prompt hash, 세 버전 run 지표, 원문 diff, trace 번호 및 실패 분석은 c13-003 의미 커버리지 실험에서 확인할 수 있다.

5. 두 번째 계층 시도: 커버리지 문제를 전용 도구로 분해하기

프롬프트 실험은 다음을 보여준다: 메인 Agent에게 계속 '더 전면적으로' 요구하는 것만으로는 그 검색 범위를 바꿀 수 없다. 문제는 이미 query를 잘 쓰느냐의 문제가 아니라, 메인 Agent가 목표 이해, 후보 발견, 완전성 판단, 답변 구성 등 여러 책임을 동시에 맡고 있다는 것이다.

따라서 하나의 핵심 결정이 등장했다: 커버리지 계획과 증거 판단을 메인 Agent의 자유 루프에서 분리하여 전용 도구로 제공한다.

5.1 핵심 결정: search_topic(topic)으로 커버리지 흐름을 담당하게 하기

메인 Agent는 계속 다음을 담당한다:

- 언제 전부 찾아야 하는지 판단;

- 커버리지 도구에 넘길 주제를 선택;

- 반환된 증거를 사용해 최종 답변 구성;

- 충돌, 취사선택, 표현 처리.

전용 도구는 다음만 받는다:

search_topic (topic)

도구는 내부에서 더 집중된 하나의 체인을 완료한다:

주제 → 주제 설명 → hybrid seed로 현재 코퍼스 관찰 → facet 계획 → facet 결측 감사 → dense／keyword 쿼리 확장 → 후보 병합 → facet별 증거 지지 판단 → 지지 블록 반환

다음은 네 구간 prompt의 핵심 원문 발췌이며, 가독성을 위해 XML 태그와 대형 schema는 생략했다:

당신은 지식베이스 검색 주제에 대한 완전한 설명을 생성하는 역할을 맡는다. 당신은 사용자 질문에 답하지 않으며, 쿼리도 생성하지 않는다. topic에 대해 상세하고 완전하며 구체적인 설명을 하고, Markdown으로 조직하라. 설명은 개념, 목표, 대상, 메커니즘, 구현 방식, 경계, 시나리오, 리스크 및 트레이드오프를 포괄해야 하며, 구체적인 기술 용어와 제약 관계를 보존해야 한다.

'사용자 질문에 답하지 않으며, 쿼리도 생성하지 않는다'는 것이 여기서 가장 핵심적인 책임 제약이다. 이는 모델이 주제를 미리 몇 개의 검색어로 압축하는 대신, 주제 의미를 구성하는 데 집중하게 한다.

이 분리는 세 가지 직접적인 효과가 있다.

첫째, 메인 Agent는 더 이상 하나의 일반 프롬프트로 답변과 커버리지를 동시에 완료할 필요가 없으며, 도구 내부의 각 LLM 단계는 오직 하나의 명확한 문제만 해결한다: 주제 설명, 증거 의무 제기, 결측 감사, 쿼리 생성 또는 후보 지지 판단.

둘째, 도구 입력은 topic만 유지하며, 현재 문제의 retrieval_goal이나 예상 답변 형식을 읽지 않는다. 따라서 커버리지 집합은 특정 답변으로부터 독립적이며, 재사용되고 별도로 진단될 수 있다.

셋째, 계획, 감사, 쿼리 및 reranker가 모두 동일한 trace에 들어가, '왜 이런 증거를 반환했는가'를 관찰하고 회귀할 수 있게 하며, 메인 Agent의 한 번의 자유 추론 속에 숨지 않게 한다.

이 단계는 여전히 실험 가설이며, 성공 결론이 아니다. 아래의 쿼리 확장, facet contract 및 reranker는 모두 이 전용 도구 내부의 구성 요소이다.

도구 책임, 입출력 및 실패 의미는 고정 스냅샷의 11 · 코퍼스 앵커링 주제 커버리지 검색에서 확인할 수 있다.

5.2 주제 설명을 벡터 쿼리로만 만드는 것으로는 부족하다

이번 라운드는 단순히 쿼리 수를 늘리는 것이 아니라, 하나의 쿼리 재작성 방식을 검증하는 것이다: 원본 topic이 너무 짧다면, 모델이 먼저 완전한 설명을 생성하고, 그 설명을 의미 단위로 여러 개의 dense 쿼리로 잘라, 각 쿼리가 자동으로 하나의 잠재적 증거 면에 대응하게 할 수 있는가?

배후의 가설은 다음과 같다:

- LLM은 원본 topic보다 더 완전한 주제 설명을 생성할 수 있다;

- 설명은 이미 여러 의미 면을 포함한다;

- 설명을 조각으로 자르면 각 조각이 하나의 독립적 쿼리로 사용될 수 있다;

- 여러 쿼리의 후보를 병합하면 지식베이스에 분산된 증거를 커버할 수 있다.

실험은 17개의 설명 조각을 사용했고, 각각 Top-20을 취했으며, 쿼리 결과를 중복 제거한 뒤 76～107개의 후보를 형성했지만, 세 개의 회귀 프로브 중에서는 단지 0～1개만 찾아냈다.

설명은 주제가 '대략 무엇을 포함하는지'를 설명할 수 있지만, 지식베이스 특유의 worktree, checkpoint 등의 용어를 자동으로 생성하지 못하며, 각 설명 조각이 하나의 독립적 증거 의무에 대응함을 보장할 수도 없다. 후보는 개요와 유사한 표현에 집중되어, 모두 관련 있어 보이지만 반드시 새로운 커버리지를 가져오지는 않는다.

따라서 이 실험이 실제로 배제한 것은:

'모델이 주제를 더 완전하게 설명하고, 그 설명을 잘게 쪼개 검색하기만 하면 자동으로 주제 커버리지를 얻을 수 있다.'

그것은 설명 자체의 가치를 배제하지 않았다. 후속 설명은 여전히 유지되지만, 책임이 '직접 쿼리 생성'에서 'corpus-grounded facet planner에 보조 컨텍스트 제공'으로 바뀐다.

5.3 설명에서 명사를 하나씩 전부 뽑아 전문 검색하면, 재현율은 충분하지만 선별이 전혀 없다

계속해서 설명을 명사로 쪼개고, FTS(전문 검색, 내부적으로 BM25 정렬)를 통해 항목별로 검색하자, worktree, checkpoint 복구 및 복구 정확성 평가라는 세 가지 프로브가 모두 찾아졌다.

그 대가는 다음과 같다:

- 346개의 쿼리;

- 511/526개 block 재현;

- 거의 전체 지식베이스가 반환됨.

이는 수학적으로 '고재현율'이라고 하지만, 제품 관점에서는 검색을 완료하지 못한 것이다. 선별 능력 없는 '전부 찾기'는 선별 비용을 읽기 단계로 떠넘길 뿐이다.

5.4 쿼리, facet 및 증거 판단을 완전한 도구 체인으로 연결하기

이 절은 facet planner를 따로 평가하는 것이 아니라, facet, 다중 쿼리 및 증거 판단을 완전한 커버리지 도구로 조합하는 것이다. 먼저 그중 첫 번째 계층을 보자: 의미 면이 현재 코퍼스에 의해 제약되게 하는 방법.

5.4.1 corpus-grounded facet: 의미 면을 현재 코퍼스에 의해 제약되게 하기

이전 라운드는 설명식 쿼리가 각 조각을 '더 주제처럼' 표현할 수는 있지만, 이 조각들이 지식베이스의 실제 증거 의무에 대응함을 보장할 수는 없다는 것을 보여주었다. 다음 단계에서 검증할 것은:

모델이 먼저 현재 지식베이스에서 실제로 적중한 본문과 문서 구조를 보게 한 뒤 커버리지 면을 계획하게 하면, 일반적 분류를 줄이고 지식베이스에서 검색 가능하고 판단 가능한 구체적 증거 의무를 산출할 수 있는가?

여기서의 가설은 세 가지다:

- seed block 전문은 모델 파라미터 지식에만 의존해 추측하는 것이 아니라, 지식베이스가 실제로 사용하는 용어, 상태 및 메커니즘을 제공할 수 있다;

- 문서 개요는 동일 문서에서 적중한 장과 인접하거나, 병렬이거나, 상하위로 관련되지만 아직 적중하지 않은 영역을 암시할 수 있다;

- 각 facet이 evidence obligation, coverage question, seed refs를 바인딩하고 있다면, 이후의 쿼리와 reranker는 동일한 정의를 중심으로 작동할 수 있다.

따라서 프로세스는 먼저 주제로 hybrid seed 검색을 수행하고, 적중한 block의 전문과 소속 문서 개요를 모델에 넘긴 뒤, 현재 코퍼스를 기반으로 의미면(facet)을 계획하게 한다. 이는 이전 라운드와 "모델에게 한 번 더 묻는" 것과의 차이가 아니라, facet을 모델이 스스로 만들어낸 분류에서 현재 코퍼스에 의해 제약되는 검색 의무로 바꾸는 것이다.

각 facet은 반드시 다음을 갖춘다:

- scope: 의미 경계;

- evidence_obligation: 어떤 증거를 찾아야 하는지;

- coverage_question: 찾은 후 반드시 답할 수 있어야 하는 것;

- required_relation: 증거가 반드시 표현해야 하는 메커니즘, 조건 또는 인과관계;

- origin: 코퍼스에서 왔는지, 가설에서 왔는지, 아니면 둘 다인지;

- seed_refs: 어떤 실제 block이 이 facet을 뒷받침하는지;

- dense 쿼리와 keyword 쿼리.

facet planner의 실제 prompt는 모델에게 "관련 측면 몇 개를 나열하라"고 하는 것이 아니라, 핵심 규칙은 다음과 같다:

각 facet은 일반화된 분류가 아니라 검증 가능한 증거 의무를 나타낸다. evidence_obligation은 반드시 찾아야 할 객체, 메커니즘, 상태, 프로세스 또는 리스크를 설명한다. coverage_question은 검색이 완료된 후 명확히 답할 수 있어야 하는 구체적인 질문이다. required_relation은 증거가 반드시 표현해야 하는 구체적인 제약, 메커니즘, 상태, 인과 또는 작용 관계를 설명한다. 서로 다른 facet은 단순히 동의어로 바꿔 쓴 것이어서는 안 되며, 하나의 "모든 방식" 총분류로 세부 사항을 대체해서는 안 된다.

5.4.2 facet audit: 검색 전에 결측 항목과 과도한 광범위함 점검

이어서 facet audit으로 다음을 점검한다:

- 중요한 메커니즘이 어떤 facet에도 빠지지 않았는지;

- 여러 독립적인 증거 의무가 혼합되어 있지는 않은지;

- 의미상 중복이 존재하지 않는지;

- 코퍼스 근거가 부족한 가설이 존재하지 않는지;

- 단일 문서나 단일 분류 프레임워크에 의해 편향되지 않았는지.

audit prompt의 역할과 점검 항목 원문은 다음과 같다:

너는 주제 커버리지 완전성 감사기다. 너는 사용자 질문에 답하지 않으며 검색도 수행하지 않는다. 다음을 항목별로 점검하라: 1. topic, explanation 또는 입력 코퍼스에 등장하는 중요한 개념, 메커니즘, 객체, 상태, 프로세스, 리스크와 트레이드오프가 어떤 facet에도 포함되지 않았는지; 2. 하나의 facet에 독립적으로 검색하고 독립적으로 판단할 수 있는 여러 증거 의무가 혼합되어 있지는 않은지; 3. 여러 facet이 단지 동의어로 바꿔 쓴 것에 불과하거나 마땅히 병합되어야 하는 것은 아닌지; 4. 일반화된 분류, 검색을 지도할 수 없는 또는 코퍼스 근거가 없는 corpus facet이 존재하지 않는지; 5. 초기 facets가 단일 해석, 단일 문서 또는 단일 분류 프레임워크의 영향을 받지 않았는지.

이것은 자유로운 query expansion보다 검증 가능한 커버리지 계약에 더 가깝다.

완전한 구현과 실패 탐침(probe)은 고정 스냅샷의 065 슬라이스에서, 계획과 감사 실험은 facet 안정성 실험에서 볼 수 있다.

🧪 이 체인에는 이미 회귀 테스트가 있으며, 불법 facet, 미지의 후보, reranker의 구조화 출력 실패, 스냅샷 경계, 그리고 "실패 시 부분 성공을 반환해서는 안 됨"을 포괄한다. 이 테스트들은 실패 의미론이 조용히 성능이 저하되지 않는다는 것을 증명하지만, 커버리지 품질이 이미 안정적이라는 것을 증명하지는 않는다.

5.4.3 다중 쿼리와 reranker: 후보를 지원 증거로 수렴시키기

planner는 각 facet에 대해 dense와 keyword 쿼리를 생성한다. 시스템은 먼저 문자열 기준으로 중복을 제거한 다음, 각각 후보를 소환(recall)하고 facet별로 병합 및 정규화한다. 각 facet은 먼저 하나의 후보 쇼트리스트를 유지한 뒤, reranker가 후보가 구체적인 증거 의무를 실제로 뒷받침하는지 점검한다.

여기서의 reranker는 하나의 block이 특정 facet의 증거 의무를 실제로 충족하는지를 판단하는 모델이다.

그 핵심 판단 규칙 원문은 다음과 같다:

각 candidate에 대해 전체 facet_catalog를 점검하라; provenance_facets는 단지 소환 힌트일 뿐이다. 판단 근거는 facet의 evidence_obligation, coverage_question 및 required_relation이며, name이나 scope에만 근거해서는 안 된다. direct: 본문이 해당 facet의 증거 의무와 필요 관계를 명확히 충족한다. partial: 본문이 해당 facet의 일부 객체, 메커니즘 또는 리스크를 포괄하지만 관계를 충분히 충족하지는 못한다. 같은 단어가 등장했다는 이유만으로 direct로 판정해서는 안 된다.

완전한 프롬프트는 고정 스냅샷의 corpus_grounded_coverage.py에서 볼 수 있으며, 버전은 각각 explanation-v1, facet-planner-v6, facet-audit-v3, reranker-v3이다.

5.5 전체 툴체인의 결과: 커버리지 계획을 형성할 수 있지만 여전히 불안정

facet planner, facet audit, 다중 쿼리 소환 및 reranker를 완전한 도구로 연결한 후, 시스템은 이미 구조화된 커버리지 계획을 형성할 수 있고 facet이 뒷받침하는 여러 block을 반환할 수도 있다. 그러나 같은 주제가 동일한 스냅샷에서의 계획과 최종 결과는 여전히 뚜렷하게 변동한다.

✅ 프로젝트 실측에서, 같은 주제가 동일한 스냅샷에서 약 14~24개의 facets를 생성하고, 약 136~192개의 쿼리로 확장하며, 약 53~75개의 지원 블록을 반환했다; 세 개의 회귀 탐침의 적중 수는 1~3개 사이에서 변동했는데, 이는 동일한 주제가 어떤 때는 알려진 누락 지점조차 다 찾지 못하고, 어떤 때는 전부 다시 찾아낼 수 있음을 보여준다.

이 숫자들은 서로 다른 프롬프트와 구현 단계의 반복에서 나온 것이며, 동일 버전 아래의 통제된 A/B가 아니므로, 변동을 드러내는 데에만 사용할 수 있고 안정적인 구간으로 표기할 수는 없다.

변동은 전체 체인에서 온다:

seed가 무엇을 보는가 → 모델이 주제를 어떻게 이해하는가 → 어떤 의미면을 선택하는가 → 각 면이 어떤 쿼리를 생성하는가 → 어떤 후보가 쇼트리스트에 들어가는가 → reranker가 증거 의무를 어떻게 판단하는가

각 계층은 다음 계층의 입력을 바꿀 수 있다. 현장 계획이 복잡할수록 최종 집합의 안정성을 증명하기가 더 어려워진다.

6. 세 번째 계층 시도: 장절 구조를 독립적인 검색면으로 만들기

6.1 의도: 인간의 장절이 하나의 독립 소환 채널이 될 수 있는지 검증

블록 embedding에는 이미 문서 제목과 section_path가 포함되어 있지만, 블록 검색은 여전히 각 block을 독립 객체로 채점한다. 장절 자체는 단독으로 검색하고 확장할 수 있는 객체가 되지 않았다.

이 계층에서 검증하려는 가설은:

현재 스냅샷의 section을 독립 검색 객체로 승격하고, 먼저 topic 또는 facet으로 장을 찾은 뒤 그 하위 트리 block을 펼치면, 블록 수준 벡터 검색이 놓친 의미적 측면을 보완할 수 있을까?

이 시도에는 세 가지 근거가 있다:

- 인간의 장 제목과 경로는 종종 한 묶음의 block이 공유하는 의미를 요약한다;

- 장 검색은 이미 적중한 문서의 get_outline만 보는 것이 아니라 seed 문서에 들어가지 않은 장까지 포괄할 수 있다;

- section이 적중한 뒤에도 section_path와 원본 block_id를 가진 증거로 펼칠 수 있어 출처 추적 요건을 충족한다.

이는 동시에 더 실제적인 문제를 검증한다: LLM 사전 컴파일 비용을 늘리지 않는 전제에서, 작성자가 이미 써 둔 목차 구조를 기성 지식 지도로 먼저 삼을 수 있는가.

6.2 방법: snapshot-bound SectionIndex와 하위 트리 펼치기

✅ 우리는 현재 15편 벤치마크 코퍼스에서 초기 장 인덱스 실험을 했다:

지표 수량 문서 15 block 526 section-tree 노드 328 라우팅 가능 section 286 95% 매핑 기준 충족 여부 예 286개 section의 embedding 입력 18,322 tokens 인덱스 구축 소요 시간 7.9～10.8초

단일 topic 조회에는 query embedding 한 번과 286회의 로컬 코사인 비교만 필요해 구축 비용은 높지 않다. 이 규모는 여전히 방법 검증일 뿐이며, 제품 목표의 1,000편／10만 block은 아니다.

6.3 긍정적 결과: 장 라우팅이 worktree를 보완했다

후보 출처만 관찰하기 위해 facet을 다시 계획하지 않고, 고정 plan의 20개 facet 이름을 그대로 사용해 장을 검색했다:

- 80개의 고유 section을 얻었다;

- 157개의 block을 펼쳤다;

- Automate and scale > Run multiple Claude sessions 아래에 있는 worktree 증거를 찾았다;

- 이 목표는 동시에 세 facet의 장 라우팅에 적중했다.

원래 topic의 block hybrid는 checkpoint 복구는 찾았지만 worktree는 찾지 못했다; 장 라우팅이 worktree를 보완했다. 둘을 합친 뒤 두 개의 회귀 프로브를 찾았고, 마지막 ‘복구 정확성 평가’는 여전히 누락되었다.

이는 장 라우팅이 가치 있는 보완 통로임을 보여 준다.

6.4 부정적 결과: 일반화된 제목과 Appendix는 여전히 사각지대

두 checkpoint 목표는 여전히 실패했다:

- checkpoint resume은 Production reliability and engineering challenges 아래에 있다;

- checkpoint evaluation은 Appendix 아래에 있다.

전자는 ‘checkpoint／resume／복구’라는 어휘 표면이 없고, 후자는 의미 없는 컨테이너일 뿐이다.

인간의 장 구조는 제목이 이미 표현한 의미적 측면을 발견하는 데 도움을 주지만, 제목이 표현하지 않은 내용을 자동으로 발견하지는 못한다.

따라서 장 인덱스는 완전한 지식 지도가 아니다. 라우팅을 도울 수는 있지만, 주제 커버리지를 단독으로 입증할 수는 없다.

6.5 block 검색과의 관계: 대체가 아니라 보완

block 검색과 section 라우팅은 실패하는 방식이 다르다:

- block 검색은 정확한 어휘 표면과 본문 의미를 보존하지만, 구조적으로 의미 있는 짧은 블록을 큰 후보 풀에 묻어버릴 수 있다;

- section 라우팅은 인간의 제목과 계층 의미를 증폭하지만, 하위 트리를 펼칠 때 같은 장 안에서 facet과 가장자리에서만 관련된 block을 끌어온다.

따라서 실험 결과가 지지하는 것은 ‘block 후보와 section 후보의 합집합을 만든 뒤 통일적으로 증거 판단을 수행’하는 것이지, 장 제목으로 본문 검색을 대체하는 것이 아니다. 장 라우팅은 새로운 발견 입구를 제공하고, 최종 증거는 여전히 원본 block으로 돌아간다.

구현과 실험은 고정 스냅샷의 066 슬라이스와 장 라우팅 실험에서 볼 수 있다.

6.6 홀드아웃 주제는 후보가 넓어졌다는 것을 설명할 뿐, 커버리지가 올바르다는 것은 아니다

튜닝에 참여하지 않은 두 홀드아웃 주제에서 장 라우팅은 각각 158개와 172개의 펼친 block을 생성했고, 현재 반환 집합과 비교해 각각 81개와 71개의 ‘신규 후보’가 있었다.

이는 후보 집합이 바뀌었다는 것만을 의미하며, 신규 후보가 모두 올바르다는 것을 의미하지는 않는다. 현재 block 수준의 수동 관련성 전체 집합(qrels)이 없고, 장 라우팅이 수동 facet 커버리지를 높였다는 증거도 없다.

한 번만 실행한(N=1) 결과는 방안 선별에만 쓸 수 있으며, 장기 효과로 쓸 수는 없다.

7. 최신 연구: 왜 이것이 ‘한 번 더 조정’한다고 해결되지 않는가

이 문제가 이 프로젝트에만 존재하는지 판단하기 위해, 우리는 네 가지 직접 관련 연구를 조사했다. 결론은 다음과 같다: 각 국소 지점에서는 누군가 하고 있지만, 우리의 전체 과업을 닫는 데 바로 가져다 쓸 수 있는 연구는 아직 없다.

7.1 CoveR: 커버리지 인식 표현을 개선하지만, 여전히 단일 쿼리 Top-K를 한다

CoveR은 하위 질문 답변 가능성으로 커버리지 인식 듀얼 인코더를 훈련해 벡터 공간이 커버리지 쪽으로 더 치우치게 한다. 이는 관련성 훈련 목표가 커버리지를 보상하지 않는 문제를 해결한다.

하지만 추론 시에는 여전히 query 단일 벡터, 문서 독립 채점의 Top-K다. 반환 집합이 서로 보완적임을 보장하지도, 어떤 주제가 완전히 커버되었음을 증명하지도 못한다.

여기서 nugget은 답변이 커버해야 하는 원자적 정보 포인트를 뜻한다.

7.2 Decompose, Estimate, Select: 집합 커버리지를 명시적으로 수행하지만, 후보 풀과 목표 예산의 제약을 받는다

Decompose, Estimate, Select는 LLM으로 하위 질문을 분해하고, 커버리지 모델로 ‘문서 × 하위 질문’ 커버리지 행렬을 예측한 뒤 최대 마진 커버리지 선택을 한다.

이는 집합 수준 커버리지를 엔지니어링할 수 있음을 증명하지만, 실험은 여전히:

- 고정 BM25 Top-100 후보 풀;

- 고정 k=10 컨텍스트 선택;

- 두 개의 훈련된 커버리지 모델 구성 요소에 의존;

- 후보 풀 내 선택을 최적화하는 것이지, 주제 증거의 무한 발견이 아니다.

논문은 또한 더 높은 검색 커버리지가 자동으로 더 높은 답변 커버리지로 전환되지는 않으며, 생성기가 검색된 증거를 다시 활용하도록 추가로 해야 한다고 보고한다.

이는 중요한 경계를 제시한다:

검색 커버리지 ≠ 메인 Agent가 커버리지를 사용함 ≠ 최종 답변 커버리지

7.3 Q-CARE: 커버리지 평가를 중시하지만, 분해 완전성은 여전히 독립적 보장이 없다

Q-CARE는 쿼리를 하위 쿼리로 나누고, 답변을 원자적 claim으로 나누며, 쿼리 커버리지와 주장 검증 가능성으로 RAG를 평가한다.

이것은 '커버리지'를 평가 가능한 대상으로 만들지만, 하위 질의 자체는 여전히 LLM이 그 자리에서 생성한다. 분해기가 놓친 의미 면은 자동으로 완전성 분모에 들어가지 않는다. 참조 답안이 없다는 것이 분해 가설이 없다는 것을 의미하지는 않는다.

7.4 TREC CAR: 작업이 가장 가깝지만 facet은 흔히 사람이 제공한다

TREC Complex Answer Retrieval은 2017년부터 복잡한 주제의 다중 facet 문단 커버리지를 연구해 왔으며, 작업 형식은 매우 가깝다.

그러나 TREC CAR은 보통 사람이 작성한 outline으로 주제 facet을 제시한다. 그것은 '주어진 facet을 어떻게 평가하고 검색할 것인가'를 해결했지만, 가장 어려운 'facet은 어디서 오는가'는 과제 입력에 남겨 두었다.

7.5 네 편의 논문이 공동으로 말해 주는 것

그것들이 각각 해결하는 것은:

- 커버리지 인지 표현;

- 집합 커버리지 선택;

- 커버리지 평가;

- 복잡한 주제 검색 작업.

그러나 그 무엇도 '완전한 의미 면의 발견, 후보 풀을 넘나드는 리콜, 커버리지 증명, 출처 회귀와 증분 갱신'을 동시에 해결하지는 못했다. 이것이 '국소적 방법은 이미 있으나 합의된 폐루프는 아직 없다'는 증거다.

8. 왜 현장 질의를 계속 쌓아도 수익이 줄어들기 시작하는가

여기까지 우리는 'RAG가 전부 찾을 수 없다'는 결론에 도달한 것이 아니다. 더 정확히 말하면 다음과 같다.

고정된 로컬 지식 베이스, topic-only 입력, 10만 block 목표 규모, 증거가 완전하고 추적 가능해야 한다는 제약 아래에서, 우리는 아직 엔지니어링 검증을 거친 원스톱 현장 검색 방안을 찾지 못했다.

질의를 계속 늘리면 서로 연관된 다섯 가지 문제에 부딪힌다.

8.1 의미 면 자체는 어디서 오는가

모델이 주제를 바탕으로 생성하면 일반적 분류로 치우치기 쉽고, seed 말뭉치만 관찰하면 seed 편향에 빠지며, 장 제목은 또 일부 의미만 표현할 수 있다. 시스템은 주제 이해, 말뭉치 관찰, 증거 의무 분해와 정지 판단을 동시에 완수해야 한다.

8.2 질의 수가 정보 증분보다 빠르게 늘어난다

facet 하나가 여러 조합의 dense 및 keyword 질의를 생성할 수 있다. 후보가 넓어질수록 중복 제거와 근접 중복의 부담이 커진다. 최종적으로 증명해야 하는 것은 '질의를 또 얼마나 보냈는가'가 아니라 '어느 질의가 새로운 증거를 가져왔는가'다.

8.3 질문할 때마다 같은 주제를 다시 이해한다

주제 커버리지는 주제와 지식 베이스 스냅샷에만 의존하므로 이론적으로 재사용 가능하다. 그러나 현장 검색은 seed, 해석, facet, 질의와 감사를 반복 실행한다. 캐시는 계획을 재사용할 수 있지만, 애초에 잘못된 커버리지 지도를 고칠 수는 없다.

8.4 '전부 찾기'에는 자연스러운 정지 조건이 없다

Top-K의 정지 조건은 K개를 반환하는 것이다. 커버리지에는 그런 것이 없다. 시스템은 어떤 증거 의무가 있는지, 어느 것이 이미 충족되었는지, 어느 것이 여전히 결여되었는지를 알아야 멈출 수 있다.

이것이 바로 현장 query fan-out에 빠져 있는 '지도'다.

8.5 커버리지 평가와 답변 생성은 여전히 또 다른 두 계층이다

커버리지 행렬을 구축하더라도 reranker가 정확한지, 메인 Agent가 증거를 사용하는지, 최종 답변이 facet을 커버하는지, 커버리지를 늘리면서 일관성을 희생하지는 않았는지를 판단해야 한다.

모든 책임을 계속 하나의 search_topic에 욱여넣으면 도구가 주제 지도, 검색기, 판정 기준과 답변 계획을 동시에 떠안게 되어 경계를 검증하기가 점점 어려워진다.

9. 원래 설계에서 LLM Wiki의 발동 조건이 이미 성립했다

🤔 현재 프로젝트 판단으로 볼 때, c13-003은 처음에 적어 둔 발동 조건을 이미 충족했다.

- '면状'의 커버리지／페이지를 넘나드는 개념 취합'이라는 명확한 공백이 나타났다;

- 블록 검색, 프롬프트, 질의 확장, facet, 감사와 장 라우팅이 모두 일부분만 해결했다;

- 문제는 단일 도구의 버그가 아니라, 재사용 가능한 주제 증거 지도의 부재다.

따라서 다음 단계는 더 이상 'Wiki를 만들 것인가'를 묻는 것이 아니라, 다음과 같이 묻는 것이다.

어떻게 Wiki를 검색 가능하고, 출처로 회귀 가능하며, 증분 유지보수 가능하고, 삭제 가능하고, 롤백 가능한 지식 계층으로 만들면서 동시에 원본 block 검색을 보존할 것인가?

목표 아키텍처는 RAG를 대체하는 것이 아니다.

┌─────────────────────┐ 사용자 주제 ───────→│ LLM Wiki / 주제 지도 │ │ 개념, 별칭, 커버리지 문제 │ │ 페이지 링크, 증거 의무 │ └──────────┬──────────┘ │ page / section refs ▼ ┌─────────────────────┐ │ 원본 block 증거 계층 │ │ dense + FTS + 스냅샷 │ └─────────────────────┘ ▲ │ 공백 보충 조회와 출처 회귀 │ Agent / coverage tool

Wiki는 '어떤 면을 찾아야 하는지'와 '면들 사이를 어떻게 조직할지'를 담당하고, block은 실제 원문과 인용을 담당하며, 온라인 Agent는 공백 보충 조회, 충돌 처리와 최종 종합을 담당한다.

완전한 연구 아카이브와 대상 설명은 067 연구 스냅샷을 참조하라.

10. 다음 단계: 먼저 LLM Wiki 사전 컴파일을 시도한다

현장 검색이라는 이 노선은 후보 리콜, facet 계획, 증거 판단과 장 라우팅을 각각 자신의 경계까지 밀어붙였다. 다음 단계에서 바꿔야 할 것은 또 하나의 질의 기법이 아니라 지식 조직의 시점이다. 즉 '질의 시점에 주제를 현장에서 이해하기'에서 '입고 시점에 먼저 주제 구조 계층을 컴파일하기'로 전환하는 것이다.

사전 컴파일에는 단 하나의 구현만 있는 것은 아니다.

더 엄격한 지식 그래프는 선택 가능한 경로다. 엔티티, 관계 유형과 제약을 모두 명시적으로 모델링해 구조가 가장 명확하지만, 지속적으로 온톨로지, 엔티티 유형과 관계 규칙을 설계해야 하므로 사람과 도메인 지식에 대한 의존이 비교적 크다. 우리의 목표 사용자는 일반 학습자이고 지식 베이스 내용도 계속 변하므로, 인공 온톨로지 설계를 선행 조건으로 삼는 것은 적합하지 않다.

GraphRAG는 또 다른 것을 증명한다. 엔티티, 관계와 계층 요약을 색인 단계로 앞당기면 실제로 일부 전역적 문제를 처리할 수 있다. 그러나 이 시리즈가 앞서 GraphRAG를 해부한 것에서도 보이듯, 그것은 목표의 사전 인지, 질문 방향의 안정성, 말뭉치가 크고 느슨하다는 등의 전제에 의존하며, 현재 구현은 제품 기반으로서 여전히 관측 가능하고, 구성 가능하며, 재현 가능한 제어 평면이 부족하다.

따라서 우리는 먼저 LLM Wiki를 시도해 볼 준비를 한다. 그것은 완전한 온톨로지를 미리 정의할 것을 요구하지 않고, 주제와 관련된 개념, 별칭, 커버리지 문제, 출처 관계와 페이지를 읽을 수 있고, 검색 가능하며, 출처로 회귀 가능한 증거 지도로 조직하므로, 현재 결여된 능력에 더 가깝다. 더 많은 관계 유형이 아니라 '이 주제를 둘러싸고 어떤 면을 더 찾아야 하는가'인 것이다.

이 시리즈는 앞서 WeKnora의 LLM Wiki 컴파일도 해부한 적이 있다. 그것은 구체적 참고를 제공한다. 개념 추출, 신원 정렬, 원문 chunk 매칭, 페이지 생성, 목차 계획과 링크 주입이며, 축자 원문 소재, 페이지에서 chunk로의 인용과 slug 신원 장부는 특히 참고할 만하다. 그러나 그것의 공개 구현에는 여전히 컴파일 비용, 재컴파일 드리프트, 삭제 잔여, 별칭／페이지 검색과 규모 문제가 있어, 참고 구현으로만 쓸 수 있고 우리 제품 제약을 이미 충족하는 기반으로는 쓸 수 없다.

그래서 다음 단계의 결정은 이것이다. 먼저 LLM Wiki 사전 컴파일 경로를 검증하고, 엄격한 지식 그래프로 곧바로 진입하지 않으며, WeKnora를 정답으로 간주하지도 않는다.

원본 block 검색은 계속 유지한다. Wiki는 주제 근거 면을 발견하고 조직하는 역할을 맡고, block은 실제 원문과 출처 회귀를 제공하는 역할을 맡는다. 먼저 c13-003으로 더 안정적인 주제 커버리지 지도를 형성할 수 있는지 검증한 뒤 held-out 주제로 넘어간다.

전체 연구 아카이브는 067 연구 스냅샷에서 볼 수 있다.

11. 한 페이지 속성

- 핵심 판단: Agentic RAG는 리콜을 확대할 수 있지만, 현존하는 연구와 실천에서는 주제의 "전부 찾기"를 해결하는 합의된 완결 루프를 아직 형성하지 못했다.

- 문제의 성격: c13-003의 난점은 단일 문서 요약이 아니라 현재 지식베이스에서 여러 상호 보완적인 근거 면을 발견하는 것이다.

- 첫 번째 필수 판별 기준(R1): 일곱 개의 교차 문서 핵심 경계를 전부 커버하고, 구체적인 제한 대상이나 리스크를 설명해야 한다.

- Agent의 실패 지점: 15개 문서를 볼 수 있지만, "한 편을 다 읽었다"를 "주제가 커버되었다"로 해석한다.

- 프롬프트 경계: 범용 범위 프롬프트는 검색 범위를 바꾸지 못했고, 강제 종료 이유는 이유와 비용, 프로토콜 오류만 늘렸다.

- 쿼리 확장 경계: 해석 쿼리는 알려진 누락점을 0~1개만 다시 찾아냈고, 명사별 전문 검색은 세 개의 프로브를 모두 다시 찾아냈지만 511/526개의 block을 가져왔다.

- facet 경계: corpus-grounded facet과 감사는 구조를 높였지만, facet 생성에는 여전히 뚜렷한 변동성이 있다.

- 챕터 경계: 챕터 라우팅은 worktree를 보완했으나 범용화된 제목과 Appendix 컨테이너에 가로막혔고, block과 section을 병합한 뒤에도 여전히 "복원 정확성 평가"가 빠져 있다.

- 연구 경계: CoveR, Decompose, Q-CARE, TREC CAR는 각각 국소적인 문제를 해결했을 뿐, 엔드투엔드 주제 근거 발견을 제공하지는 못했다.

- 아키텍처 판단: 블록 검색을 계속 유지하는 동시에, 출처 회귀와 검색, 점진적 유지 관리가 가능한 LLM Wiki 근거 지도를 검증한다.

- WeKnora 결론: 7단계 컴파일, 축자 원문, 인용, slug 원장은 참고할 만하다. 다만 비용, 드리프트, 삭제, 별칭, 규모 문제는 무시할 수 없다.

- 다음 단계: 먼저 LLM Wiki 사전 컴파일 실험에 들어가고, 동시에 원본 block 검색을 유지한다. 먼저 c13-003이 더 안정적인 주제 근거 지도를 형성할 수 있는지 관찰한다.

마지막으로 핵심 판단 한 줄을 남긴다.

우리는 RAG에서 Wiki로 전환하는 것이 아니라, "쿼리로 근거를 찾는 것"에서 "먼저 출처 회귀가 가능한 근거 지도를 유지하고, 다시 쿼리로 그것을 보완하는 것"으로 확장하는 것이다.

페이둥의 인지와 실천

아키텍트

54

글

3.3k

조회

4

팔로워