RAGFlow 2

管理员在配置页面（Chat Configuration）点击“Add Variable”。系统会在数据库里记录一个 JSON Schema。"label": "您的职业","options": ["工程师", "设计师", "产品经理"],“设置对话变量”是 RAGFlow 提供的低代码（Low-Code）逻辑控制能力。对比没用变量用了变量Prompt 形态静态的文本块动态的填空题模板用户体验所有

The Straggling Crow

1082人浏览 · 2025-12-12 17:25:37

The Straggling Crow · 2025-12-12 17:25:37 发布

这段文字介绍的是 RAGFlow 的 “对话变量（Chat Variables）” 功能。

简单来说，这是给提示词（Prompt）玩 “填空游戏”。它允许你在设置 Prompt 时留出一些 “空位”，然后在用户开始聊天前，让用户（或系统）填入具体的值。

如果说 Prompt 是给 LLM 的“剧本”，那么对话变量就是剧本里的“角色名”和“场景设定”。有了它，同一个剧本可以演变出无数种个性化的版本。

1. 核心功能与实例说明

痛点：千篇一律的机器人

如果没有变量，你的 Prompt 可能是写死的：“你是一个精通 Python 的编程助手”。

如果用户想问 Java 问题怎么办？你得重新建一个机器人。
如果用户是小学生，听不懂专业术语怎么办？你又得建一个“少儿编程机器人”。

解决方案：动态注入

使用变量，你可以把 Prompt 改成：“你是一个精通 {{ language }} 的编程助手，请用 {{ tone }} 的语气回答。”

场景实例：多语言翻译官 & 风格控制器

假设你正在搭建一个“智能翻译助手”。

1. 后台设置（管理员）：
管理员在 RAGFlow 的“变量设置”中定义两个变量：

变量 A：target_lang (目标语言)。类型：下拉菜单（选项：中文、英文、日文）。
变量 B：difficulty (专业程度)。类型：下拉菜单（选项：像给 5 岁孩子讲、像给博士讲）。

2. Prompt 编写：
管理员在系统提示词里写：

“你是一个翻译专家。请将用户的输入翻译成 {{ target_lang }}。要求你的用词风格必须 {{ difficulty }}。”

3. 前端交互（用户）：
当用户打开这个聊天窗口时，系统会先弹出一个表单：

请选择目标语言：[ 用户选了英文 ]
请选择专业程度：[ 用户选了 像给 5 岁孩子讲 ]

4. 最终效果：

用户输入： “量子纠缠是什么？”
RAGFlow 实际发给 LLM 的指令：

“你是一个翻译专家。请将用户的输入翻译成英文。要求你的用词风格必须 像给 5 岁孩子讲。”
LLM 回答： “Quantum entanglement is like two magic dice…” (用非常简单的英文解释)。

价值点： 用一套 Prompt 适配多种场景，实现了“千人千面”的个性化服务，而无需创建多个 Agent。

2. 功能实现链条 (Implementation Chain)

这个功能的实现属于 Prompt Engineering（提示工程） 的预处理环节。

步骤一：变量定义与 Schema 构建 (Definition)

动作： 管理员在配置页面（Chat Configuration）点击“Add Variable”。

数据结构： 系统会在数据库里记录一个 JSON Schema。

{
  "key": "user_role",
  "label": "您的职业",
  "type": "select",
  "options": ["工程师", "设计师", "产品经理"],
  "required": true
}

步骤二：前端表单渲染 (Form Rendering)

动作： 当用户点击“开始聊天”或刷新页面时，RAGFlow 前端读取上述 Schema。
展示： 自动渲染出一个 HTML 表单，强制或引导用户在对话开始前填写这些信息。

步骤三：模板渲染 (Template Rendering) —— 核心步骤

时机： 用户填完表单，发送第一条消息的那一刻。
输入：
1. 原始 Prompt 模板： ...作为一名 {{ user_role }}，请分析...
2. 用户填写的变量值 (Context)： {"user_role": "设计师"}
引擎： 使用类似 Python 的 Jinja2 或简单的字符串替换算法。
动作： 将模板里的 {{ user_role }} 替换为 设计师。

步骤四：上下文注入 (Context Injection)

结果： 生成了最终的 System Prompt。
执行： 这个“定制化”的 Prompt 会被作为 System Message 发送给 LLM。
- 注：这就好比你在每次对话开始前，先悄悄给 LLM 塞了一张纸条，告诉它“在这个会话里，请把对方当作设计师来对待”。

3. 总结

