当知识可以被”编译” —— LLM Wiki 企业级实践的三道坎
内容提要
本文介绍LLM Wiki在企业合规知识问答中的实践，面临三道坎：并发编译导致38%页面重复，通过串行规划解决；目录摘要有损压缩导致查询遗漏，用BM25全文检索补充，命中率从70%提升至92.7%；人工修正被重编译覆盖，用语义pin保存修正意图。最终强调LLM Wiki适合少而精的知识，非RAG替代品。
延伸解读
并发边界应依据状态依赖划分
文章指出，LLM工作流中的并发边界不应简单按模型调用划分，而应按状态依赖划分。在知识编译中，Plan阶段因依赖前序规划结果而需串行，而Generate等编译环节可保持并发。这种设计在保证一致性的同时，避免了整条流水线性能的牺牲。对于类似场景，识别状态依赖点并据此设计并发策略，是提升系统可靠性和吞吐量的关键。
目录摘要的有损压缩与检索旁路
LLM Wiki的目录摘要本质是有损压缩，容易丢失具体数字、术语等细节，导致查询召回不足。文章通过BM25全文检索作为旁路，与目录选择取并集，将命中率从70%提升至92.7%。这一做法提示，在依赖摘要或索引的系统中，增加基于原文的检索路径可有效弥补信息损失，且并集策略能避免新路径干扰原有正确结果。
人工修正需语义化保存而非文本diff
针对人工修正被重编译覆盖的问题，文章提出用语义pin保存修正意图（claim），而非文本diff。因为LLM重写可能改变措辞和结构，文本patch易失效。通过检查新页面是否满足claim，并在冲突时显式上报，实现了0静默丢失。这启示我们，在AI生成内容的持续维护中，应保存语义层面的修正意图，而非依赖文本位置，以应对生成内容的不稳定性。
LLM Wiki适用场景与RAG的互补
文章强调LLM Wiki并非RAG的替代品，而是适用于“少而精、强一致、值得审核”的知识，如政策、合规文档；RAG则更适合“广而新”的探索性知识。实践采用Wiki-first、RAG fallback的混合模式，兼顾准确性与覆盖范围。企业在选型时，应根据知识性质、更新频率和审核能力来决定架构，而非盲目追求新技术。
Q&A
LLM Wiki 和传统 RAG 在知识处理上有什么本质区别？
传统 RAG 在每次查询时重新检索和组装答案，类似“解释执行”；LLM Wiki 在文档入库时预先编译为结构化 Wiki 页面，查询时直接读取，类似“编译执行”。
LLM Wiki 企业实践中遇到的第一道坎是什么？如何解决？
第一道坎是并发编译导致 38% 的页面语义重复。根因是 Plan 阶段并发时无法看到彼此的规划结果。解决方案是串行化 Plan 阶段，让规划任务顺序读取最新 Wiki Index 并写入占位，而 Generate 阶段保持并发。
为什么 LLM Wiki 查询会找不到答案？如何提升查询命中率？
因为查询依赖目录摘要，而摘要是有损压缩，可能遗漏具体数字、术语等关键信息。解决方案是增加 BM25 全文检索旁路，与目录选页取并集，命中率从 70% 提升至 92.7%。
如何保证人工修正的内容在重编译后不被覆盖？
采用语义 pin 机制，保存专家确认的事实（claim）而非文本 diff。重编译后检查 pin，若新页面满足 claim 则保留，若冲突则进入人工审核，若锚点丢失则标记为 orphan。实验证明 12 个 pin 中 8 个存活、4 个冲突显式上报，静默丢失为 0。
LLM Wiki 适合什么样的知识场景？它和 RAG 是什么关系？
LLM Wiki 适合强权威、强一致、精选且相对稳定的知识，如政策、合规、SOP；RAG 适合宽泛探索、海量高频更新的文档。两者并非替代关系，实践中可采用 Wiki-first、RAG fallback 的混合模式。
在 LLM Wiki 实践中，如何利用 AWS 服务实现并发控制和成本优化？
使用 Amazon S3 条件写（If-Match）实现乐观并发控制，防止旧草稿覆盖新版本；使用 Amazon Bedrock Prompt Caching 缓存稳定目录前缀，降低选页调用成本约 90%，时延从 3.0 秒降至 2.3 秒。
