> 本文由 苏州市天智教育培训中心 技术团队整理，基于真实生产故障复盘，面向一线运维与开发同学，可直接用于排障参考。
一、问题现象
知识库文章从几千涨到几十万后，检索从 80ms 涨到 900ms，而且"该找到的找不到"。扩容实例也没用——问题在索引与数据治理，不在算力。
二、排查思路速览
先按下面的路径走，每一步都有明确的判断分支，避免"上来就重启"这种无效操作。
三、先看清链路：AI Agent 的典型架构
动手之前先明确"请求经过了哪些环节"，把问题定位到具体一层，排查效率会成倍提升。
四、根因分析
结合现场日志、监控与配置，逐条核对，绝大多数情况都能收敛到下面这几类原因：
- 没建向量索引（或索引类型选错），数据一多就退化成全量暴力比对
- 换了 Embedding 模型但没重建向量库，新旧向量不在同一空间
- 知识库里大量重复/过期片段，挤占了 TopK 名额
- 分块过大，单条向量语义混杂，相似度区分度下降
- 并发检索没有缓存与限流，热点查询把库压满
五、处置过程
处置原则：先止血、再根治。先让业务恢复，再回头解决根因，不要在故障中做长期改造。
- 先确认是否走了索引——这决定性能问题的方向
- 换 Embedding 模型等于换坐标系，必须整库重建
- 入库前做去重与有效期管理，脏数据比索引更伤召回
- TopK 之后一定要加 Rerank，别让向量相似度独自决定结果
六、关键命令与配置
下面这些命令/配置可以直接在生产上核对（执行前请确认环境与权限）：
# 1) 建索引（以 Milvus 为例，HNSW 更稳，IVF 更省内存）
index_params = {"index_type": "HNSW", "metric_type": "COSINE",
"params": {"M": 16, "efConstruction": 200}}
client.create_index("kb_chunks", index_params)
# 2) 检索侧调参：ef 越大越准越慢，按 SLA 找平衡
res = client.search("kb_chunks", [vec], "embedding",
param={"metric_type": "COSINE", "params": {"ef": 64}}, limit=20)
# 3) 入库去重（按内容哈希），避免重复片段挤占 TopK
h = hashlib.sha256(chunk.text.encode()).hexdigest()
if not store.exists(h):
store.insert(h, chunk, client.embed(chunk.text))七、复盘
故障恢复后必须做复盘，重点不是"谁的责任"，而是"哪个机制缺位"：
- 根因是向量库集合建好后从未建索引，一直在暴力检索
- 复盘发现没有"检索耗时"与"召回率"的日常指标
- 重复片段占了三成，是历次导入没有做幂等导致的
八、预防建议
- 把检索耗时 P95 与召回率纳入监控
- 入库流程加"按内容哈希去重"与"有效期字段"
- 换模型必须走"重建 + 评估集回归"流程
- 定期抽样人工校验 TopK 质量
九、写在最后
上面这套排查方法，是 AI Agent 在生产环境中最常见的一类问题，也是AI Agent方向岗位面试里经常被追问的场景题。很多人搜「苏州aiagent培训」或者关心「AI Agent 培训」，真正想确认的其实是：课程讲不讲真实的线上故障。我们在AI Agent 开发工程师课程里，会把这类故障做成实战演练——从监控曲线、日志、命令输出一路推到根因，再动手恢复，而不是背命令。苏州校区面授 + 线上同步，主打苏州aiagent培训方向的实战教学，就业推荐覆盖江浙沪。如果你正在做AI Agent方向、或者想转行进入AI Agent领域，可以了解一下我们的课程（苏州aiagent培训、AI Agent 培训、智能体开发培训），也可以直接联系我们做一次免费的职业与技术评估。