“设置对话变量” 是 RAGFlow 提供的低代码（Low-Code）逻辑控制能力。

对比	没用变量	用了变量
Prompt 形态	静态的文本块	动态的填空题模板
用户体验	所有人得到一样的服务	用户可以定制自己的服务模式
维护成本	需要为不同场景创建多个 Bot	一个 Bot 搞定所有变体
实现原理	直接透传	表单收集 -> 字符串替换 -> 透传

这使得 RAGFlow 不仅能做“企业知识库”，还能做“填表生成器”、“多风格文案助手”等工具型应用。

问答缓存（Q&A Cache）

这段文字介绍的是 RAGFlow 的 “问答缓存（Q&A Cache）” 功能，旨在加速问答并节省成本。

简单来说，这就是给 AI 配了一个 “记性极好的笔记本”。

普通的 RAG 是“每次都重新做题”；而开启了这个功能后，系统会先看**“这道题（或类似的题）以前有没有人问过？”**。如果问过，直接把上次的答案抄过来，不再去翻书（检索），也不再请教授（LLM）重新组织语言。

1. 核心功能与实例说明

痛点：重复劳动与资源浪费

在企业应用中，80% 的人往往问的是 20% 的相同问题（比如“怎么重置密码？”、“发票怎么开？”）。
如果没有缓存：

张三问“怎么开发票”，系统消耗 0.5 元 Token，花了 5 秒生成答案。
李四问“发票流程是什么”，系统又消耗 0.5 元 Token，又花了 5 秒生成答案。
这既慢又费钱。

解决方案：语义缓存 (Semantic Cache)

RAGFlow 不仅仅是匹配“完全一样的字”，而是匹配**“意思一样的问题”**。

场景实例：HR 薪资咨询机器人

1. 第一次提问（缓存未命中 - Cache Miss）：

张三问： “这周六加班有加班费吗？”
系统动作： 缓存里没找到类似问题 -> 去知识库检索员工手册 -> LLM 计算并生成回答：“根据手册，周末加班按 2 倍工资计算。”
后台动作： 系统悄悄地把 {问：“这周六加班有加班费吗？”, 答：“根据手册，周末加班按 2 倍工资计算。”} 这一对数据存入了缓存库。

2. 第二次提问（缓存命中 - Cache Hit）：

李四问： “周末上班给多少钱？”（注意：用词完全不同，但意思一样）
系统动作：
1. 计算“周末上班给多少钱”的向量。
2. 在缓存库里搜索，发现它和“这周六加班有加班费吗？”的相似度高达 0.95。
3. 拦截！ 不再调用 GPT-4，不再检索文档。
4. 直接返回张三得到的那个答案。
效果： 响应时间从 5 秒缩短到 0.1 秒，Token 消耗为 0。

2. 功能实现链条 (Implementation Chain)

这个功能在 RAGFlow 的处理流程中处于最前端的“看门人”位置。

步骤一：向量化与相似度计算 (Embedding & Similarity Check)

输入： 用户的新问题 $Q_{new}$ 。
动作： 系统使用 Embedding 模型将 $Q_{new}$ 转化为向量。
搜索目标： 系统不去搜“知识库文档”，而是去搜 “历史问答对（Q&A Pair）数据库”。
判断： 计算 $Q_{new}$ 与历史问题 $Q_{history}$ 的相似度分数（Score）。

步骤二：阈值判定 (Threshold Decision)

这是一个关键的分岔路口，取决于你在后台设置的相似度阈值（Similarity Threshold）（通常设置得比较高，比如 0.9，以防答非所问）。

分支 A：命中 (Hit - Score > 0.9)
- 动作： 直接提取对应的历史答案 $A_{history}$ 。
- 输出： 立即返回给用户。流程结束。（跳过了检索文档和 LLM 生成）。
分支 B：未命中 (Miss - Score < 0.9)
- 动作： 放行。进入标准的 RAG 流程：
  1. 检索知识库（Retrieval）。
  2. LLM 生成答案（Generation）。
- 后续动作（异步）： 拿到 LLM 生成的新答案 $A_{new}$ 后，系统会将这一对 $Q_{new}, A_{new})$ 写入缓存数据库，为下一个人做准备。

这段文字介绍的是 RAGFlow 的 “语义缓存（Semantic Cache）” 功能。在 RAGFlow 的界面描述中，通常被称为 “Accelerate Question Answering（加速问答）”。

