Dify 还是自研 RAG：铸造 MES/ERP 场景的架构共创与落地计划

背景与目标

本篇用于把一次“Dify vs 自研 RAG”的架构讨论整理成可复盘记录，避免后续只记结论、不记前提。

讨论前提：

  1. 已完成一轮 Python AI 控制面重构。
  2. 需要快速接入铸造行业知识库能力。
  3. 同时满足“生产可用”和“可作为面试项目叙事”两类目标。
  4. 数据来源复杂（公众号、书籍、工艺参数文档、行业文档），噪声高、知识密度高。
  5. 业务并行存在 MES 实时数据工具调用 + 行业知识问答两类请求。

本轮目标：

  1. 明确路线：Dify、纯自研、混合三种方案中怎么选。
  2. 明确策略：Agent 策略如何收敛，避免“策略堆叠”。
  3. 明确工程门禁：如何防止“看起来能答、上线后不稳定”。

决策记录（Decision Log）

尖锐结论（4 条）

a. 瓶颈在 数据清洗 + chunk 策略 + 检索过滤 + 评测集，不是 Agent 花样。
b. 最优路线是 “自研检索内核 + 现有 Python Control Plane + 可选 Dify External Knowledge API”。
c. Agent 策略收敛为：ReAct 默认；Plan-and-solve 仅复杂任务；Reflection 仅低置信/高风险触发。
d. 没有 Gold Set（金标问答）+ 回归门禁，系统很容易“看起来能答但不稳定”。

最该先拍板的 10 个问题（完整列出）

  1. 数据合规先不管，能不能先做？
  2. 如果增强效果需要上新基础设施，可以加吗？
  3. 数据量 <= 20G、QPS 50~500，整体怎么设计？
  4. 先用 Qwen 最强模型验证效果，后续再谈成本，是否可行？
  5. Reranker 私有部署和公有部署的关键区别是什么？
  6. ACL 是什么？在 RAG 链路里放在哪一层？
  7. 数据更新要分钟级，能支持吗？
  8. Dify 和自研双接入是否推荐？
  9. 什么是金标问答？为什么必须做？
  10. 低置信时策略怎么定？

KEY CONTENTS

你的这 10 条反馈非常关键，基于它我给出一个更落地的结论：

1. 路线定型

- 采用“双线并行”：自研 RAG Retrieval API + Dify External Knowledge API 同时接入。
- 在线主链路：Python Agent 调你自研检索服务；Dify 作为并行入口与备份编排入口。
- 这条路兼顾“快出效果”和“长期可控”。

2. 尖锐提醒（必须直说）

- 4核8G + 无GPU 想稳定跑高质量本地 reranker + 50~500 QPS，现实上很吃力。
- 你可以先用 Qwen 最强模型做效果验证，但生产一定要做“分级策略+缓存+降级”，否则成本和时延会失控。
- 真正决定效果的，不是 Agent 名字，而是数据清洗、chunk、过滤和评测集。

3. 你问的关键点回答

- ACL 是什么：Access Control List，访问控制列表。
  在你场景里就是“谁能检索到哪些文档/片段”。最小粒度建议到 chunk，至少带 tenant_dept_id、visibility_level、
  role_scope。
- 私有 vs 公有 reranker：
  公有API优点是快上线、质量通常更高、无算力压力；缺点是网络时延、调用成本、限流。
  私有部署优点是可控和数据不出域；缺点是你当前机器配置下吞吐偏低，维护成本更高。
  你的现状建议：先公有API reranker验证效果 -> 后续再评估私有化。
- 金标问答是啥，为什么能提升效果：
  金标问答不是 few-shot。
  它是“评测基准集”，用于客观判断你每次改动到底变好还是变坏。
  没有金标集，RAG 调优基本是拍脑袋。

4. 金标问答样例（非本行业示例）

{
  "id": "qa_001",
  "question": "锅炉水质硬度超标会导致什么问题？",
  "answerable": true,
  "expected_doc_ids": ["doc_chem_12", "doc_ops_03"],
  "must_include_points": [
    "结垢风险",
    "换热效率下降",
    "能耗上升"
  ],
  "must_not_include_points": [
    "与硬度无关的结论"
  ]
}

{
  "id": "qa_002",
  "question": "2030版某标准中新增了哪些条款？",
  "answerable": false,
  "expected_doc_ids": [],
  "must_include_points": [
    "当前知识库证据不足"
  ]
}

5. 按你约束后的推荐技术方案

