很多团队已经上了向量知识库：上传 PDF，提问，返回几段相似文本。演示好看，一到芯片业务就露出缺口——过期手册被召回、同名参数条件不同、结论找不到页码、两份内部文档互相打架。

芯片知识的难点不是“有没有文字”，而是对象、版本和约束。这正是 [LLM Wiki](/article/llm-wiki) 要编译的东西。

## 向量检索擅长什么

- 快速从大量非结构化文本里找到相关段落
- 给通用问答提供上下文
- 作为编译后知识的检索通道之一

它是工具，不是知识模型。

## 芯片场景里它不够用的原因

1. **版本**：同一料号存在多份手册，召回旧版会直接错
2. **条件**：参数必须带着电压、温度和模式，否则数字无意义
3. **关系**：芯片、封装、外设、API、参考设计是网，不是孤立段落
4. **冲突**：专家经验和官网文档不一致时，检索不会自动升级给人
5. **权限**：客户资料、内部勘误和公开手册不能混在一个索引里

所以 [替代分析](/article/chip-replacement-analysis-workflow)、[AI FAE](/article/ai-fae-first-response) 和 [Coding Agent](/article/mcu-dsp-coding-agent) 都不能只靠“最相似的 5 段”。

## 应该先编译，再检索

LLM Wiki 的顺序是：

1. 接入 PDF、网页、SDK、代码和表格
2. 编译成芯片、参数、引脚、API 等对象
3. 给结论挂上证据和有效期
4. 发现冲突，提交专家审核
5. 再让各场景 Agent 调用

检索发生在对象网络上，而不是发生在碎纸堆上。

## 判断知识库是否合格的四个问题

- 过期型号还会被推荐吗？
- 关键结论能回到手册页码吗？
- 冲突是被隐藏了，还是被标记了？
- [P2P](/article/p2p-agent)、FAE、Coding 是否共用同一底座？

如果四个问题里有两个答不上来，先不要扩大 Agent 数量。先把知识做对，Agent 才 [能完成工作](/article/chip-agent-from-answer-to-completion)。

[了解 LLM Wiki](/products/llm-wiki) · [预约建设企业知识底座](/booking)