简单来说，这是一个 “抄作业” 机制。系统会记住之前回答过的问题。当有新问题进来时，如果发现意思和以前问过的问题高度相似，就直接把上次的答案拿出来给用户，不再重新去检索文档和调用大模型。

这就像老师批改卷子，如果发现两张卷子的题目一模一样，他就不需要重新算一遍答案，直接把标准答案写上去即可。

1. 核心功能与实例说明

核心价值

极速响应（Low Latency）： 省去了检索和 LLM 推理的时间，几乎是秒回。
节省成本（Cost Saving）： 因为没有调用 LLM（如 GPT-4），所以不消耗任何 Token，这对于高频重复问题非常省钱。

场景实例：电商客服机器人

假设你运营一个电商售后机器人，后台设置的相似度阈值是 0.9。

第一阶段：冷启动（无缓存）

用户 A 提问： “你们的退货政策是什么？”
系统动作：
1. 查缓存？没查到。
2. 去知识库检索“退货政策”文档。
3. 调用 LLM 生成回答：“我们的商品支持 7 天无理由退货，请保持包装完整…”
4. 【关键动作】 系统将 {"问题": "你们的退货政策是什么？", "答案": "我们的商品支持..."} 这一对数据存入缓存库。

第二阶段：加速生效（缓存命中）

用户 B 提问： “我想退货，有什么规定吗？”
系统分析： 虽然字面不一样，但在语义空间里，“退货政策是什么”和“我想退货有什么规定”意思极度接近。
系统动作：
1. 计算用户 B 问题的向量。
2. 在缓存库里比对，发现与用户 A 的问题相似度高达 0.95。
3. 直接拦截！ 系统判断 0.95 > 0.9（阈值），直接把上次给用户 A 的答案扔给用户 B。
结果： 用户 B 瞬间收到回复，且未消耗任何 API 费用。

2. 功能实现链条 (Implementation Chain)

这个功能在 RAGFlow 的架构中，位于最前端的“拦截层”。

步骤一：语义向量化 (Vectorization)

输入： 用户的新问题 $Q_{new}$ 。
动作： 使用 Embedding 模型（如 text-embedding-3-small 或 bge-large）将文本转化为向量。
目的： 为了理解“意思”，而不是匹配“关键词”。

步骤二：缓存检索 (Cache Lookup)

目标： 系统在一个专门存储“历史问答对”的向量索引中进行搜索（注意：不是搜知识库文档，是搜历史记录）。
计算： 找出与 $Q_{new}$ 距离最近的历史问题 $Q_{top1}$ ，并得到相似度分数 (Similarity Score)。

步骤三：阈值判定 (Threshold Decision) —— 核心逻辑

系统会对比用户在后台设置的 Similarity Threshold（相似度阈值，例如 0.9）。

情况 A：命中 (Score ≥ 阈值)
- 判定： 这是一个重复问题。
- 动作： 直接从数据库取出 $Q_{top1}$ 对应的答案 $A_{old}$ 。
- 输出： 返回给用户。流程终止。
情况 B：未命中 (Score < 阈值)
- 判定： 这是一个新问题，或者是虽然相似但有细微差别的坑（比如“退货政策”和“退款多久到账”很像，但不能混用）。
- 动作： 放行，进入标准的 RAG 流程（检索文档 -> 重排序 -> LLM 生成）。
- 回写 (Update)： 等 LLM 生成了新答案 $A_{new}$ 后，系统会异步地将这一组 $Q_{new}, A_{new})$ 写入缓存库，让系统越来越聪明。

3. 总结

特性	普通 RAG 流程	开启“加速问答”后
面对重复问题	每次都像第一次见一样，重新思考、重新生成	像复读机一样，直接复述标准答案
响应速度	慢（3~10秒）	快（< 1秒）
API 成本	高（每次都要付费）	低（命中缓存则免费）
适用场景	复杂分析、千人千面的个性化创作	客服 FAQ、规章制度查询、标准作业流程

注意事项： 必须合理设置阈值。

阈值太低（如 0.5）： 容易答非所问（把“怎么买票”的答案回给了“怎么退票”）。
阈值太高（如 0.99）： 缓存几乎不生效，必须字字相同才能命中。

这段文字介绍的是 RAGFlow 的 “AI 搜索（AI Search）” 模式。

简单来说，这是一个 “企业版的 Perplexity.ai” 或 “带答案的超级搜索引擎”。

与普通的“聊天（Chat）”模式不同，AI Search 不强调“对话”和“拟人化”，而是强调 “答案的精准度”、“信息来源的可视化” 和 “相关问题的延伸”。它更像是一个工具，帮你快速从海量文档中提取确凿的证据。

