很多团队已经上了向量知识库：上传 PDF，提问，返回几段相似文本。演示好看，一到芯片业务就露出缺口——过期手册被召回、同名参数条件不同、结论找不到页码、两份内部文档互相打架。
芯片知识的难点不是“有没有文字”，而是对象、版本和约束。这正是 LLM Wiki 要编译的东西。
向量检索擅长什么
- 快速从大量非结构化文本里找到相关段落
- 给通用问答提供上下文
- 作为编译后知识的检索通道之一
它是工具，不是知识模型。
芯片场景里它不够用的原因
- 版本：同一料号存在多份手册，召回旧版会直接错
- 条件：参数必须带着电压、温度和模式，否则数字无意义
- 关系：芯片、封装、外设、API、参考设计是网，不是孤立段落
- 冲突：专家经验和官网文档不一致时，检索不会自动升级给人
- 权限：客户资料、内部勘误和公开手册不能混在一个索引里
所以 替代分析、AI FAE 和 Coding Agent 都不能只靠“最相似的 5 段”。
应该先编译，再检索
LLM Wiki 的顺序是：
- 接入 PDF、网页、SDK、代码和表格
- 编译成芯片、参数、引脚、API 等对象
- 给结论挂上证据和有效期
- 发现冲突，提交专家审核
- 再让各场景 Agent 调用
检索发生在对象网络上，而不是发生在碎纸堆上。
判断知识库是否合格的四个问题
- 过期型号还会被推荐吗？
- 关键结论能回到手册页码吗？
- 冲突是被隐藏了，还是被标记了？
- P2P、FAE、Coding 是否共用同一底座？
如果四个问题里有两个答不上来，先不要扩大 Agent 数量。先把知识做对，Agent 才 能完成工作。