AI技术落地典型问题分析

为什么AI技术落地，第一站几乎都是 RAG

当前AI技术如雨后春笋般涌现，但不同的企业遇到的问题不一样，用一套方法论和技术架构无法解决在企业数字化转型中遇到的各种问题。企业落地AI技术解决业务问题，往往遇到的不是技术本身架构的问题，而是技术选型决策与业务匹配的问题，不一味的迎接更难、更深、更新的技术，用合适的技术当前团队匹配的阶段去解决问题。

第一批 AI 项目，核心目标通常很直接：先让系统基于企业知识稳定答对。
这句话听起来像常识，但真正落到项目里，它几乎会决定后面一整条技术路线：在绝大多数企业业务场景里，第一站几乎都会落在 RAG 上，全自治 Agent 往往还排不到前面。

真正麻烦的地方在于，“先做 RAG”只是方向，不是答案。项目一启动，团队很容易把几个不同层面的技术混在一起讨论。最典型的误判有两个：

1. 把 Dify、朴素 RAG、LangGraph RAG、Agentic RAG、LightRAG 当成同一层的备选项。
2. 把 RAG 理解成“向量检索 + 大模型生成”，忽略了企业知识的版本、权限、关系、冲突和评测问题。

所以这篇文章想把四件事说透：

1. 企业为什么第一站几乎都是 RAG。
2. Dify、朴素 RAG、LangGraph RAG、Agentic RAG、LightRAG 分别解决什么问题。
3. 它们在架构、调试、失败模式、上线成本上到底有什么差异。
4. 企业应该如何从一种技术平稳升级到下一种，避免一上来就把系统复杂度拉爆。

一、这些技术不在同一个维度

做技术讨论，最怕一上来就急着选型。更稳妥的做法，是先把对象放回正确维度。
不然讨论“Dify 还是 LightRAG”，其实就有点像在讨论“数据库和微服务谁更好”，话题很热闹，但结论很难成立。

1. Dify：应用与交付平台

Dify 更接近 AI 应用平台，核心价值在于：

• 知识库接入
• 工作流编排
• Agent 节点
• API/Web 发布
• 低代码协作

它更偏向解决 应用怎么更快交付 这个问题，至于 知识求解逻辑怎么做得最优，那是另一层的事情。

2. 朴素 RAG：最小知识增强链路

朴素 RAG 解决的是：

• 把企业文档接进模型
• 用检索约束生成
• 给答案附带引用

它几乎是所有企业 RAG 的起点，不过很少会是终点。

3. LangGraph RAG：可控的状态化 RAG

LangGraph 一类框架真正有价值的地方，在于它能把原本藏在 prompt 里的隐式流程显式化：

• 改写
• 路由
• 补查
• 回退
• 转人工

它解决的是 检索过程需要被建模和治理 的问题。

4. Agentic RAG：给 RAG 增加有限自主决策

Agentic RAG 更适合被理解成一种能力模式，而不是单独的产品。
它让系统在证据不足、知识域不确定、任务路径不固定时，允许一定程度的自主决策。

它解决的是 固定检索管道不够用 的问题。

5. LightRAG：关系增强型 RAG 路线

LightRAG 更适合被放在 图增强 / 关系增强 / 混合检索 这个维度里看。
它并不是默认通用解。只有当问题的主矛盾从“段落命中”转向“关系求解”时，它的价值才会明显放大。

它解决的是 文本相似不等于关系正确 的问题。

二、企业为什么第一站几乎总是 RAG，而不是 Agent

原因并不复杂：企业第一批问题，大多还是“知识可信问题”，离“开放任务求解问题”通常还有一段距离。

典型第一批需求

• 制度问答
• 产品 FAQ
• 客服标准口径
• 合同条款检索
• 售后手册查询
• IT/HR/财务内部知识查询

这些需求的共性是：