1. 核心功能与实例说明

痛点：聊天模式的“黑盒”感

在普通聊天模式下，AI 回答一大段话，虽然有引用链接，但用户往往懒得点开验证。对于律师、研究员、审计师来说，他们更需要**“一眼看到证据”**。

核心特征

来源卡片（Source Cards）： 直接展示文档的缩略图、标题、匹配片段。
行内引用（Inline Citation）： 每一句话后面都紧跟 [1] [2]。
相关推荐（Related Questions）： 猜你想问什么。

场景实例：招投标文件的技术参数核对

假设你是一家工程公司的技术员，资料库里有几十份、上千页的《国家建筑标准》和《过往项目标书》。

用户操作： 进入 RAGFlow 的 AI Search 界面，输入：“抗震等级为 8 级时的钢筋配比要求。”

RAGFlow AI Search 的反馈页面：

顶部 - 智能回答（Answer）：

“根据《建筑抗震设计规范》（GB50011-2010），在 8 级抗震设防区，框架梁端加密区的箍筋最小直径为 10mm [1]，且体积配箍率不应小于 1.2% [2]。”
中部 - 来源列表（Sources）：
- 卡片 1： 展示《GB50011-2010.pdf》的封面缩略图，并高亮显示第 58 页的“箍筋直径”相关表格。
- 卡片 2： 展示《2023某项目施工方案.docx》的第 12 页。
底部 - 相关搜索（Related）：
- “抗震等级 8 级对应的混凝土强度等级是多少？”
- “箍筋加密区的长度怎么计算？”

价值点： 将“问答”变成了“循证研究”，极大地增强了专业场景下的信任感。

2. 功能实现链条 (Implementation Chain)

AI Search 的后端逻辑与 Chat 类似，但 Prompt 的侧重点和后处理（Post-processing） 完全不同。

步骤一：高精度检索 (High-Recall Retrieval)

输入： 用户查询“抗震要求”。
动作： 系统执行混合检索（Hybrid Search），同时利用关键词匹配（保证精确）和向量匹配（保证语义）。
重排序 (Reranking)： 这一步在 AI Search 中至关重要。系统会调用 Rerank 模型，对前 50 个结果进行打分，选出最靠谱的 Top-N。

步骤二：结构化生成 (Structured Generation)

Prompt 注入： 系统发给 LLM 的指令会特别严格：

“你是一个严谨的研究助手。请基于以下片段回答问题。必须在引用的事实后加上 [index] 格式的引用标记。如果文中未提及，严禁编造。回答要客观、罗列要点。”
生成： LLM 输出带有 [1]、[2] 标记的文本。

步骤三：元数据关联 (Metadata Mapping)

动作： 系统解析 LLM 生成的答案，提取出 [1]。
回溯： 系统找到第 1 号切片对应的 原始文件 ID、页码、缩略图路径。
组装： 将这些信息打包成前端可渲染的 JSON 对象（用于展示那些漂亮的卡片）。

步骤四：相关问题生成 (Query Suggestion)

并行任务： 在生成答案的同时（或之后），系统会发起第二次轻量级 LLM 调用。
Prompt： “基于用户的问题‘抗震要求’和刚才的回答，用户下一步最可能问哪 3 个问题？”
输出： 生成“相关推荐”列表。

步骤五：前端渲染 (UI Rendering)

展示： 前端界面不再是气泡式的对话框，而是类似 Google 搜索结果页的布局：答案置顶 + 证据卡片平铺 + 延伸阅读。

总结：AI Search vs Start Chat

维度	Start Chat (聊天模式)	AI Search (搜索模式)
界面风格	WhatsApp / 微信风格	Google / Perplexity 风格
侧重点	多轮交互、上下文连贯、拟人化	单次查询、信息密度、证据展示
引用展示	通常只是文末的一个小链接	图文并茂的卡片、强化的行内角标
典型用户	客服咨询者、闲聊用户	律师、合规官、研究员、技术人员

AI Search 是 RAGFlow 对标现代 AI 搜索引擎（如 Perplexity）的一种交互形态，更适合严肃的知识检索场景。

这段文字介绍的是 RAGFlow 最强大的核心功能之一：“Agent（智能体 / 工作流编排）”。

简单来说，这是一个 “低代码工作流编辑器”。

