背景
为一家中型服务公司做的原型，目的是评估「自建还是采购」。预算只有一个迭代周期。拿不到生产环境，语料是他们脱敏导出的一份副本。
问题
新员工在群里反复问同样的制度问题。手册是 200 页 PDF，没人会去搜索。他们之前试过直接把整份文档粘进通用聊天机器人，结果模型开始自信地编造根本不存在的制度。
实现与取舍
- 按标题层级切块，而不是按固定 token 长度切。手册本来就是按制度分节写的，顺着这个结构切，每块语义完整；固定长度切法会把同一条制度拆到三个块里，抽查时效果明显更差。
- 用带向量扩展的 SQLite 存索引，没有额外上向量数据库。900 个分块的总索引只有几 MB，为一个客户端专门维护向量数据库纯属运维负担。
- 强制模型要么返回引用出处，要么返回「手册中没有这一条」。用户能核实的拒答，比无法核实的自信猜测有价值得多。
- 用真实客服工单写了 20 条评测集，每次改动都跑一遍。没有这个评测集，每一次调 prompt 都感觉像是在改进，其实根本分辨不出来。
结果
内部评测集上，给出正确答案且引用出处准确的比例，从「整份 PDF 直接粘」基线的 61% 提升到 89%。超范围问题的正确拒答率 25 题里对了 24 题。交付物是一个可运行的原型，外加一份「要上生产还缺什么」的说明。
为什么标注为「自建项目」
这是在脱敏样例语料上做的原型，没有签合同，所以不把它包装成客户案例。放在这里是因为它能说明我解决什么样的问题，以及我怎么衡量问题是否真的被解决了。
上生产还缺什么
原型里刻意跳过了三件在生产环境会要命的事，交接时我明确写了：文档级权限控制（手册里有仅管理者可见的章节）、源文档变更后的重建索引触发、以及单次对话的成本监控。这三件都不难，但都是范围之外的工作。