RAGFlow 2 - 技术栈

这段文字介绍的是 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。

json 复制代码

{
  "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)

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

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

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

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