一、为什么用 Dify 和 RAG？

我一开始的目标其实很简单：
做一个能模仿我回答风格、在日常聊天中“像我一样说话”的 Agent。

在这个前提下，我并不需要一个复杂的推理系统，也不打算做模型微调。
最直接、成本最低、可控性也最强的方式，就是 RAG。

RAG 的好处在于：

• 不改模型本身

• 知识可以随时增删

• 回答有来源，不靠模型“猜”

至于为什么选 Dify，因为Dify 把 AI 应用中「非业务核心但又必须存在的部分」几乎全部封装掉了，操作很简单。

---

二、设计与架构：我一开始踩过的坑

最开始我在流程设计上犯了一个很典型、也很致命的错误。

❌ 错误的流程设计

我一开始的思路是：

用户问题
  ↓
LLM 先生成回答
  ↓
用回答去知识库里检索

结果就是rag检索不到任何内容，LLM也在乱答一通

原因其实很简单——
LLM 已经根据问题生成了一段“看似合理”的回答，再用这段回答去做向量检索，本身就已经偏离了原始语义。

本质上等于：

用“模型的猜测”，去匹配“真实语料”。

自然是对不上的。

---

✅ 正确的顺序应该是

关键点只有一句话：

一定要用“用户的原始问题”去做检索，而不是模型的回答。

最终采用的流程是：

用户输入
  ↓
Dify Chat Agent
  ↓
判断是否需要知识库
  ↓
RAG 检索（向量搜索）
  ↓
拼接上下文 Prompt
  ↓
LLM 生成回答

这样做之后，命中率和回答质量立刻就稳定了下来。

---

三、知识库设计（RAG 的核心）

1️⃣ 知识来源

我的知识库并不是技术文档，而是聊天记录语料。

处理方式是：

读取历史聊天记录然后整理成 Q&A 结构

---

2️⃣ 文档拆分（Chunk）

因为单条内容都比较短，这里没有做特别复杂的拆分策略：

• 使用 Dify 默认的 chunk 方式

• 不额外切分、不加 overlap

在这种偏“对话型语料”的场景下，过度切分反而容易破坏上下文。

---

3️⃣ Metadata 设计

虽然当前文档量不大，但我还是提前设计了 metadata：

• 场景标签

• 内容类型

目的只有一个：
当文档变多时，检索还能跑得动、管得住。

---

四、检索策略与参数设置

这一部分我调了挺久，也踩了一些“性价比坑”。

1️⃣ 为什么不用「经济模式」

在测试中我发现：

• 不管关键词给得多准

• 只要用纯关键词或偏全文检索

• 命中率都很不稳定

问题在于：
对话场景下，很难保证用户提问和知识库关键词高度一致，基本就是用不了！

---

2️⃣ 最终采用的方案：混合检索 + 权重控制

配置思路是：

• TopK：3～5

• 启用相似度阈值过滤

• 使用 向量检索 + 关键词检索的混合模式

这样既能保证语义理解，又能兼具性能和经济。

---

3️⃣ 关于 Rerank

Rerank 就是给检索出来的结果，重新排个更准的名次，但是要花钱

对我这个小 Agent来说：混合检索 + 权重设置，已经完全够用，就不上Rerank。

五、总结与可扩展方向

目前这个 Agent 已经能稳定地：

• 命中我自己的语料

• 模仿我的回答方式

• 在聊天场景下不显得“太像客服”

至于后续的扩展 自动更新知识库

理想状态下的结构会是：

用户
 ↓
Router Agent
 ↓
┌──────────────┐
│ Knowledge Agent │ ← 自动更新知识库
└──────────────┘
 ↓
┌──────────────┐
│ Tool Agent     │ ← 实时数据
└──────────────┘
 ↓
Response Agent（总结 / 解释）

到那一步，这个 Agent 才算真正“活着”。

---