你的企业知识库不是"搜不到"，而是"看不见森林"——一篇论文把整个 RAG 从「检索」改成「导航」
- 关联论文：2604.14572
做企业 RAG 的工程师都有一个痛点：用户问了一个稍微复杂点的问题，AI 翻来覆去找不到正确答案。
明明相关文档就在库里，明明向量检索已经跑了 top-k——可答案就是不对。你去翻 trace，会发现关键证据根本没进检索窗口，AI 只看到"几片树叶"，看不到"整片森林长什么样"。
传统 RAG 把大模型当成"检索结果的被动消费者"——它只看到 top-k 个段落，看不到"还有几条没看"、"这条分支是否值得继续"。这就是企业 RAG 用了几代人都没解决的根本问题。
最近 arXiv 上的 2604.14572（GitHub 仓库 https://github.com/dukesun99/Corpus2Skill），给出了一个反直觉的解法：别让 AI 检索，让它"导航"。
具体做法：把企业语料离线编译成文件系统形式的"Skill 森林"（SKILL.md / INDEX.md 分层目录），运行时用 LLM 的渐进披露（progressive disclosure）机制，像读一本书一样从鸟瞰层钻到细节层。
结果是：在工业客服基准 WixQA（6,221 篇文档）上，答案质量与文档引用 grounding 两条指标同时超越全部 5 个 baseline（BM25 / Dense / Hybrid / RAPTOR / Agentic RAG）。
一句话总结：这篇论文做对了什么
它把 RAG 从"黑盒检索函数 f(query, D)"换成了"可被 Agent 主动遍历的有结构目录"。具体三件事：
- 离线编译（Compile）：用 LLM 对每篇文档做摘要，自底向上聚类，建一棵树——根节点是主题分区，叶子节点是文档卡片；每个 skill 目录里都是 SKILL.md（这个分区讲什么）+ INDEX.md（包含哪些文档的一句话简介）。
- 运行时导航（Serve）：Agent 只预加载 200 token 的"全局 skill 描述 + 实体索引"，从根节点往下钻，看到不相关分支就回溯、跨分支合并证据；不需要向量数据库，不需要专用检索 API，纯靠文件系统 + 标准 shell 工具就能跑。
- 显式刻画失败模式：论文明确告诉你，navigation 不是 RAG 银弹——在 HAGRID / TatQA / CUAD 等"开放域事实池"或"同质表格型语料"上，flat retrieval 反而更好。这不是缺陷，是设计准则。
为什么"导航"比"检索"更适合企业
论文给这件事取了一个名字：corpus navigability（语料可导航性）。
传统 RAG 的失败模式有三种：
- 多跳查询容易失手：第一条检索没命中关键证据，AI 没意识到"森林里还有别的路"，直接放弃；
- Agentic RAG 多跳盲打：agent 能多发几次 query，但每条 query 仍是基于相似度的"盲打"——它不知道语料里到底有什么；
- 层次化方法（RAPTOR / GraphRAG / BookRAG）：建树或图但 query 时仍走 embedding，模型看不到树的结构本身。
Corpus2Skill 真正的贡献，是把"层次"从索引结构升级为 Agent 直接浏览对象——AI 不再做黑盒检索，而是像一个图书管理员一样在目录树里跳进跳出。
这套设计有几个工程优势：
- 渐进披露解耦成本：skill 全局描述 ≈ 200 token 预加载，每条 INDEX.md < 2KB，10 万级语料只多 1 层——目录再大也不会撑爆 context window；
- 部署零门槛：完全用文件系统 + shell 工具 + Skills API，不依赖向量库、不需要专门检索服务；
- 跨分支导航：实体索引 + Related skills 让 Agent 命中具名实体时不必从根搜索，直接横向跳跃——长尾查询体验远超传统 RAG。
这套方法怎么 work
论文给出的离线编译流程伪代码：
def compile(D, p=10, K=10, tau=margin):
# 1. 文档表征
for d in D:
card[d] = LLM.summarize(d) # title + 一句话 + 关键短语
emb[d] = embed(card[d] + d[:chunk])
# 2. 自底向上聚类建树
level = [emb[d] for d in D]
while len(clusters) >= K:
groups = kmeans(level, n=ceil(len(level)/p))
for g in groups:
summary[g] = LLM.summarize(members_of(g))
# verify-and-repartition：合并混淆簇、拆分混合簇
flags = LLM.verify(sibling_summaries)
groups = repartition(groups, flags)
level = [embed(summary[g]) for g in groups]
# 3. 跨分支导航（写入 ## Related skills 块）
entities[g] = LLM.tag(summary[g])
related[g] = jaccard(entities)
# 4. 文件化
for root in top_K:
write_SKILL_md(root, summary[root], related[root])
for child in root.children:
write_INDEX_md(child, rows=[card[d] for d in child.docs])
两个值得记的关键技巧：
- 跨引用而非复制：每篇文档只有一个 home cluster，但若 top-1 与 top-2 余弦相似度差距小于 τ，会被交叉列出到 runner-up 的 INDEX.md——避免硬聚类在边界文档上"劈错"；
- verify-and-repartition：兄弟簇汇总一起交给 LLM 看，标记"confusable"（覆盖同一主题）和"mixed"（单一簇跨多主题），flagged 的就重分并重新摘要。这步直接借自 RAPTOR，但落到了文件系统而不是扁平向量库。
复杂度：深度 L = ⌈log_p N⌉，单次导航只需浏览 O(p · log_p N) 条摘要，不是 O(N)。论文报告在 WixQA 上 p=10, L=3，每查约 30 条摘要，可线性扩到 10 万级语料。
实测数据与失败边界
论文给出核心结论（在抽象与引言明确表述）：
- 质量与 grounding 同时提升：答案质量与 grounding（是否引用到正确文档）两条指标上都优于全部 5 个 baseline；
- 代价为中等：调用成本高于单次 dense retrieval（因为多了多轮浏览 + LLM 调用），但仍在企业可接受区间；
- 泛化实验（10 个 RAGBench 子集）：大多数子集上赢过 flat retrieval，但 HAGRID / TatQA / CUAD 三个子集 flat retrieval 反而更好——论文明确指出"navigation 适合单域、可恢复出主题层级的语料"，在开放域事实池或同质表格型语料上，顶层聚类直接失效，回到 flat retrieval 更划算。
几个常被忽略的工程坑
论文自陈了几个关键边界，落地时一定要警惕：
- 编译是一次性成本高峰：10 万级语料单次编译可能吃掉 150-500 万 token；建议先用 1% 语料做成本预估，对静态语料做增量编译（新增文档只编译受影响的分支）；
- Skills API 并发限制是真实瓶颈：原文提到 Skills API 有约束但未给具体数值；多 Agent 实例同时访问会限制吞吐量，必要时考虑自托管一套文件系统 progressive disclosure；
- τ 阈值与 p/K 参数是半经验性的：从 τ=0.05 开始网格搜索 5-10 个候选值，用有标注的 query set 做评估；p/K 直接用论文默认 (p=10, K=10) 起步；
- 跨分支合并不等于无幻觉：LLM 在合并来自不同 cluster 的证据时可能产生幻觉，建议强制每个答案 claim 附带
source: doc_id并做引用完整性检查； - 语料更新需要整树重建：对小于 X% 的增量变化设计局部更新策略，避免全量重建；
- WixQA 客服场景到异构语料的 gap：迁移到更异构的语料（如混排 PDF 合规文档）时，compile 阶段文档表征质量会下降——上线前在自己语料上做"聚类质量审计"。
谁该读这篇
- 企业知识库 / 客服 Copilot 架构师：要决定继续走 dense retrieval 还是上层次化导航——这是当下最直接的对照实验；
- RAG 平台工程师：想找一种不依赖向量库的兜底/混合方案——本文给出极轻的备选；
- Agent 框架设计者：评估把 progressive disclosure 与 skill 文件系统纳入自己 agent runtime 的收益；
- 学术读者：研究层次化 RAG、Agentic RAG、Skill 形式化方向——把本文作为"informational skill"的起点案例；
- 不那么适合：还在用"先把所有文档灌进向量库再 top-k"的早期 PoC 阶段读者，先把基础 RAG 跑稳再考虑范式切换。
一句话总结
企业 RAG 卡了三年的根因，是 AI 看不到"森林"。这篇论文把语料离线编译成文件系统的 Skill 森林，让 Agent 用渐进披露机制主动浏览而非盲目检索——在工业基准 WixQA 上同时拉满答案质量与引用 grounding。它在做的是：把企业 RAG 从"模型背着语料蒙眼找"换成"模型翻开目录边走边找"。
如果你的企业知识库还在为多跳查询与长尾问题头疼——这是 2026 年最值得抄的一套工程范式。
三个标题变体
- 你的企业知识库不是"搜不到"，而是"看不见森林"——一篇论文把整个 RAG 从「检索」改成「导航」
- 别再 top-k 了！让 AI 像图书管理员一样翻目录，企业 RAG 终于做出工业级 ground
- 同一个企业知识库，从"检索"换成"导航"后，答案质量与文档引用同时拉到工业 SOTA
小红书风格卡片文案（可直接发布）
🤖 企业 RAG 卡了三年的根因找到了 ✨
不是搜不到，是看不见森林 🌲
过去 AI 在企业知识库里只能干一件事：top-k 检索 它只能看到几片树叶，看不到森林长什么样 所以多跳查询总是失手、长尾问题总是答错 😭
最近 arXiv 2604.14572（GitHub 开源）给了一个反直觉解法：
🔥 别让 AI 检索，让它"导航"
具体怎么做？ 1️⃣ 离线编译：把语料蒸馏成 SKILL.md / INDEX.md 分层目录（用 LLM 摘要 + 自底向上聚类 + 兄弟簇校验） 2️⃣ 运行时导航：Agent 只预加载 200 token 全局 skill 描述，从根往下钻，看到不相关就回溯、跨分支合并证据 3️⃣ 不依赖向量库：纯文件系统 + 标准 shell 工具 + Skills API ✨
核心数字（工业客服基准 WixQA，6,221 篇文档）📊： - 答案质量与引用 grounding 两条指标同时超越全部 5 个 baseline（BM25 / Dense / Hybrid / RAPTOR / Agentic RAG） - 单次查询只浏览约 30 条摘要，不是 O(N) 全扫 - 完美扩到 10 万级语料（只多 1 层目录深度）
三个工程亮点 🔑： - 渐进披露解耦成本：skill 描述 ≈ 200 token、INDEX.md < 2KB，目录再大不撑爆 context - 跨分支导航：实体索引 + Related skills，长尾查询体验远超传统 RAG - 部署零门槛：不需要向量数据库，不需要专用检索 API ✨
⚠️ 失败边界（论文自陈）： - HAGRID / TatQA / CUAD 等开放域事实池，flat retrieval 反而更好 - 只适合单域、可恢复出主题层级的语料 - 编译是一次性成本高峰（10 万级语料可能 150-500 万 token）
📎 论文 ID：2604.14572 🔗 GitHub：https://github.com/dukesun99/Corpus2Skill 💬 评论区聊聊：你们团队的知识库还在用向量检索吗？敢不敢试试"目录导航"？