← 返回
02 独立设计与部署 · 2025
AI 销售知识库与询盘 Agent
给约十人销售团队用的询盘问答系统。核心不是"能答",是"不敢瞎答" —— 硬事实不进向量库。
DifyOneAPIChromaBGE-M3
3
层知识库
~10
人日常使用
人工
确认后发送
交付与结果
面向约 10 人销售团队的知识库与询盘 Agent
- 我的职责
- 独立设计并部署三层知识库与问题分流流程，明确事实查询、语义检索和人工确认的边界。
- 数字的范围
- 约 10 人描述团队使用规模；三层知识库描述架构。人工确认是发送流程要求，不是模型准确率或自动化率。
- 公开材料
- 公开架构、关键取舍与异常处理路径。当前没有公开的量化评测报告，以下流程不作为已通过的测试结果。
遇到异常，怎么处理
下面是系统设计中的处理路径，展示方案的边界与取舍。
- 查询型号、参数或报价
- 进入结构化事实层精确匹配，避免用相似型号的检索片段代替目标事实。
- 没有对应资料
- 提示查不到并转人工确认，不补写没有依据的参数。
- 生成客户回复
- 输出草稿，由销售确认后发送，保留人工决策出口。
要解决什么
销售问参数、问报价、问能不能做,模型答得很流畅。
问题是流畅不等于对。报错一个参数,客户按错的下单;报错一个价,亏的是真金白银。
所以这套系统的设计约束从一开始就不是准确率,是"宁可答不上来,也不能编"。
- 01 结构化事实层 硬事实精确匹配,不进向量检索
- 02 语义检索层 产品说明与场景,向量化进 Chroma
- 03 历史问答层 真实问答沉淀,作为口径参照
- 04 编排 Dify 按问题类型分流到对应层
- 05 出口 AI 只起草,人工确认后才发出
- 3
- 层知识库
- ~10
- 人日常使用
- 人工
- 确认后发送
高亮的一步是整套系统的要害 —— 下面每一区都在讲它为什么这样定。
怎么搭的
每一层都是一次真实的取舍。图里高亮的那层,是整套系统的要害 —— 它错了,别的做得再好也没用。
- 结构化事实层:硬事实精确匹配,不进向量检索
- 语义检索层:产品说明与场景,向量化进 Chroma
- 历史问答层:真实问答沉淀,作为口径参照
- 编排:Dify 按问题类型分流到对应层
- 出口:AI 只起草,人工确认后才发出
为什么这么选
所有资料都进向量库?
硬事实单独一层,不进
向量检索是"找相似",而相似不等于正确。型号 A 和型号 B 的参数表在向量空间里挨得很近 —— 检索得回来,就意味着可能被张冠李戴地答出去。
Agent 直接回客户还是先给人?
只起草
销售看一眼再发,几秒钟的成本;发错一次的成本是客户关系。这个交换不需要犹豫。
模型托管在哪?
私有化部署 Dify + OneAPI
询盘正文里有客户身份和商务信息,不该出公司网络。