Corpus2Skill 深度解读：不要检索，去导航！

> **一句话总结**：Wix团队把企业知识库变成了一棵「技能树」，让大模型像人一样「浏览文件夹」找答案，而不是像搜索引擎一样「关键词匹配」抓片段。结果？不需要向量数据库，不需要嵌入检索，纯靠LLM的推理能力导航，效果还更好。 --- ## 一、先从一个具体场景理解问题 想象你是一个客服，用户问你：「我怎么把Wix上的个体工商户账户改成LLC公司账户？」 这个问题涉及三个领域：账户类型、支付配置、法律实体管理。传统RAG怎么做？它把你的问题变成一个向量，去数据库里找「最相似」的文档片段，返回前K个。问题是——这些片段可能都包含「sole proprietorship」「LLC」这些关键词，但**真正关键的那条信息**（"账户类型不能直接修改，必须联系客服"）可能因为表面词汇不匹配，根本没出现在返回结果里。 更糟的是，LLM拿到这些碎片后，**完全不知道知识库的整体结构**。它不知道还有哪些主题没搜到，不能决定「这个方向没结果，换个方向试试」，更不能把不同部门的文档拼成完整答案。 这就是论文说的「只见树木不见森林」——RAG让LLM成了搜索结果的被动消费者，而不是主动探索者。 --- ## 二、Corpus2Skill的本质：把「搜索」变成「浏览」 论文的核心洞察非常朴素：**与其让LLM搜索知识库，不如让它浏览知识库**。 具体怎么做？分两步： ### 编译阶段（离线，一次完成） 1. **嵌入+聚类**：把所有文档向量化，用层次聚类构建一棵主题树 2. **LLM总结**：在每个层级，让LLM写总结——顶层是技能目录（SKILL.md），中层是子主题索引（INDEX.md），底层是具体文档 3. **物化为文件**：最终产物不是数据库索引，而是**一堆可读的Markdown文件**，像文件夹一样组织 ### 服务阶段（在线，每次查询） LLM Agent拿到用户问题后： 1. **先看鸟瞰图**——所有顶级技能的名称和简介（约200个token）预加载到上下文 2. **选择技能**——读对应的SKILL.md，了解子主题结构 3. **深入探索**——读INDEX.md，看具体文档列表 4. **按需获取**——用get_document工具读取完整文档内容 5. **回溯或交叉**——如果发现这条路不对，可以换分支；如果需要综合多个主题的信息，可以跨分支收集 整个过程就像你在公司Wiki上找资料：**先看目录，再点进相关页面，发现不对就返回，最终锁定目标**。 --- ## 三、关键设计：渐进式披露（Progressive Disclosure） 这是整个系统最聪明的地方。 如果预加载所有导航文件，上下文会被成千上万的摘要淹没；如果什么都不预加载，LLM又成了瞎子。渐进式披露取了中间值：**只给LLM看目录**（技能名称+一句话描述），让它做第一级选择。等它决定深入某个分支后，再动态加载该分支的详细内容。 这带来了两个关键收益： - **Token效率**：LLM只在必要时才读取长文档，避免垃圾信息淹没上下文 - **可解释性**：每一步决策都基于明确的摘要，LLM的导航路径是透明的、可审计的 --- ## 四、实验结果：为什么这个方法有效？ 在WixQA基准上（200个真实企业客服查询），Corpus2Skill击败了： - 密集检索（Dense Retrieval） - RAPTOR（层次化RAG） - 多轮Agentic RAG **为什么它能赢？** 传统RAG的检索是「一锤子买卖」——查询→向量匹配→返回Top-K。如果第一次检索漏掉了关键文档，LLM永远看不到。而Corpus2Skill的导航是「迭代探索」——LLM可以**发现当前分支不对，主动回溯换方向**；也可以**看到多个相关主题，主动跨分支合成答案**。 论文展示了两个典型轨迹： **直接导航**（4步）：查询→选技能→选子组→读文档→答案 **交叉导航**（7步）：查询→选技能→探索子组A→发现不够→切换到子组B→综合两处分信息→答案 这种「试错+综合」的能力，是传统RAG的黑盒检索无法提供的。 --- ## 五、诚实地看看局限（这才是关键） 论文花了整整一节分析失败案例，这种诚实本身就很科学。 **200个查询中，62个（31%）失败**，主要三类原因： 1. **导航失误（38次，61%失败）**：LLM在顶层技能选择时走错了路。比如「CMS集合排序」的问题被导航到了「网站编辑」技能，而非「CMS」技能。这说明**顶层分类的粒度**是瓶颈——主题太粗，相似技能之间的边界模糊。 2. **过度检索（19次，31%失败）**：LLM找到了正确主题，但顺带抓了一大堆相邻无关文档，稀释了上下文质量。这说明**叶子节点的分组精度**还有提升空间。 3. **合成错误（3次，5%失败）**：LLM把条件性指令误读为通用规则，或者过度泛化。这是LLM本身的推理问题，不是架构问题。 作者还做了消融实验：把顶层聚类从15个压缩到3个（紧凑模式），导航失误减少了——因为更少的选项意味着更低的决策复杂度。这提示了一个有趣的权衡：**树越扁平，导航越容易，但每个节点的摘要越长；树越深，摘要越短，但决策步骤越多**。 --- ## 六、费曼式追问：这真的是「不要检索」吗？ 论文的口号是"Don't Retrieve, Navigate"，但让我们别被口号骗了。 仔细看看编译阶段——**文档嵌入和聚类本质上就是检索的预处理**。Corpus2Skill只是把「检索」从在线查询时移到了离线编译时。好处是运行时不需要向量数据库，坏处是**知识库更新后必须重新编译整个技能树**。 所以更准确的说法是："把检索成本从查询时转移到编译时，用LLM的推理能力替代向量相似度匹配来做最终文档选择"。 这不是否定检索，而是**重新分配计算资源的时空分布**。 --- ## 七、落地启示：谁适合用这个？ **适合的场景**： - 企业知识库相对稳定（不需要实时更新） - 查询复杂，需要跨主题综合（不是简单的事实查找） - 已有Anthropic Skills API或类似基础设施 **不适合的场景**： - 需要毫秒级响应的实时系统（LLM导航需要多轮API调用） - 知识库频繁变动（每次更新都要重编译） - 简单查找类查询（传统RAG的向量检索更快更便宜） --- ## 八、结语 Corpus2Skill最有价值的贡献不是某个具体技术，而是**一个设计范式的转变**：从「让LLM消费搜索结果」到「让LLM主动探索知识结构」。 它提醒我们：RAG的问题可能不在于检索算法不够准，而在于**整个交互模式错了**——LLM不是搜索引擎的用户，它应该是一个能在知识森林里自己找路的探险家。 但别忘了论文里那31%的失败率。导航树的质量、顶层分类的精度、LLM的决策稳定性，都是实打实的工程挑战。口号很性感，落地很骨感。 > **"先编译，后导航"**——未来的知识库系统，也许不再是「数据库+检索器」，而是「预编译的可导航结构+推理Agent」。 --- 📄 论文：arXiv:2604.14572 🏢 作者：Yiqun Sun, Pengfei Wei, Lawrence B. Hsieh (Wix) 🔗 代码：https://github.com/dukesun99/Corpus2Skill #论文解读 #RAG #LLM #知识库 #Corpus2Skill #Wix