1. 依赖企业私有知识，公共常识只能起辅助作用。
2. 要求可引用、可审计，语言自然反而没那么重要。
3. 错误成本很高，不能用“平均上看不错”来安慰自己。
4. 大量问题其实不需要复杂规划，只需要正确取知识。

所以企业第一站通常会先聚焦在“别答错、别乱答”这件事上。
这其实就是 RAG 在企业场景里的原点。

三、企业问题先分型，再谈技术

如果不先按问题结构分类，很多技术选型最后都会变成“凭感觉”。
下面这个分法，比单纯按行业分更适合做技术判断，因为它直接对应系统复杂度。

类型 A：标准知识问答

例子：

• “A 产品保修期多久？”
• “差旅报销标准是什么？”
• “转正流程怎么走？”

技术特征：

• 单知识域
• 低歧义
• 主要靠命中率和引用正确性

类型 B：条件化知识判断

例子：

• “华东区 2025 年新签客户能否沿用旧折扣？”
• “该制度是否适用于外包员工？”
• “教育行业和政企行业报价口径是否不同？”

技术特征：

• 需要补充时间、区域、角色、产品线等过滤条件
• 经常涉及版本和例外规则
• 单次检索容易答偏

类型 C：多文档归纳与组装

例子：

• “汇总三版制度差异”
• “生成投标方案初稿”
• “把售后排障步骤整理成标准作业建议”

技术特征：

• 重点已经不再是单段命中，而是多证据整合
• 对输出格式有要求
• 经常需要模板化生成

类型 D：多源交叉求证

例子：

• “合同主协议和补充协议哪份优先？”
• “工单现象和 E17 故障码是否相关？”
• “订单异常是 CRM 口径问题还是 ERP 数据问题？”

技术特征：

• 跨文档、跨系统、跨知识域
• 常有证据冲突
• 需要补查和回退

类型 E：开放式知识任务

例子：

• “结合工单、日志、手册生成排障报告”
• “分析客户流失原因并给建议”
• “做一次竞品对比和报价策略建议”

技术特征：

• 任务目标宽
• 路径不固定
• RAG 已经成为任务求解的一部分

类型 F：关系密集型知识问题

例子：

• “这个条款被哪份补充协议覆盖？”
• “故障码、模块、工单经验之间是什么关系？”
• “客户、项目、合同、回款节点怎么串起来？”

技术特征：

• 重点不在段落文本，而在实体与关系
• 单纯相似度检索经常“文本像，但关系错”

四、五条路线放在一起看，差别就清楚了

到了真正做选型的时候，大家关心的通常不会是“谁更新”，而是“谁更贴合当前问题”。把几条路线放到同一个坐标系里，很多分歧反而会自然消失。

先看技术定位和工程代价。很多路线纸面上都能讲通，真正拉开差距的，往往是复杂度和失败成本。

总表：技术定位与工程代价

路线	解决的主问题	检索复杂度	编排复杂度	可观测性	典型失败模式	推荐起点
朴素 RAG	单知识域答准	低	低	中	召回偏、切片错、版本错	第一批知识问答
Dify	应用快速交付	取决于底层	低到中	中	平台很快，底层逻辑不够强	多场景试点期
LangGraph RAG	检索过程可控	中	中到高	高	状态设计差、分支爆炸	生产深水区
Agentic RAG	开放任务求解	高	高	中到高	循环失控、成本失控、工具误调用	局部引入
LightRAG	关系求解增强	中到高	中	中	图构建差、实体抽取误差扩散	关系问题成为主矛盾时

再看问题适配。技术路线一旦和问题结构对不上，后面的投入通常都会变得很别扭。

总表：更适合什么问题

问题类型	优先技术	不建议一上来用什么
类型 A 标准问答	朴素 RAG	Agentic RAG
类型 B 条件化判断	LangGraph RAG 或强化版朴素 RAG	纯向量朴素 RAG
类型 C 多文档归纳	Dify Workflow 或 LangGraph RAG	纯 FAQ 型 RAG
类型 D 多源交叉求证	LangGraph RAG，必要时局部 Agentic	只有一次检索的 RAG
类型 E 开放任务	Agentic RAG，最好跑在状态图骨架上	纯低代码拼装
类型 F 关系密集问题	LightRAG 或图增强 RAG	只靠语义向量检索