在此之前，RAGFlow 的功能（如聊天、搜索）都是官方定死的流程（输入->检索->回答）。
而 Agent 功能允许你像搭积木或画流程图一样，自己设计 AI 的思考和行动路径。你可以让 AI 先上网搜一下，再查本地文档，如果没查到就翻译成英文再查一遍，最后写成邮件。

如果说标准 Chat 是 “自动售货机”（投币->出货），那么 Agent 就是 “乐高积木”（你想搭成什么样，就能搭成什么样）。

1. 核心功能与实例说明

痛点：线性流程的僵化

标准 RAG 流程是直线的。但现实任务往往需要逻辑判断和工具调用。
比如用户问：“帮我查一下今天北京的天气，并根据我的公司差旅规定，告诉我能不能订头等舱去北京。”

普通 RAG： 只会去查“差旅规定”，它不知道“今天北京天气”，也无法把两者结合。

场景实例：智能差旅审批助手

你可以在 RAGFlow 的 Agent 界面拖拽出以下流程节点，构建一个复杂的助手：

流程设计：

开始节点 (Start)： 接收用户输入 “北京今天暴雨，我可以订头等舱吗？”
分类节点 (Categorize - LLM判定)：
- 让 LLM 判断用户意图。
- 路径 A： 询问天气 -> 走节点 3。
- 路径 B： 询问政策 -> 走节点 4。
- 路径 C (混合)： 复杂查询 -> 走节点 3 和 4。
工具节点 (Tool - Google Search)： 调用搜索引擎查询“北京今天天气”。
- 输出： “北京今日特大暴雨，航班大面积延误。”
检索节点 (Knowledge Retrieval)： 在《公司差旅报销制度》知识库中检索。
- 输出： “…一般员工仅限经济舱。但在恶劣天气导致航班延误或紧急公务情况下，经特批可乘坐头等舱…”
生成节点 (Generate - LLM)：
- 输入： 把节点 3 的天气结果 + 节点 4 的政策结果，一起喂给 LLM。
- 提示词： “结合天气情况和公司政策回答用户。”
最终回答： “根据查询，今天北京有特大暴雨。虽然公司规定通常只能订经济舱，但根据制度第 5 条，在恶劣天气下您可以申请特批预订头等舱。”

价值点： 将单一的问答，变成了具备“感知（查天气）”、“记忆（查文档）”和“逻辑（判断条件）”的复杂任务执行系统。

2. 功能实现链条 (Implementation Chain)

Agent 的背后是一个 DAG（有向无环图）执行引擎。

步骤一：图谱构建 (Graph Definition)

前端交互： 用户在 Canvas（画布）上拖拽组件（节点），并用线（边）连接它们。

数据结构： 系统生成一份 JSON 配置文件，描述节点关系。

{
  "nodes": [
    {"id": "node_1", "type": "retrieval", "config": {...}},
    {"id": "node_2", "type": "tool", "tool_name": "weather_api"}
  ],
  "edges": [
    {"source": "node_1", "target": "node_2"}
  ]
}

步骤二：拓扑排序与解析 (Topological Sort)

动作： 当用户发送消息时，后端引擎读取 JSON。
逻辑： 引擎计算执行顺序。它必须确保“前置节点”执行完，拿到数据了，才能执行“后置节点”。
- 例如： 必须先执行“搜索天气”，拿到结果后，才能执行“生成回答”。

步骤三：状态流转与变量传递 (State Management)

这是最关键的一步。

动作： 节点 A 的输出（Output） 会变成节点 B 的输入（Input）。
机制： 系统维护一个上下文词典（Context Dictionary）。
- 节点 3 跑完，字典里写入：{"weather_info": "暴雨"}。
- 节点 5 开始跑，它配置了读取 weather_info，于是系统把“暴雨”填入它的 Prompt 中。

步骤四：组件执行 (Component Execution)

RAGFlow 内置了多种类型的执行器（Operators）：

LLM Operator： 调用大模型进行对话或分类。
Retrieval Operator： 去向量数据库查资料。
Tool Operator： 调用外部 API（如 Google Search, PubMed, 计算器）。
Logic Operator： 像编程一样处理 If-Else 或 Switch 分支。

3. Agent 与普通 Chat 的核心区别

维度	普通 Chat	Agent (智能体)
形态	黑盒 (Black Box)	白盒/流程图 (White Box / Flowchart)
能力上限	只能做“检索+回答”	无上限 (可以联网、算数、写代码、多步推理)
容错率	如果检索不到就瞎编	可以设计“检索不到就换个关键词重试”的逻辑
适用人群	普通用户	想要深度定制业务逻辑的开发者/超级用户