2. 从编译到检索：一次理念延伸的探索
从编译到检索：一次理念延伸的探索
前面记了 LLM-Wiki 的探索。知识在编译端长出来了，但怎么取用，还是卡着。每次大模型调取知识，仍然从 Raw 里翻全文，Wiki 那边编译好的结构化成果在检索环节等于没派上用场。
这件事让我重新审视了一个更大的问题：编译和检索，到底应该是什么关系。
在 LLM-Wiki 里，我把编译放在了提问之前，让 AI 提前消化知识。但检索端如果还是传统的“临时翻找”，编译的价值就被拦腰截断了。编译的成果应该辐射到检索环节——不是让检索变得更“能找”，而是让检索直接命中已经编译好的知识单元。
这是第二段探索的起点。目标不是给 LLM-Wiki 配一个检索引擎，是让编译的理念穿透到检索层。从向量库到 OpenViking，推了五种方案，最后留下的那个，恰好是整个思考过程的自然收敛。
一、理念的延伸：编译的成果如何进入检索
LLM-Wiki 走的是编译路线——AI 提前消化，产出结构化知识。但到了取用这一步，我一开始还是习惯性地选择上向量库。Wiki 页面切片、生成 Embedding、语义搜索加关键词匹配、调权重排序，结果塞给大模型。这是典型的检索范式，技术栈成熟，方案现成，大部分 RAG 系统都在这么做。
能跑。但问题很快就暴露了：返回一堆碎片，概念间的层次和关联丢了；Token 浪费严重，不管相关内容到底需要多少，一股脑往里塞；权重调来调去永远不稳，换个场景就变。更根本的问题是，把编译好的结构化知识拆碎再拼回去，中间的损耗比省下的 Token 更贵。
向量库这段试探的价值不在于“它没走通”，在于它帮我确认了一件事：编译和检索这两段流程，如果一端做了结构化、另一端又把它打碎，那就两头都没落着好。检索环节需要的不是更強的搜索算法，是承接上游编译成果的能力——直接命中一个已经编译好的知识单元，而不是从碎片里拼出一个答案。
带着这个判断，我转向了 OpenViking。它核心的设计逻辑——L0 摘要、L1 概览、L2 全文，按需逐层加载——恰好与我需要的东西匹配。它管理的不是碎片，是文件；检索命中的不是切片，是一个完整的知识单元。编译产出的概念 Wiki 文件，天然适合作为它的管理对象。
二、架构对接：两种三层结构的映射
LLM-Wiki 有三层：Raw（原料）、Wiki（编译产物）、Schema（规范）。OpenViking 也有三层：L0（核心摘要）、L1（结构化概览）、L2（完整全文）。
两个工具三层结构的映射关系：
- OpenViking L2 对应 LLM-Wiki 的 Raw 和 Wiki 全文——最完整的信息。
- OpenViking L1 对应 LLM-Wiki 的 Wiki 概览——结构化的知识入口。
- OpenViking L0 是 OpenViking 自动生成的浓缩摘要，LLM-Wiki 没有这一层。
这个映射关系揭示的，不只是技术上的兼容性。它揭示的是两个工具的天然分工：LLM-Wiki 负责知识的提炼和生长，离线工作；OpenViking 负责知识的按需加载和检索，在线工作。一个管编译，一个管检索，各司其职，中间用文件系统连接。
关键的问题就变成了：LLM-Wiki 的产出，应该以什么形态进入 OpenViking。
三、五条路径的推演与收敛
围绕这个问题，前后推演了五个方案。它们不只是技术选型，背后是对检索颗粒度、架构耦合度和维护成本的反复权衡。
方案 E：继续用向量库混合检索。 这是基准线。能用，但核心缺陷已经清楚——检索端无法承接编译成果。保留作为参照，但不作为演进方向。
方案 A：概念卡片嵌入原文。 把 LLM-Wiki 生成的概念卡片嵌入原始文档，形成“增强版原文”，存入 OpenViking 作为 L2。需要修改 OpenViking，编写解析插件识别标注并生成混合导航。
评估下来，这个方案的致命伤是 L1 的粒度。L1 必须携带整篇文档的全部概念列表，无论实际查询只涉及其中哪一个。单概念查询仍需加载近两千 Token 的 L1，Token 节省不彻底。此外，概念更新后所有引用它的原文都需重新生成和导入，维护成本偏高。
这个方案的价值在于，它帮我确认了一条设计原则：L1 的粒度必须和知识检索的最小单元对齐。这个原则后来成为评估所有方案的标尺。
方案 C：伴生标注文件。 保持原文不变，通过外挂 YAML 或集中映射表管理概念与原文的关联关系。OpenViking 解析器需要读取伴生文件来生成 L1 和 L0。
这个方案满足了原文零侵入的洁癖，但 Token 消耗与方案 A 处于同一水平，L1 仍是文档级别。伴生文件的生成和同步增加了一套新的维护逻辑，概念更新后所有相关配置文件都需重新处理。
它的价值在于排除了“外挂配置”这条看起来优雅的路。外挂并没有解决成本问题，只是把复杂度从文件内部移到了文件外部。
方案 D：在 OpenViking 内部构建双链知识图谱。 最激进的方向。引入双向链接和图谱索引，让概念文件之间形成可遍历的动态网络，查询时自动发现并预加载关联概念。
这条路的搜索能力确实更强，网状遍历能浮现表面不直接相关的知识。但代价太高。Token 消耗不可控——关联边界模糊，可能越拉越多。系统复杂度跃升——关系引擎、图谱索引、版本同步、关联阈值，每一项都是深坑。更关键的是，把检索引擎和知识图谱深度绑定，意味着未来任何一方的变更都会产生连锁效应，耦合度从松散变为刚性。
它的价值在于帮我划定了一条不能逾越的耦合底线。除非所解决的问题本身就是知识图谱工程，否则不应让检索层背负图谱的复杂度。
方案 B：独立文件。 将 LLM-Wiki 的原文文件和所有概念 Wiki 文件分别作为独立 Markdown 直接存入 OpenViking。不改 OpenViking，完全利用原生能力。一个概念一个文件，原文也是独立文件。
这个方案在讨论初期被我自己否决过，理由现在看来都站不住——文件数量增多、概念关系难维护。重新审视后，文件数量在现代文件系统下根本不是瓶颈；概念关联只需在文件正文内维护轻量链接即可，无需中心化引擎。
最终评估：搜索精准度最高，概念直接成为一级检索单元；Token 消耗最低，单概念查询全程不到一千 Token，比方案 A 节省六成以上；实现成本极低，从 LLM-Wiki 导出文件，按目录存入 OpenViking；维护成本极低，概念更新只覆盖对应文件，无联动成本。
它之所以胜出，不是因为它更精巧，恰恰相反，是因为它最“不精巧”。它没有试图改造工具，没有引入新的中间层，没有提高系统耦合度。它只做了一件事：让编译端的产出，原样成为检索端的单元。
四、路线选择背后的判断逻辑
五条路径推演下来，收敛到一个看起来最不需要技术含量的方案。但复盘整个过程，每一步排除都有它的判断依据：
- 方案 A 排除了文档级 L1 的检索粒度，确认了“检索的最小单元必须等于知识的编译单元”。
- 方案 C 排除了外挂配置的松耦合幻想，确认了“外挂不解决本质问题，只是移动了复杂度”。
- 方案 D 排除了把知识图谱嵌入检索层的架构冲动，确认了“耦合是负债，不是资产”。
方案 B 不是一开始就确定的。它是其他路径被逐条排除后，自然浮现的唯一解。这个推演过程本身，就是一次从“想当然”到“想清楚”的收敛。
从更大的技术路线角度看，这次探索也帮我厘清了编译和检索的关系。过去我默认检索是独立的技术栈——向量库、排序算法、召回策略，都围绕“怎么搜得更准”。这次探索给我的教训是：如果编译端已经做了结构化，检索端的任务就不是“搜得更准”，而是“打得更准”——直接命中那个已经被编译好的知识单元。这两个任务听起来相似，实际需要的架构完全不同。前者需要复杂的搜索策略，后者需要清晰的索引粒度。
写在最后
先是向量库，再是 OpenViking 的五个方案。两轮试探，最后留下来的就六个字：把文件复制过去。
跟 LLM-Wiki 那次一样。那次从三百行 Skill 缩回几十行，状态机、长 Prompt 都试过了，才知道这些方向不适合。这次向量库、解析插件、伴生文件、双链图谱都推演过了，才确认独立文件是最优解。
两次探索的终点都落在一个极简的方案上。这不是巧合，但背后的原因需要参详。