上篇写了为什么我的本地知识库一直\”搜不准\”本地知识库总“搜不准”？不是模型不行，是Embedding底层逻辑没吃透，写完发现很多人遇到类似问题，好多朋友追问结果。
这篇是续篇——把我实际做的改造过程写出来，包括踩的坑、改的代码、优化的思路，以及最终的数据对比。文章末尾附知识库代码。
背景：这是一个用于AI方案工作坊多智能体协同的本地知识库，存储公司介绍、产品文档、典型案例、合同模板等74份文档，通过RAG方式为5个AI Agent提供上下文支撑。
一、动手前先想清楚：改什么，不改什么？
上篇诊断出三个硬伤，但我没有一股脑全改。在工程实践里，方向对了不等于路径对。资源有限的情况下，先改性价比最高的。
我拉了一张优先级矩阵：
| 优化项 | 预期收益 | 改造难度 | 优先级 |
| 知识分切逻辑（chunk策略） | ⭐⭐⭐⭐ | 中 | P0 先行 |
| 前端配置与查询页面 | ⭐⭐⭐ | 中 | P0 先行 |
| 文档大幅扩容（7类→12类） | ⭐⭐⭐⭐ | 低 | P0 先行 |
| 关键词加权检索 | ⭐⭐⭐ | 低 | P1 本次 |
| 向量模型升级（512→1024维） | ⭐⭐⭐⭐⭐ | 高（显存/内存） | P2 后续 |
| 混合搜索（BM25+向量） | ⭐⭐⭐⭐⭐ | 高（引入ES） | P2 后续 |
结论：这次优化聚焦三件事——切块策略精细化、关键词加权、前端可视化管理。
向量模型升级和混合搜索这两个大头，等服务器资源到位再说。
二、第一道坎：Base64数据污染了整个索引
改造的第一步是扩充知识库内容。
知识库从最初的47个文档、7个分类，要扩展到覆盖产品文档、项目经验教训等12个分类。新增的核心文档包括：
- • HolliMOM制造运营管理系统白皮书（V5.0）
- • HolliEAM设备资产管理系统使用手册
- • Hol
