说明 Flowise 适合做编排引擎,但缺知识库/运营后台,不适合作为鲜境首期唯一底座。 Co-authored-by: haijd <haijd@163.com>
221 lines
13 KiB
Markdown
221 lines
13 KiB
Markdown
# 鲜境物联 · AI 智能客服|技术路线建议书
|
||
|
||
> 依据材料:框架合作建议书、AI 客服建议书与报价、验收标准(附件三)、委托开发合同、开发计划与进度表(附件二)。
|
||
> 结论先看:**推荐「开源自托管二开 + 核心业务定制」;不推荐纯自研,不推荐纯公有云 SaaS。二开底座首选 Dify。**
|
||
|
||
---
|
||
|
||
## 1. 项目边界(合同已锁死的硬约束)
|
||
|
||
| 维度 | 合同 / 计划约定 | 对技术选型的含义 |
|
||
|------|------------------|-------------------|
|
||
| 周期 | **7 周**(约 2 个月),自首付款 + 必要资料齐备起算 | 必须复用成熟对话/RAG 底座,禁止从零造轮子 |
|
||
| 费用 | 一次性实施 **¥50,000**;年度订阅 **¥30,000/年** | 人力预算紧,二开性价比远高于纯自研 |
|
||
| 场景一 | 选 **一个高频渠道** 做 24h 智能咨询(意图→追问→方案→人工接管) | 首期渠道做深一个,勿同时铺网站+FB+邮件 |
|
||
| 场景二 | 录音/对话 → 语义识别 → 知识库 → 自动生成方案 | 可与场景一共用同一知识库与方案引擎 |
|
||
| IP | 定制功能 + 知识库归甲方;乙方保留通用框架复用权;开源须清单披露 | **自托管开源二开完全合规**,且利于乙方后续复用 |
|
||
| 数据 | 建议书明确:数据自主可控、避开对第三方平台(如阿里)依赖 | 排除强绑定公有云客服 SaaS 作为主路径 |
|
||
| 验收 | 功能闭环 + AI Eval(意图≥85%、方案≥80%、完成≥70%、幻觉≤5%、泄露 0%) | 必须单独做评测与人工接管,不能只做「能聊天」 |
|
||
|
||
进度锚点(附件二):
|
||
|
||
| 阶段 | 周次 | 必须产出 |
|
||
|------|------|----------|
|
||
| P1 需求诊断 | W1 | 需求清单、资料清单、方案判定逻辑初稿 |
|
||
| P2 概念验证 | W2 | 可运行 Concept Demo |
|
||
| P3 真实验验 | W3 | 真实场景验证报告 |
|
||
| P4 MVP | W4–W6 | 可上线 MVP(含约定渠道对接) |
|
||
| P5 试运行 | W7+ | 效果看板、首轮优化 |
|
||
|
||
在 **5 万 / 7 周** 约束下,任何「自研完整客服中台」都会在 W2–W3 断档。
|
||
|
||
---
|
||
|
||
## 2. 三条路线怎么选
|
||
|
||
### 2.1 纯自研(LangChain/自写服务 + 自研后台)
|
||
|
||
| 优点 | 风险 |
|
||
|------|------|
|
||
| 完全可控、后续扩展空间大 | 知识库后台、对话编排、评测、权限、多轮状态机都要自写 |
|
||
| 契合乙方「保留通用框架」长期意图 | 7 周内难同时达到验收阈值;5 万预算撑不起完整团队 |
|
||
|
||
**结论:不作为首期主路径。** 可作为二期沉淀「方案判定引擎 / Eval」时逐步抽离自研模块。
|
||
|
||
### 2.2 纯 SaaS(扣子 Coze、阿里云智能客服、腾讯企点等)
|
||
|
||
| 优点 | 风险 |
|
||
|------|------|
|
||
| 上线快、少运维 | 与「数据自主可控、避开第三方平台依赖」直接冲突 |
|
||
| | 知识库/对话数据常落在厂商侧;出海/模型切换受限 |
|
||
| | 合同要求开源清单与定制归属,SaaS 难谈清底层复用 |
|
||
|
||
**结论:不推荐作主交付。** Demo 可用公有能力试效果,生产必须迁出自托管。
|
||
|
||
### 2.3 开源自托管二开 + 业务定制(推荐)
|
||
|
||
| 优点 | 风险 |
|
||
|------|------|
|
||
| W2 即可出 Concept Demo | 底座升级需跟社区版本 |
|
||
| 知识库/对话/工作流开箱可用 | 「卖方案」逻辑仍要定制,不能只靠默认 FAQ RAG |
|
||
| 符合数据本地化与 IP 条款 | 需选好 License(Apache/MIT 优先)并出开源清单 |
|
||
| 年度订阅可覆盖模型+运维+迭代 | 多渠道若一次做满会爆工期——合同已限制「选一个高频渠道」 |
|
||
|
||
**结论:唯一与合同周期、金额、数据主权、验收指标同时匹配的路线。**
|
||
|
||
---
|
||
|
||
## 3. 二开底座对比与推荐
|
||
|
||
面向本项目关键能力:RAG 知识库、多轮工作流(追问)、工具调用(方案匹配)、自托管、国产/海外模型可切换、可接人工接管。
|
||
|
||
| 底座 | 知识库/RAG | 工作流/Agent | 业务后台完备度 | 中文生态 | 与本项目匹配 | 建议 |
|
||
|------|------------|--------------|-----------------|----------|--------------|------|
|
||
| **Dify** | 强 | **强**(可视化工作流贴合意图→追问→方案) | **高**(知识库/日志/应用开箱) | 强 | ★★★★★ | **首选** |
|
||
| Flowise | 中(偏编排侧) | **强**(LangChain 节点灵活) | **低**(缺完整客服运营后台) | 中 | ★★★ | 可做引擎,不适合单独交付 |
|
||
| Ragflow | **检索质量突出** | 工作流弱于 Dify | 中(偏知识工程) | 强 | ★★★★ | 检索难达标时与 Dify 组合 |
|
||
| FastGPT | 强(偏问答) | 中 | 高 | 强 | ★★★★ | 备选,复杂判定易顶天花板 |
|
||
| MaxKB | 够用 | 偏基础 | 中高 | 强 | ★★★ | 简单 FAQ 够用,本项目偏弱 |
|
||
| Botpress | 中 | 对话机器人强 | 中高 | 中 | ★★★ | 渠道多时考虑 |
|
||
| 扣子/阿里云等 SaaS | 强 | 强 | 高(非自托管) | 强 | ★★ | 违背数据自主原则 |
|
||
|
||
### 推荐组合(按投入递增)
|
||
|
||
**方案 A|默认推荐(匹配 5 万 / 7 周)**
|
||
|
||
```
|
||
渠道入口(网站插件 或 FB 选其一)
|
||
↓
|
||
Dify(自托管)
|
||
├─ 知识库(产品/技术/方案)
|
||
├─ 工作流:意图分类 → 追问槽位 → RAG → 方案生成
|
||
├─ 低置信度 / 敏感 → 转人工
|
||
└─ 模型:智谱等国产 API(可切私有化)
|
||
↓
|
||
人工接管:Chatwoot(开源)或企业微信/飞书群机器人
|
||
后台:Dify 控制台 + 轻量效果看板(对话日志导出 + Eval 表)
|
||
场景二:录音 → ASR(阿里/讯飞/开源 Whisper 私有化择一)→ 同一工作流出方案
|
||
```
|
||
|
||
**方案 B|检索效果不达标时升级**
|
||
|
||
- 文档解析与向量检索改 **Ragflow**,对话编排仍用 **Dify**(或 Dify 调 Ragflow API)。
|
||
- 适用于产品资料 PDF/图纸多、默认切块幻觉压不下去时。
|
||
|
||
**方案 C|不推荐首期**
|
||
|
||
- 全自研 Agent 框架:超预算与工期。
|
||
- 纯 FastGPT 无工作流定制:难做「先判断再追问再出组合方案」。
|
||
|
||
### 为何首选 Dify(而不是 Flowise)
|
||
|
||
Dify 和 Flowise 都能自托管、都能画工作流,但**产品形态不同**:
|
||
|
||
| 对比项 | Dify | Flowise |
|
||
|--------|------|---------|
|
||
| 定位 | 偏「可交付的 LLM 应用平台」 | 偏「LangChain 可视化编排器」 |
|
||
| 知识库运营 | 文档上传、分段、召回测试、权限较完整 | 有向量/文档节点,**缺甲方业务人员可长期维护的知识库后台** |
|
||
| 合同要的后台 | 对话日志、应用配置、基础观测更开箱 | 多半要**另做 Admin / 日志 / 效果看板** |
|
||
| 「卖方案」链路 | Chatflow/Workflow 直接支撑意图→追问→出方案 | 也能搭,但槽位追问、会话状态、对外 Chat API 要更多拼装 |
|
||
| 甲方侧使用门槛 | 运营/销售助理可在控制台改知识库 | 改流程基本是**开发在画布上改节点** |
|
||
| 中文资料与实施案例 | 多,便于 FDE 驻场与交接 | 英文社区为主,国内交付摩擦更大 |
|
||
| 二开成本(相对本项目) | 定制重心在业务规则与 Eval | 定制要覆盖 **规则 + 大半个运营后台**,易吃掉 5 万预算 |
|
||
| License | Apache-2.0 | Apache-2.0 |
|
||
|
||
**对本合同的含义:**
|
||
|
||
1. 验收写了「知识库可增删改查、对话记录可追溯、数据看板」——Dify 自带大半;Flowise 二开等于还要自研一层运营面。
|
||
2. 7 周里 W2 就要 Concept Demo、W3 真实验证——Dify 用控制台灌资料即可;Flowise 更适合「工程师已写好链路」的演示,不适合业务专家自己改库。
|
||
3. Flowise **不是不能用**,更适合:团队强依赖 LangChain 生态、只要 API 引擎、运营后台另有系统承接。鲜境首期没有现成客服中台,用 Flowise 会把二开做成「半自研」。
|
||
4. 若坚持 Flowise:建议 **Flowise 只做编排引擎 + 自研/套 Chatwoot 做会话与人工接管 + 自研轻量知识库管理**,工作量和风险高于 Dify 单底座。
|
||
|
||
**一句话:Flowise 是好用的编排器;Dify 更接近「能验收交付的 AI 客服底座」。** 在 5 万 / 7 周下选后者。
|
||
|
||
### 为何首选 Dify(相对其他底座)
|
||
|
||
1. **工作流原生支持**合同核心链路「意图识别 → 追问 → 方案生成」,比纯问答库更贴「卖方案」。
|
||
2. **自托管 + 多模型**:满足数据可控与智谱/Gemini 等切换。
|
||
3. **Apache-2.0**:便于合同 5.4 开源清单与乙方框架复用。
|
||
4. **W2 Concept Demo** 可在底座上直接配知识库+简易流,不必先写后台。
|
||
5. 人工接管、评测、渠道适配用周边开源/薄封装即可,不必绑死一家云。
|
||
|
||
---
|
||
|
||
## 4. 必须自研/定制的部分(二开不等于零开发)
|
||
|
||
这些是验收与差异化的关键,**不要指望底座默认能力**:
|
||
|
||
| 模块 | 做法 | 归属(按合同) |
|
||
|------|------|----------------|
|
||
| 方案判定逻辑 | 从业务专家萃取规则/决策树 → Dify 工作流节点或 Tool | 定制成果 → 甲方 |
|
||
| 产品组合匹配 | 结构化产品表 + 规则/检索混合,禁止纯自由发挥 hallucination | 定制 + 知识库 → 甲方 |
|
||
| 追问槽位设计 | 按两大类技术路线设计必问项(预算、场景、工况等) | 定制 → 甲方 |
|
||
| 人工接管策略 | 置信度阈值、敏感词、超时、留资表单 | 定制 → 甲方 |
|
||
| AI Eval | 200 条标注集、盲测流程、幻觉抽检脚本 | 评测资产 → 甲方 |
|
||
| 渠道适配 | **只做一个**高频入口的对接与样式 | 定制 → 甲方 |
|
||
| 开源清单 | Dify/Chatwoot/依赖 License 列表 | 合同强制交付 |
|
||
|
||
底座本身、通用连接器、模板工作流 → 属乙方可复用框架(合同 5.1 / 5.2)。
|
||
|
||
---
|
||
|
||
## 5. 与 7 周计划的落地映射
|
||
|
||
| 周次 | 技术动作(建议) | 防延期要点 |
|
||
|------|------------------|------------|
|
||
| W1 | 锁定唯一渠道;萃取方案判定树;资料分级入库标准 | 甲方不给齐资料则工期按合同顺延 |
|
||
| W2 | Dify 部署 + 样本知识库 + Concept Demo(追问 3–5 轮能出草案) | Demo 先通闭环,不追求全量资料 |
|
||
| W3 | 导入真实资料;人工盲测方案准确率;调检索与提示词 | 未达标先调知识结构,勿急着上第二渠道 |
|
||
| W4–W5 | 人工接管、留资、日志;场景二 ASR 联调(可并行薄做) | 渠道对接放本阶段,避免 W2 分心 |
|
||
| W6 | UAT、安全脱敏、开源清单、部署文档 | 预留修缺陷缓冲 |
|
||
| W7 | 生产试运行、效果看板、首轮 Eval 报告 | 订阅期内持续迭代算年度服务 |
|
||
|
||
**砍范围优先级(预算不够时):**
|
||
保:知识库 + 追问闭环 + 方案生成 + 人工接管 + 单渠道。
|
||
可后置:多渠道、精美独立 Admin、复杂经营看板、海外获客(属框架二期)。
|
||
|
||
---
|
||
|
||
## 6. 模型与部署建议(贴合数据自主)
|
||
|
||
- **推理**:优先智谱 / 其他国产 API;敏感或申报需要时再上私有化(vLLM 等),首期不必自建 GPU。
|
||
- **Embedding**:与知识库同环境部署,避免文档出域。
|
||
- **ASR(场景二)**:可先用云端 ASR 降本;若录音含客户机密,改为私有化 Whisper 类方案。
|
||
- **部署**:客户机房或乙方托管的独立 VPC 均可,但知识库与对话日志不得默认进公有 SaaS。
|
||
|
||
年度 ¥3 万订阅建议覆盖:Token 上限、监控、知识库更新、Eval 与小迭代——与合同 3.3 一致;超用量或新渠道走变更单。
|
||
|
||
---
|
||
|
||
## 7. 风险与门禁
|
||
|
||
| 风险 | 应对 |
|
||
|------|------|
|
||
| 把项目做成「通用 FAQ 机器人」导致方案匹配<80% | W1 必须产出判定树;W3 专家盲测不过不进 P4 全量开发 |
|
||
| 同时做多渠道拖死工期 | 严格按合同「一个高频渠道」 |
|
||
| 幻觉与敏感泄露 | RAG 强制引用;输出护栏;Eval 自动化+人工抽检 |
|
||
| 开源协议纠纷 | 交付开源组件清单;避免传染性 Copyleft 污染定制代码 |
|
||
| 5 万预算被运维吞掉 | 首期单机/小集群 Docker Compose;监控用开源 |
|
||
|
||
---
|
||
|
||
## 8. 最终建议(决策一页纸)
|
||
|
||
1. **路线**:开源自托管 **二开**,不是纯自研,不是纯 SaaS。
|
||
2. **底座**:**Dify 首选**;检索吃力再加 **Ragflow**;人工席位用 **Chatwoot**(或现有企微/飞书)。
|
||
3. **定制重心**:方案判定 + 产品组合 + 追问槽位 + AI Eval + 单渠道接入。
|
||
4. **与合同一致**:7 周、5 万实施、3 万/年订阅、知识库与定制归甲方、框架归乙方可复用。
|
||
5. **首期成功标准**:附件三阈值达标 + 一个渠道 7×24 可用 + 销售辅助能基于录音/文本出方案。
|
||
|
||
---
|
||
|
||
## 9. 建议甲方/乙方立刻确认的 5 件事
|
||
|
||
1. 首期「一个高频渠道」究竟是网站还是 Facebook?
|
||
2. 两大类技术的方案判定树由哪几位业务专家拍板?
|
||
3. 模型选型:智谱 API 是否可直接用于生产?是否有私有化硬性要求?
|
||
4. 场景二是否与场景一同周验收,还是 W7 后订阅期迭代?
|
||
5. 部署位置:甲方机房还是乙方托管 VPC?
|
||
|
||
确认以上后,即可按附件二从 P1 启动,无需再纠结纯自研。
|