五、朴素 RAG：能解决 60% 的早期问题，但有明确上限

最合适的地方

• 制度问答
• FAQ 客服
• 产品手册查询
• 内部知识助手

最核心的工程目标

朴素 RAG 能不能站住，关键不在 Demo 漂不漂亮，而在下面四个指标：

1. Recall@K 是否够高
2. Citation Fidelity 是否可靠
3. 版本过滤 是否正确
4. 权限过滤 是否前置

一条成熟朴素 RAG 的最小链路

flowchart LR
    A["文档接入"] --> B["解析与切片"]
    B --> C["向量化与索引"]
    C --> D["检索 TopK"]
    D --> E["带引用生成"]
    E --> F["答案输出"]

朴素 RAG 为什么常在企业里失真

问题通常不在“太简单”，而在于大多数团队把它做得过于粗糙：

1. 文档解析不保留结构
2. 只做向量检索，不做关键词和过滤
3. 切片只按字数，不按语义单元
4. 检索阶段不带权限
5. 最终答案不做引用约束

什么时候说明你已经到上限了

出现以下任意三个信号，就说明朴素 RAG 该升级了：

1. 问题经常带多个限定条件
2. 单轮检索命中相关材料，但总差最后一步
3. 新旧版本冲突频繁
4. 需要跨两个以上知识域联合判断
5. 用户开始问“为什么这样判断”，而不只是“答案是什么”

六、Dify：它强在交付效率，不强在替你做深层检索判断

专业定位

Dify 的核心价值主要体现在团队交付效率上：

• 更快把应用搭出来
• 更快接知识库和工作流
• 更快让业务试用

它更像一个 交付加速器，很难直接替代底层求解逻辑。

适合的使用方式

更稳的做法通常不是“全靠 Dify”，通常会这样分层：

1. 用 Dify 承担应用层和流程层
2. 底层复杂检索逻辑仍由自建服务或专门编排层承担

什么时候 Dify 是好答案

1. 试点场景很多，重复开发太慢
2. 业务方要参与 prompt、知识库、工作流配置
3. 需要快速把能力暴露成 API 或内部助手
4. 当前矛盾主要在交付效率，而不在底层检索能力

什么时候 Dify 不是关键矛盾

1. 你们的问题是“检索逻辑不够强”
2. 你们需要细粒度控制检索状态和失败路径
3. 你们需要复杂 tracing、重放和状态持久化

这时候，Dify 可以继续用，但它不再是主战场。

七、LangGraph RAG：企业真正进入专业区的分水岭

很多团队从朴素 RAG 升级时，第一反应是“要不要上 Agent”。
更成熟的做法，往往是先把检索做成 显式状态图，而不是直接冲向 Agent。

它首先解决的是控制问题

企业复杂问答的真实链路往往是：

1. 先识别问题类型
2. 再做查询改写
3. 再决定查哪个知识库
4. 再判断证据是否充足
5. 不足则补查或换路由
6. 高风险则转人工

如果这些逻辑都塞进一个 prompt，系统看起来能跑，但实际上不可调、不可测、不可复现。

LangGraph RAG 的核心价值

把隐式逻辑拆成节点：

• Intent Classifier
• Query Rewrite
• Retriever Router
• Evidence Check
• Answer Builder
• Human Review

推荐状态字段

一个最小可用的状态对象至少应包含：

query_original
query_rewritten
intent
retrieval_attempts
retrieved_chunks
evidence_score
conflict_flags
risk_level
final_action

这不是形式主义。没有这些状态，你根本不知道系统到底为什么走到这一步。

推荐状态图

