跳到主内容
← 返回

02 独立设计与部署 · 2025

给约十人销售团队用的询盘问答系统。核心不是"能答",是"不敢瞎答" —— 硬事实不进向量库。

DifyOneAPIChromaBGE-M3
3
层知识库
~10
人日常使用
100%
回复经人工确认

Problem

要解决什么

销售问参数、问报价、问能不能做,模型答得很流畅。

问题是流畅不等于对。报错一个参数,客户按错的下单;报错一个价,亏的是真金白银。

所以这套系统的设计约束从一开始就不是准确率,是"宁可答不上来,也不能编"。

Architecture

怎么搭的

流程图按站点样式重画,不是 PDF 截图

  1. 1

    结构化事实层

    型号、参数、认证等硬事实,精确匹配,不进向量检索

  2. 2

    语义检索层

    产品说明与应用场景,BGE-M3 向量化后进 Chroma

  3. 3

    历史问答层

    过往真实问答沉淀,作为口径与语气的参照

  4. 4

    编排

    Dify 工作流按问题类型分流到对应层

  5. 5

    出口

    AI 只起草,人工确认后才发给客户

Tradeoffs

为什么这么选

所有资料都进向量库?

硬事实单独一层,不进

向量检索是"找相似",而相似不等于正确。型号 A 和型号 B 的参数表在向量空间里挨得很近 —— 检索得回来,就意味着可能被张冠李戴地答出去。

Agent 直接回客户还是先给人?

只起草

销售看一眼再发,几秒钟的成本;发错一次的成本是客户关系。这个交换不需要犹豫。

模型托管在哪?

私有化部署 Dify + OneAPI

询盘正文里有客户身份和商务信息,不该出公司网络。