- 检索引擎：OpenSearch（支持 BM25 + 向量 + 过滤）。
- 检索策略：Hybrid Recall（BM25 + Dense）+ RRF 融合。
- Rerank策略：只对复杂/低置信问题启用。
- 更新策略：分钟级增量（队列化 ingest + upsert index）。
- 回答策略：你已定的“追问 + 风险提示回答”，非常正确。
- Agent策略：默认 ReAct；复杂任务再开 Plan-and-Solve；Reflection 只在低置信触发。

关键决策结论（按讨论时间固化）

日期 决策项 结论
2026-02-20 路线选择 采用混合路线，不做纯 Dify/纯自研二选一。
2026-02-20 能力分层 Dify 负责流程编排试错；检索上限由自研内核负责。
2026-02-20 Agent 策略 ReAct 默认；Plan-and-solve 和 Reflection 改为按条件触发。
2026-02-20 质量门禁 必须建设 Gold Set 与回归评测，禁止“凭感觉调参上线”。

Q&A 纪要（含用户原始输入）

以下 10 条“用户原始输入 + 用户回答”按讨论记录完整保留，不做摘要改写。

Q1

用户原始输入：数据合规先不管，能不能先做？
用户回答（完整保留）：可以先做验证版，但建议保留文档来源和版本元数据，后续补治理时不会返工。

Q2

用户原始输入：如果增强效果需要上新基础设施，可以加吗？
用户回答（完整保留）：可以。建议优先上支持混合检索的引擎（如 OpenSearch）。

Q3

用户原始输入：数据量 <= 20G，QPS 50~500，怎么设计？
用户回答（完整保留）：这个规模下，核心不在“能不能跑”，而在“高峰稳定和检索质量可回归”。需要缓存、分级策略和压测门禁。

Q4

用户原始输入：先用 Qwen 最强模型验证效果，后续再谈成本，是否可行？
用户回答（完整保留）：可行，且是正确顺序。先做质量上限验证，再做成本优化和模型分层。

Q5

用户原始输入：Reranker 私有部署和公有部署区别？
用户回答（完整保留）：

公有部署：上线快、质量通常更好、免运维，但有调用成本和外部延迟。
私有部署：数据与服务更可控，但你当前 4核8G + 无GPU 条件下吞吐会受限。
建议：先公有验证，后私有评估。

Q6

用户原始输入：ACL 是什么？
用户回答（完整保留）：ACL（Access Control List）是访问控制列表。在 RAG 里就是“谁能检索到哪些文档/片段”的硬约束，必须在召回阶段就生效。

Q7

用户原始输入：数据更新要分钟级，能支持吗？
用户回答（完整保留）：能。需要增量 ingest + upsert 索引 + 任务队列，避免全量重建。

Q8

用户原始输入：Dify 和自研双接入是否推荐？
用户回答（完整保留）：推荐。这正是当前阶段“快 + 稳 + 可扩展”的最优策略。

Q9

用户原始输入：什么是金标问答？为什么必须做？
用户回答（完整保留）：金标问答不是 few-shot，它是评测基准集。作用是客观评估“改了检索策略后是否真的变好”，避免调参靠感觉。

金标样例（非行业）：

1
2
3
4
5
6
7
{
  "id": "qa_001",
  "question": "锅炉水质硬度超标会导致什么问题？",
  "answerable": true,
  "expected_doc_ids": ["doc_chem_12", "doc_ops_03"],
  "must_include_points": ["结垢风险", "换热效率下降", "能耗上升"]
}

Q10

用户原始输入：低置信时策略怎么定？
用户回答（完整保留）：采用“追问 + 带风险提示回答”。这是兼顾可用性与安全性的合理策略。

术语解释（4 个）

Hybrid Retrieval

同一查询同时做关键词召回（BM25 等）和向量召回，再做融合排序。目标是兼顾“术语精确命中”和“语义相近召回”。

Reranker

对初步召回结果做二次排序的模型/服务。它不负责“广撒网召回”，主要负责“把更相关结果排到前面”。

Reflection Gating

不是全量反思，而是“按门控触发反思”：仅在低置信度、高风险问题时触发，避免时延与成本失控。

Gold Set

用于评测的金标问答集，不是提示词样例。核心用途是做离线评测和回归门禁，验证系统改动是否真实提升。

基于 10 条回答的落地结论

路线定型

路线正式定为：自研检索内核 + 现有 Python Control Plane + 可选 Dify External Knowledge API。
这保证了短期上线速度与长期可控上限兼得。

尖锐提醒

如果先投入大量时间做 Agent 花样，而没有先稳定“清洗、切分、检索过滤、评测集”，上线后会出现“个别案例惊艳、整体稳定性不足”的典型反模式。