flowchart LR
    A["用户问题"] --> B["Intent Classifier"]
    B --> C["Query Rewrite"]
    C --> D["Retriever Router"]
    D --> E["Hybrid Retrieval"]
    E --> F["Evidence Check"]
    F --> G{"证据充足?"}
    G -->|否| H["补查/换路由/转人工"]
    H --> D
    G -->|是| I["Answer Builder"]
    I --> J["Guardrails"]
    J --> K["输出"]

它的代价

1. 节点设计必须清楚
2. 状态字段必须稳定
3. 每个节点都要能单独评测
4. 分支一多，维护成本会上升

最常见失败模式

1. 图画得很大，但每个节点职责模糊
2. 把改写、路由、检索、打分混成一个节点
3. 只有流程图，没有节点级指标
4. 有状态图，但没有回放能力

什么时候该上 LangGraph RAG

当下面这些事情开始反复出现时：

1. 同一问题经常要补查第二轮
2. 不同问题要走不同检索路径
3. 需要显式判断证据够不够
4. 需要把失败路径建模

这是企业从“能跑”走向“能治理”的关键分水岭。

八、Agentic RAG：只在固定逻辑不够时，给系统有限自主性

Agentic RAG 更像一种条件触发的升级路线，不太适合当成默认答案。很多团队的问题，不是上得太晚，而是上得太早。

它适合解决什么

• 多跳检索
• 开放式知识任务
• 跨库、跨工具、跨系统求解
• 难以预先穷尽路径的问题

它真正有价值的地方

它真正的价值，不在“模型能自己想”，而在系统碰到中间状态不充分时，能做下面几类动作：

1. 补查
2. 换知识域
3. 接工具
4. 调整路径

专业系统里，Agentic 不应覆盖哪些节点

以下节点尽量保持确定性：

• 权限判断
• 版本优先级
• 风险分级
• 输出格式校验
• 审计日志

也就是说，Agentic 最好只管 不确定性求解，不要管 规则性治理。

必须显式控制的四个机制

1. Loop Termination

必须设置：

• 最大补查轮次
• 最大工具调用次数
• 最大 token 预算
• 单轮最小增益阈值

否则系统会在“差一点就找到答案”的错觉里不断烧钱。

2. Cost Guardrail

至少要按请求记录：

• 检索轮数
• 工具调用数
• 总 token
• 总耗时

如果没有这些统计，就没有资格谈 Agentic 上线。

3. Tool Gating

不同工具必须分级：

• 只读工具
• 可回滚写工具
• 高风险写工具

高风险工具不能直接开放给 agentic 节点。

4. Evidence Sufficiency

系统必须定义“什么时候算证据够了”。
否则它只会一直补查，直到预算耗尽。

常见失败模式

1. 全链路 agentic，导致系统不可复现
2. 没有终止条件，循环补查
3. 工具调用粒度太粗，失败代价太大
4. 答案看起来完整，但证据链不完整

九、LightRAG：当主矛盾从“段落命中”变成“关系求解”时才值得上

LightRAG 最容易被误解成“更高级的 RAG”。
更准确的说法是：它更适合关系密集型知识场景。

哪类问题最受益

如果你的问题频繁依赖下面这些关系，LightRAG 会比纯向量检索更值得考虑：

• 覆盖关系
• 依赖关系
• 属于关系
• 别名关系
• 演化关系

例如：

• 哪份补充协议覆盖了主协议的哪个条款
• 某故障码通常关联哪个模块和哪类工单经验
• 某客户的项目、合同、回款节点是否存在断链

为什么纯向量检索会失真

因为它擅长找“文本相似”，不擅长找“关系正确”。

一个段落和另一个段落可能很像，但：

• 很可能压根不是同一个实体
• 不在同一时间版本
• 不处于同一关系链

引入 LightRAG 之前必须确认的前提

1. 你已经有相对稳定的文档解析
2. 你已经有基础评测能力
3. 实体抽取和关系抽取至少能达到可用水平
4. 业务问题的主矛盾确实已经转到关系层，而不是还卡在基础检索质量上

常见失败模式

1. 基础数据很脏，却直接上图增强
2. 实体别名没统一，图越建越乱
3. 关系抽取误差沿链路扩散
4. 本来是简单 FAQ，却引入图复杂度

十、不要只看能力，还要看失败模式和调试成本

很多文章喜欢只比较“能力上限”，但企业真到了上线阶段，看的往往不是谁更炫，而是 能力上限 / 调试成本 / 失败可控性 这三件事能不能一起成立。

一张更接近真实工程的对比表

路线	最强能力	最大风险	最难调的点	最关键指标
朴素 RAG	快速交付标准问答	命中偏、引用错	切片与召回	Recall@K、Citation Accuracy
Dify	快速应用化	平台很快，底层逻辑弱	平台与自定义逻辑边界	上线速度、复用率
LangGraph RAG	检索过程可控	状态图膨胀	节点职责和状态设计	Node Success Rate、Replayability
Agentic RAG	动态求解开放任务	成本和行为失控	终止条件和工具治理	Avg Loops、Tool Calls、Cost/Req
LightRAG	关系求解增强	图质量不好会误导系统	实体和关系抽取	Relation Hit Rate、Path Correctness

十一、一个真实可落地的案例：售后排障助手应该怎么选技术

如果一篇文章只讲概念，不讲场景，专业读者通常很难真正买账。
这里用“售后排障助手”做例子，就是因为它天然跨越了朴素 RAG、LangGraph RAG 和 Agentic RAG 的边界，很适合把路线差异讲透。

业务目标

用户输入：

• 故障现象
• 设备型号
• 报错代码
• 最近操作记录

系统希望输出：

• 初步判断
• 可能原因排序
• 排障步骤
• 风险提示
• 对应手册和工单引用

为什么朴素 RAG 不够

如果只做一次检索，系统很容易：

1. 只命中故障码说明，却缺少工单经验
2. 命中旧型号资料
3. 命中的是相似报码，真正的问题报码反而没被抓到
4. 忽略“先断电再排查”这类高风险前置条件

朴素 RAG 能做“查手册”，但很难做“排故判断”。

为什么第一步应该升级到 LangGraph RAG

因为这个场景当前最先暴露出来的，不是开放规划能力不够，而是 检索路径缺少控制。

推荐状态图：

flowchart TB
    A["用户输入<br/>型号/报码/现象"] --> B["Intent Classifier"]
    B --> C["Query Normalize<br/>报码归一/别名展开"]
    C --> D["Retriever Router"]
    D --> E["手册库检索"]
    D --> F["历史工单检索"]
    E --> G["Evidence Merge"]
    F --> G
    G --> H["Safety Check"]
    H --> I{"证据充足?"}
    I -->|否| J["补查或转人工"]
    I -->|是| K["Answer Builder"]
    K --> L["输出排障建议与引用"]

这个场景真正决定成败的几个机制

1. Query Normalize

必须把：

• 故障码别名
• 设备型号简称
• 用户口语描述

统一成检索友好的标准表达。

2. Retriever Router

至少要区分：

• 手册型知识
• 工单经验型知识
• 安全禁令型知识

不能把所有东西混在一个库里一次检索。

3. Safety Check

必须单独做安全规则节点。
比如涉及高压、拆机、断电、停线的风险动作，不能只交给生成模型顺带提一句。

4. Evidence Merge

手册说法和工单经验可能冲突。
必须定义优先级，比如：

1. 官方安全禁令
2. 当前型号手册
3. 历史高质量工单经验

什么时候才值得引入 Agentic RAG

当场景进一步升级为：

• 需要联动日志系统
• 需要读取实时监控
• 需要动态决定下一步查什么
• 需要为复杂故障自动生成排障报告

这时候再把 agentic 能力放进 补查决策 和 工具选择 这些节点，会更稳一些；一开始就全链路 agentic，通常很难收住。