关键问答解释（影响实现优先级）

  1. Q4 明确“先上限后成本”：先用强模型验证能力上限，再做分层降本。
  2. Q5 明确“先公有后私有”：在 4核8G + 无GPU 资源约束下，先用公有 reranker 更稳妥。
  3. Q7 明确“分钟级更新要靠增量链路”：必须做 ingest 增量化与 upsert，不能靠全量重建。
  4. Q9/Q10 明确“必须可评测 + 可兜底”：有金标、有门禁、有低置信策略，才是生产系统。

金标样例（用于回归评测）

以下样例沿用 Q9 讨论，用于说明 Gold Set 的结构要求：

1
2
3
4
5
6
7
{
  "id": "qa_001",
  "question": "锅炉水质硬度超标会导致什么问题？",
  "answerable": true,
  "expected_doc_ids": ["doc_chem_12", "doc_ops_03"],
  "must_include_points": ["结垢风险", "换热效率下降", "能耗上升"]
}

推荐技术方案（由 Q&A 反推）

  1. 检索：Hybrid Retrieval + ACL 过滤 + 条件触发 reranker。
  2. 编排：Python Control Plane 承担主链路编排与工具路由。
  3. 对接：保留 Dify External Knowledge API 作为可选知识入口。
  4. 评测：Gold Set + 回归门禁（Recall@K、citation 覆盖率、低置信策略命中率、P95 时延）。

架构方案与阶段计划

架构分层（生产口径）

  1. 接入层：Dify 编排入口（快速试错）+ Python Agent 入口（主生产路径）。
  2. 检索层（自研内核）：解析/清洗/切分、混合召回、ACL 过滤、reranker、证据引用。
  3. 决策层：默认 ReAct；复杂任务才启用 Plan-and-solve；低置信/高风险才启用 Reflection。
  4. 评测与观测层：Gold Set 回归评测、线上指标告警、链路可追踪。

阶段计划（沿用原讨论节奏）

Phase 1（2~3 周）：先跑通效果

  1. 建立最小 ingest pipeline（解析/清洗/切分/元数据）。
  2. 上线 Hybrid Retrieval（关键词 + 向量）与基础过滤。
  3. 输出可引用证据（chunk/doc 引用 ID）。

Phase 2（3~5 周）：提升稳定性

  1. 加 reranker（按复杂度和置信度触发）。
  2. 建立分钟级增量更新链路。
  3. 建立缓存与限流，控制峰值时延。

Phase 3（5~8 周）：工程化闭环

  1. 建立金标问答集和离线评测流水线。
  2. 对接 Dify External Knowledge API 与 Python Agent 双入口。
  3. 做回归门禁（Recall@K、citation 覆盖率、低置信策略命中率、P95 时延）。

风险与反模式

  1. 反模式：过早追求 Agent 复杂策略，忽略数据清洗与 chunk 质量。
    风险：线上结果波动大、复现困难。
  2. 反模式：没有 Gold Set 和回归门禁就频繁改策略。
    风险：每次优化都可能隐性退化。
  3. 反模式：ACL 后置到生成阶段才做。
    风险：召回阶段即发生越权风险。
  4. 反模式：分钟级更新诉求仍走全量重建。
    风险：索引延迟不可控，资源浪费。
  5. 反模式：低置信场景不给追问/风险提示。
    风险：系统“答得很满但不可靠”。

后续行动项（Owner/截止）

行动项 Owner 截止
形成 Gold Set v1（至少覆盖上述 10 个高频问题） 业务专家 + AI 平台（待指派） 2026-02-27
打通增量 ingest + upsert（分钟级更新） 数据接入负责人（待指派） 2026-03-06
完成 Hybrid Retrieval + ACL 召回前置 检索内核负责人（待指派） 2026-03-13
上线条件触发 reranker 与低置信兜底策略 推理编排负责人（待指派） 2026-03-20
建立回归门禁（Recall@K / citation / P95）并接入发布流程 评测与平台工程负责人（待指派） 2026-03-27

结语

在铸造 MES/ERP 场景，真正决定成败的不是 Agent 名字，而是数据管道质量、检索过滤设计、评测回归体系。
先把这三件事做扎实，RAG 才能从 Demo 变成稳定生产能力。

AI
#AI工作日志 #AI工程 #RAG #Dify #MCP #架构设计 #知识库
Dify 还是自研 RAG：铸造 MES/ERP 场景的架构共创与落地计划
https://willfordzhan.github.io/2026/02/20/dify-rag-mes-erp/
作者
詹文杰
发布于
2026年2月20日
许可协议