什么时候值得考虑 LightRAG

当排障场景里频繁出现：

• 故障码与模块关系
• 模块与零件关系
• 型号与版本关系
• 现象与历史工单路径关系

这时问题主矛盾会逐渐从“找段落”变成“找关系链”，再考虑用 LightRAG 或图增强检索才合理。

看到这里，概念路线和工程路线的差别其实已经很明显了

如果只停留在概念层，文章通常会这么写：

• 先 RAG
• 再 Agent
• 再图谱

但真正落到工程里，更合理的说法往往是：

1. 先确认主矛盾是检索命中还是关系求解
2. 先把检索流程状态化
3. 再在局部节点引入 agentic
4. 最后在关系成为主矛盾时引入图增强

十二、稳定升级路线：别急着追更复杂的技术，先看谁能解决当前主矛盾

企业技术路线往上走，最怕的往往不是慢，反而是跳级。下面这条升级路径，核心不是“越新越好”，而是每一步都先把当前矛盾解开。

阶段 1：朴素 RAG 打底

必须完成：

• 解析
• 切片
• 混合检索
• 引用回答
• 权限过滤
• 基础评测

阶段 2：Dify 做应用规模化

适合在：

• 多场景试点
• 业务共创
• 快速交付

这时引入。

阶段 3：LangGraph RAG 做检索过程治理

适合在：

• 多条件问答
• 多源补查
• 冲突消解
• 失败路径建模

成为主矛盾时引入。

阶段 4：局部引入 Agentic RAG

只在：

• 补查
• 跨域整合
• 工具选择
• 开放任务分析

这些不确定性节点引入。

阶段 5：关系问题成为主矛盾时引入 LightRAG

只有当“关系正确性”比“段落命中率”更重要时，图增强路线才会真正带来收益。

十三、什么时候该升级：一套给 CTO 和架构师看的判断清单

很多团队并不缺技术名词，真正缺的是升级时机判断。下面这组清单，更适合拿去做内部评审或路线复盘。

从朴素 RAG 升到 Dify

当交付速度成为主矛盾：

1. 场景很多，重复开发太慢
2. 业务方要参与配置
3. 需要快速批量发布应用

从朴素 RAG 升到 LangGraph RAG

当检索控制成为主矛盾：

1. 一轮检索经常不够
2. 问题需要不同路由
3. 需要证据充足度判断
4. 需要显式失败路径

从 LangGraph RAG 升到 Agentic RAG

当开放任务求解成为主矛盾：

1. 路径难以预先定义
2. 需要动态决定下一步
3. 需要跨工具、跨系统联合求解

从普通 RAG 升到 LightRAG

当关系建模成为主矛盾：

1. 问题核心是实体关系
2. 相似度命中看似相关但关系错误
3. 需要跨实体追踪知识链

十四、结论：企业真正要选的，是“下一步最合适的复杂度”

企业的第一站几乎总是 RAG，这和保守不保守关系不大，更主要是因为企业 AI 的第一性问题本来就是知识可信。
真正有经验的团队和只会讲概念的团队，差别往往也不在谁知道更多名词，而在于前者更清楚下面这些判断：

• Dify 是平台，不该被当成算法路线讨论
• 朴素 RAG 很适合起步，但很难包打天下
• LangGraph RAG 是进入专业治理区的分水岭
• Agentic RAG 应该只在不确定性节点局部引入
• LightRAG 只有在关系成为主矛盾时才值得投入

真正成熟的技术判断，最后都会回到几个很朴素的问题上：

1. 当前主矛盾在交付、检索、编排，还是关系建模？
2. 当前问题需要的是命中、补查、决策，还是关系求解？
3. 当前团队有没有能力支撑更高复杂度的调试和治理？
4. 升级之后，权限、评测、审计、成本能不能一起跟上？

能沿着这四句话往下走，企业才更有机会把 RAG 从试点能力真正做成生产能力。