《Rag Agent，迭代史》系列已完成4次迭代，概要如下：

V1版本

• 内容：通过Dify平台，搭建入门智能体，包含：知识库（配置一律默认），智能体简易配置。
• 结果：能跑通。
• 问题：回答质量低，根源在于召回内容语义不完整。

V2版本（切换至COZE平台）

• 内容：将上传文章进行Q&A Pairs转换，保证每对Q&A语义完整。
• 结果：较V1版本，内容具备语义完整性。
• 问题：回答缺乏广度与深度。因“Q&A Pairs转换”在保证语义完整的同时，造成了严重的信息丢失。

V3版本

• 内容：舍弃V2版本"Q&A Pairs转换"路线，知识库尝试父子层级切分（索引和上下文分离）。
• 结果：较V2版本，内容广度和深度有所提升。
• 问题：提示词中的固定模板导致答案结构僵化，逻辑流畅性不足。

V4版本

• 内容：先对召回内容（这里指父级内容）进行预处理，提取自由主题，让LLM参考自由主题和召回内容先形成结构性大纲，再输出内容。
• 结果：较V3版本，内容的结构性/逻辑流畅性在感官上明显提升。
• 问题：出现答非所问。根因是检索阶段存在内容召回不全或不准确的问题。

前4个版本的迭代主要依赖主观直觉与定性观察。然而，在规划V5时，过多的可能性使得 “选择迭代方向” 本身成为了瓶颈。这引出了一个根本性原则：

No measure, no management!

因此，建立量化的评估体系，定义明确的迭代目标与关键指标，是突破瓶颈的首要路径。 本文即围绕该体系展开，主要内容包括：

• 整体评估框架
• 黄金评估集介绍及构建
• 各类评估器的Prompt

一、整体评估框架

本文将 RAG Agent链路解耦为：

user_query -> Retrieval（检索召回） -> LLM_Generation（大模型生成）-> answer

在这个链路中：

• user_query： 用户问题
• Retrieval： 检索召回，通过用户问题检索召回上下文（contexts）,给LLM提供内容参考。
• LLM_Generation： 大模型内容生成，根据参考内容和Prompt，生成内容。
• answser： Agent最终输出答案。

基于该链路，建立评估框架：

1.1 答案正确性-整体评估(User_Query->Answer)

我们首先需回答：究竟在迭代什么？我们在乎Rag Agent的什么能力？

当然是衡量 Agent 回答用户问题时是否正确。

答案正确性

• 定义：Agent 的最终回答是否在事实层面与专家撰写的标准答案 (Ground Truth Answer) 一致。注：Ground Truth后文简称为GT
• 计算方式：LLM-as-a-Judge。利用更强模型（如DeepSeek-V3）对比 Agent Answer 与 GT Answer。
• 评分标准：
  • 最高分：事实完全一致，关键信息无遗漏。
  • ……
  • 最低分：事实矛盾（一本正经胡说八道）或关键信息缺失。
• 实践意义：这是迭代的最终评判标准，无论采取何种迭代方向，如果正确性得分低，说明在做“无用功”。

1.2 Retrieval阶段

在此阶段，衡量的是召回内容质量，需要对比实际召回的上下文 与 专家标记的充分且必要 的上下文。

[!NOTE]

充分且必要
指生成标准答案所需的最小上下文集合。

字典解释

• ID：指召回的每条上下文都具备唯一识别ID，IDs则指上下文的ID集合。
• Retrieved_Contexts_IDs ：指用户询问后，Retrieval阶段实际召回的上下文ID集合。
• GT_Contexts_IDs： 指专家根据问题标记的最小上下文ID集合，该集合能构成标准答案。

1.2.1 召回率 ( Context Recall )

该指标决定了系统的能力天花板。

• 定义：专家认为回答问题必需的那些上下文集合，检索系统找全了吗？
• 计算公式：$${\displaystyle \mathrm{Recall}=\frac{|\mathtt{RetrievedContextsIDs}\cap \mathtt{GTContextsIDs}|}{|\mathtt{GTContextsIDs}|}}$$
• 公式详解：
  • 针对每一个问题，都需要专家标注充分且必要的上下文ID集合（GT_Contexts_IDs）。
  • 将问题送入Agent中，Retieval阶段得到实际召回的Contexts集合（Retrieved_Contexts_IDs ）。
  • 取GT_Contexts_IDs 和 Retrieved_Contexts_IDs 的交集，获取其数量，再除以GT_Contexts_IDs的数量，则得到召回率。
• 实践意义：
  • 召回内容诊断： 如果 Recall 很低，说明 LLM 根本没有获得足够的原材料，这是导致“答非所问”的根本原因。
  • 迭代方向： 想办法提高Recall，如：优化 Embedding 模型、优化切分粒度、优化检索召回策略、增大 Top-K、降低召回阈值、引入NER、优化Rerank等等。

1.2.2 准确率（ Context Precision ）

变相表示LLM生成时所参考内容的信噪比。

• 定义：Retrieval阶段检索回来的 Top-K 上下文集合中，有多少是真正有用的？
• 计算公式：$${\displaystyle \text{Precision}=\frac{|\text{ RetrievedContextsIDs }\cap \text{ GTContextsIDs }|}{|\text{ RetrievedContextsIDs }|}}$$
• 公式详解：
  • 取GT_Contexts_IDs 和 Retrieved_Contexts_IDs 的交集，获取其数量，再除以Retrieved_Contexts_IDs 的数量，则得到准确率。
• 实践意义：
  • 召回内容诊断： Precision 低意味着检索结果中充斥着大量噪音。这不仅浪费 Token 成本，更会诱导 LLM 产生幻觉（因为 LLM 很难忽略看似相关实则错误的干扰信息）。
  • 迭代方向：想办法提高Precision，过滤掉不必要的召回上下文，包括：元数据过滤、增高召回阈值、混合检索、优化Rerank等.

1.2.3 平均倒数排名 (Mean-RR)

衡量Retrieval阶段对召回上下列表的排序能力与对 LLM 的“注意力引导”效果。

• 定义：在召回上下文的列表中，第一个正确（属于 GT_Contexts_IDs ）的上下文是不是排在最前面？
• 计算公式：$${\displaystyle \text{RR}=\frac{1}{\text{Rank of First Relevant Context In RetrievedContextsIDs}}}$$
• 公式详解：
  • 针对每一个问题，检查 Retrieved_Contexts_IDs 列表（有序）。
  • 找到列表中第一个出现在 GT_Contexts_IDs 中的文档，记录其排名位置（Rank）。
  • 计算该问题的得分 $\frac{1}{\text{Rank}}$（例如：排第1得1分，排第2得0.5分，没找到得0分）。
  • 将所有问题的得分加总后取平均值，即为 MRR。
• 实践意义：
  • 召回内容诊断： MRR 低说明正确答案虽然被召回了，但被埋没在列表的中间或尾部。由于 LLM 存在 “迷失中间 (Lost in the Middle)” 效应和 “首因效应”，排在靠后的正确信息很容易被 LLM 忽略或权重降低，导致回答质量下降。
  • 迭代方向： 核心是优化排序逻辑，确保最相关的文档“置顶”。包括：引入重排序模型 (Re-ranker)（这是提升 MRR 最有效的手段）、微调 Embedding 模型、调整混合检索中关键词与向量的权重配比等。

1.3 LLM_Generation阶段

在此阶段，假设检索召回已经完成，我们将目光聚焦于 LLM 的“大脑”处理能力。评估的重点不再是“找没找到”，而是“读懂了没”以及“写得好不好”。

字典解释

• Retrieved_Contexts: 指Retrieval阶段实际召回的上下文内容，特指内容本身，不是ID。

1.3.1 答案有据性（Groundedness）

该指标是 RAG Agent的“防幻觉”底线。

• 定义：Agent 的回答是否严格基于召回上下文？生成的每一个原子事实（Atomic Fact）能否在召回上下文中找到证据支撑？
• 计算逻辑（LLM-as-a-Judge）：
  • 输入：Agent Answer vs Retrieved_Contexts
  • 逻辑：裁判 LLM 将回答拆解为独立的事实陈述，逐一在 Context 中寻找证据。
• 评分标准：
  • 最高分：所有信息均有出处，允许合理的总结与改写。
  • ……
  • 最低分：包含未知的外部信息，或与 Context 严重冲突。
• 实践意义：
  • 生成内容诊断：确保 Agent “知之为知之，不知为不知”。对于教程类 Agent，必须防止它在检索失败时，利用训练数据中的过时知识编造参数。
  • 迭代方向：若分数低，需修改 System Prompt，加强“仅基于上下文回答”、“严禁使用外部知识”的约束；或降低 LLM 的 Temperature 参数；或更换LLM等。

1.3.2 答案相关性（Relevance）

该指标衡量 Agent 是否“听懂了人话”以及“服务态度”。

• 定义：Agent 是否直接、有效地回应了用户的核心问题？
• 计算逻辑（LLM-as-a-Judge）：
  • 输入：Agent Answer vs User Query。注：此处特意不输入上下文，以保持变量隔离。
  • 逻辑：裁判 LLM 判断回答是否直击痛点，是否存在废话、复读机行为或答非所问。
• 评分标准：
  • 最高分：完美切题。
  • ……
  • 最低分： 答非所问，如V4版本遇到的问题。
• 实践意义：
  • 生成内容诊断：
    1. 若 相关性低：说明 LLM 指令遵循能力差，或者被 Prompt 中的无关信息带偏。
    2. 若 相关性低 但 有据性高：这是典型的”老实人办坏事”。说明检索到了错误信息，Agent 被迫“老实地”回答了错误的内容。此时锅在 Retrieval 阶段。
  • 迭代方向：优化 Prompt 中的任务指令（Instruction），明确回答风格；若属上述情况2，则需回溯优化召回率。

1.3.3 可选指标-信息组织力（Organization）

该指标是 V4 版本的特色指标，用于衡量“结构化生成”策略的成效。

• 定义：Agent 是否成功利用“主题约束”，将碎片化的召回上下文有机融合，并果断舍弃了无关噪音？
• 计算逻辑（LLM-as-a-Judge）：
  • 输入：Agent Answer vs Retrieved_Contexts。
  • 逻辑：判断 Agent 是否构建了清晰的逻辑主线？是否舍弃了 Context 中的琐碎噪音？是否消除了“根据资料1显示…”这种机械拼接痕迹？
• 评分标准：
  • 最高分：深度融合/完美降噪/专家口吻。
  • ……
  • 中间分：机械拼接/流水账。
  • ……
  • 最低分：逻辑混乱。
• 实践意义：
  • 生成内容诊断：这是区分“复读机”与“真正的专家助手”的关键。验证 V4 引入的 “自由主题提取 -> 结构化生成” 策略是否生效。
  • 迭代方向：若分数低，说明 LLM 仍倾向于机械摘录。需优化生成阶段的 Prompt，引入思维链（CoT），要求 LLM 先在内部构建大纲，再进行“专家口吻”的转述。

二、 黄金评估集

2.1 介绍

在整体评估框架中，会发现无论什么指标，都要求有 正确参考内容 作为对比，这些正确参考内容是黄金集条目的核心要素，主要包含3部分：

2.2 黄金集的构造原则

黄金集为评估服务，评估框架为迭代服务。

在此前提下，首先避免踩坑大坑，需指出黄金集条目不是越多越好，原因如下：

• 黄金集不是为了在大数据上抛出统计学显著性，而是快速诊断系统病灶。
• 黄金集更多是“困难样本的浓缩”，当样本过多时，分母变大，指标被稀释。
• 黄金集的更新维护成本较高，小规模的样本可确保人工校验的可行性。
• 迭代成本，小样本意味着评测成本低、速度快。

构建黄金评估集需要遵循以下原则：

覆盖度 > 质量 > 数量

2.2.1 覆盖度

覆盖度并非指题目要穷尽所有的业务知识点，而是指黄金集中的 GT_Contexts（标准上下文）必须覆盖不同的检索场景。

在对检索场景分类前，先介绍检索动作依赖性，大致分为单跳类型和多跳类型。

• 单跳类型：指检索召回模块通过用户输入，仅需进行一次并行检索动作，即可在结果集中找齐所需信息，上下文之间是并列关系（B上下文不需要通过A上下文中的线索得到），图示如下：
  
• 多跳类型：指检索召回模块无法通过初始输入一次性找齐答案。它需要多次检索，且后续的检索动作依赖于前一次检索到的内容（线索）。上下文之间存在链式或因果关系（A $\to$ B），图示如下：
  

结合检索动作依赖性 & GT_Contexts在文档的位置分布情况，就可以得到4类检索场景。

2.2.2 质量

质量是黄金集的生命线。高质量的标注必须遵循 “最小完备集” 原则。即：专家标注的 GT_Contexts 对于回答该问题而言，必须是充分且必要的。

充分性—— “缺一不可”
– 定义：集合必须包含回答问题所需的所有信息片段。
– 违规后果：若漏标关键Contexts，检索没找回来也不扣分，但生成阶段 LLM 却因缺信息而瞎编（导致 Recall 虚高，幻觉增加）。

必要性 —— “多一不可”
– 定义：集合中不应包含任何对回答问题无实质帮助的冗余片段。
– 违规后果：若多标了无关Contexts，Agent 没找回来（这是对的）却被扣了召回分（导致 Recall 虚低，误杀好模型）。

验收标准：专家在审核时需自问：“如果我不给 LLM 看这个 Context，它还能答对吗？”如果不影响作答，则该 Context不应被标记为 GT。

2.2.3 数量

在 RAG 的迭代开发期，遵循 “精简原则”。

• 推荐规模：50 条以内 （tips：作者首次实践时，只构建了10条）
• 动态维护策略：
  • 拒绝题海战术：保持小规模数据集，确保专家可在短时间内完成一轮人工校验，保证评估的可持续性。
  • 末位淘汰制：黄金集应是“动态错题本”。当某个 Type A 类问题在连续N个版本中得分均为满分，说明系统已完全掌握，应将其移出黄金集（转入回归测试库），并补充新的 Type C/D 类“难题”进来。
  • 保持敏感度：始终维持黄金集的高难度与高敏感度，确保每一次代码微调（如修改 Prompt 或 重排序权重）都能在分数上得到直观反馈。

2.3 黄金集构建实操SOP

面对海量文档，纯人工构建耗时耗力。为了在质量与效率之间取得平衡，推荐采用 AI 辅助 + 专家裁决的流水线模式。

Step 1：定向提问

利用 LLM 遍历知识库，针对性地生成覆盖 A/B/C/D 四类场景的问题。

• 操作技巧：不要让 LLM 泛泛而谈。需在 Prompt 中明确要求：“请根据文档生成一个需要跨段落总结的问题（B类）”或“请生成一个多跳推理问题（D类）”。
• 输入：知识库文档片段。
• Prompt：见文末附录。
• 产出：候选问题列表。

Step 2：专家标记上下文

这是构建过程中唯一不可省略的人工环节，也是确立“真理”的过程。

• 操作：开发者审视候选问题，利用搜索工具在知识库中检索，人工筛选出 GT_Context_IDs。
• 执行标准：严格执行“最小完备集”原则。
  • 自问 1：“为了答对这道题，必须看这段话吗？” -> 若否，剔除。
  • 自问 2：“只看这两段话，逻辑链条断了吗？” -> 若断，补录。
• 产出：User_Query + GT_Context_IDs。

Step 3：有机融合生成答案

有了精准的上下文，我们不需要人工手写几百字的标准答案，而是让 LLM 代劳。

• 策略：使用 “有机融合 Prompt”。要求 LLM 扮演专家，基于 GT_Context_IDs 进行逻辑重组，生成一篇结构严密、丝滑的“满分作文”。
• Prompt：见文末附录。
• 产出：GT_Answer。

Step 4：快速验收

专家只需快速人工扫视生成的 GT_Answer,同时也可以让LLM代劳。

• 检查点：逻辑是否通顺？是否存在明显幻觉（使用了素材外的信息）？
• 耗时：熟练后，每条数据的验收时间可控制在 1-2 分钟。
• Prompt：当然，也能利用LLM进行答案审核，Promp放在文末附录。

三、结语

回顾《Rag Agent，迭代史》，V1 到 V4 是“功能”的累积，而评估框架的诞生，则是“工程”的觉醒。

评估不是终点，而是新迭代的起点。带着这套量化体系，让我们在后续版本中，用数据驱动每一次优化，通过实操去挑战 RAG 的能力上限。

附录

Agent_Answer有据性评估Prompt

# Role
你是一位专门检测 AI 幻觉的审计员。你的任务是判断“模型回答”中的每一条信息是否都有“参考资料”作为支撑。

# Input Data
## **参考资料 (Retrieved Context)**:
{{context}}

## **模型回答 (Model Answer)**:
{{actual_output}}

# Evaluation Steps (评估步骤)
1. 将“模型回答”拆解为独立的陈述句。
2. 逐一检查每一条陈述句：
   - 它是否能在“参考资料”中找到明确证据？
   - 或者它是否是基于“参考资料”的合理推断（不矛盾）？
3. 检查是否存在“参考资料”中未提及的外部知识（除非是普适常识）。

# Scoring Rubric (评分标准 1-5)
- **5分 (完全忠实)**：回答中的所有事实、数据、逻辑都严格源自参考资料。回答是对资料的有机重组，没有添加任何未授权的信息。
- **4分 (基本忠实)**：回答基于参考资料，但包含了极少量的、无害的连接词或背景修饰，不影响事实准确性。
- **3分 (部分幻觉)**：回答的主要内容基于资料，但夹杂了资料中未提及的具体细节（如编造了具体的参数值或步骤）。
- **2分 (严重幻觉)**：回答中包含大量资料中不存在的信息，或者通过外部知识回答了资料中没提到的问题。
- **1分 (完全矛盾)**：回答的内容与参考资料直接冲突，或者是完全的瞎编。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短指出哪一句话或者是哪个参数在参考资料中找不到依据>"
}

Agent_Answer相关性评估Prompt

# Role
你是一位严格的考官。你的任务是评估考生的回答是否**直接、完整**地回应了考题，而不关心回答的事实是否正确。

# Input Data
## **用户问题 (User Question)**:
{{input}}

## **模型回答 (Model Answer)**:
{{actual_output}}

# Evaluation Criteria (评估标准)
请关注回答的**针对性**。
- 回答是否正面解决了用户的疑问？
- 回答是否提供了有用的信息，还是在说废话？
- **注意**：即使回答包含事实错误（幻觉），只要它是在尝试回答这个问题，相关性分数也可以很高。

# Scoring Rubric (评分标准 1-5)
- **5分 (完美相关)**：回答直击痛点，完整覆盖了问题的所有意图。无冗余废话。
- **4分 (高度相关)**：回答了核心问题，但可能包含少量不必要的啰嗦，或者遗漏了次要的追问。
- **3分 (一般)**：回答沾边，但不够直接。例如：用户问“怎么做”，回答却在解释“是什么”。或者回答过于宽泛。
- **2分 (低相关)**：回答了相关的话题，但没有解决具体问题。例如：复述了一遍问题中的关键词，但没给出结论。
- **1分 (不相关)**：完全答非所问，或者像复读机一样重复问题，或者回答了完全不同的问题。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短评价回答是否直接解决了问题>"
}

Agent_Answer信息组织力评估Prompt

# Role
你是一位资深的信息架构师和编辑。你的任务是评估 AI 是否成功地将**碎片化的【上下文】**重构成**结构化的成品**。

# Input Data
## **用户问题**: 
{{这里填写用户问题}}


## **上下文 (Context)**: 
*(注意：这里面可能包含很多零碎、重复、甚至与核心主题无关的噪音信息，其中topics代表了内容主题)*

{{这里填写召回的上下文}}


# **模型回答 (Model Answer)**: 
{{actual_output}}

# Evaluation Goal
请判断：模型是否成功应用了“主题约束”策略？即：它是否从碎片中提取了逻辑主线，并**果断舍弃**了那些无法串联的零碎信息？

# Evaluation Criteria (评分标准 1-5)

- **5分 (卓越的重构)**：
    - **极强的逻辑主线**：回答围绕核心主题展开，结构严密（如：总分总、对比结构）。
    - **完美的降噪**：上下文中那些琐碎的、无法融入主题的孤立句子被完全过滤掉了。
    - **有机串联**：引用的上下文片段被“消化”后重新组织，看不到拼接痕迹。

- **4分 (良好的重构)**：
    - 有明显的主题结构。
    - 舍弃了大部分噪音，但可能保留了个别突兀的细节。
    - 语句通顺。

- **3分 (机械拼接 - 你的痛点)**：
    - **流水账**：虽然回答了问题，但感觉是把上下文里的信息按顺序翻译了一遍。
    - **未过滤噪音**：上下文里提到的一些无关琐事（比如无关的参数定义）也被强行塞进了回答里。
    - **缺乏主线**：没有清晰的“自由主题”感。

- **2分 (逻辑混乱)**：
    - 试图结构化但失败了，导致逻辑断层。
    - 或者强行把不相关的信息硬凑在一起。

- **1分 (失败)**：
    - 直接复制粘贴上下文原文。
    - 或者完全脱离上下文自己瞎编。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短评价回答是否直接解决了问题>"
}

黄金集构建_提问Prompt

# Role
你是一位 RAG 系统测试专家，专门负责构建高难度的“黄金评估集”。你需要深入理解提供的技术文档，并站在小白用户、进阶用户和故障排查者的角度，设计出能全面考察检索系统能力的测试题。

# Taxonomy: 检索场景分类矩阵
请严格按照以下四种难度类型生成问题，确保问题集具备充分的覆盖度：

1.  **Type A (单跳-单点)**:
    * **定义**: 答案仅位于文档中的某一个具体段落，只需精准匹配。
    * **特征**: 询问具体的参数值、定义、报错含义。
    * **例题**: "Flux.1 Dev 版本的显存推荐值是多少？"

2.  **Type B (单跳-离散)**:
    * **定义**: 答案分散在同一文档的开头、中间或结尾，需要进行长文总结。
    * **特征**: 询问“所有...”、“流程步骤”、“包含哪些...”。
    * **例题**: "总结一下文中提到的所有 ControlNet 预处理器名称。"

3.  **Type C (跨文档-对比/融合)**:
    * **定义**: 答案需要结合文档中两个不同主题的部分（甚至跨文档）进行对比或综合。
    * **特征**: 询问“区别是什么”、“优缺点对比”、“共同点”。
    * **例题**: "对比一下文中提到的 IPAdapter 和 ControlNet 在控图原理上的主要区别。"

4.  **Type D (多跳-推理)**:
    * **定义**: 答案无法直接找到，需要先找到线索 A，再根据线索 A 找到答案 B。
    * **特征**: 问题中包含间接引用的实体，或询问“如何配置 X 对应的 Y”。
    * **例题**: "我要加载文中提到的那个 T5 文本编码器，在 ComfyUI 加载节点里应该填哪个文件名？" (需先查 T5 对应的文件名，再回答)。

# Task
阅读提供的参考文档，生成 **5-8 个** 测试问题。

# Requirements
1.  **覆盖度强制**: 输出必须尽可能覆盖 A、B、C、D 四种类型。如果文档内容不足以生成 C 或 D 类，请尝试基于文档逻辑挖掘最接近的问题。
2.  **拟人化**: 问题必须模拟真实用户的提问口吻，不要过于书面化。
3.  **自证**: 对每个生成的问题，必须标注其所属类型，并简述“解题路径”。

# Input Data (参考文档)
{{document_content}}

# Output Format
请严格按以下 JSON 格式输出：
[
  {
    "question": "生成的问题文本",
    "type": "Type A / B / C / D",
    "reasoning": "简述为什么属于这个类型（例如：需要结合第1段和第5段的内容）",
    "source_clue": "答案对应的关键词或原文片段"
  },
  ...
]  

黄金集构建_生成标准答案Prompt

 # Role
你是一位 ComfyUI 领域的资深技术专家，擅长将碎片化的技术文档融合成逻辑严密、通俗易懂的教程答案。

# Input Data
## 1. 用户问题 (User Question):
{用户问题}

## 2. 预提取的核心主题 (Pre-extracted Themes):
{你预处理好的主题列表}
*(注：这些主题仅作为你的“导航线索”，帮助你组织逻辑。)*

## 3. 参考资料 (Raw Contexts):
{粘贴 gt_contexts 对应的原始文本}
*(注：这是你生成答案的唯一事实来源。)*

# Task Instructions
请执行以下 **“有机融合” (Organic Fusion)** 的生成过程：

## Step 1: 语义映射与结构规划 (Internal Thought)
* **审查主题**：查看预提取的“核心主题”，在“参考资料”中寻找对应的事实细节。
* **过滤空洞**：如果某个主题在参考资料中没有实质性内容支撑，请果断**舍弃**该主题，或将其**合并**到其他点中。**不要为了凑骨架而强行描写。**
* **构建逻辑流**：根据资料的丰富程度，动态调整回答的结构（是先讲原理，还是先讲操作？是对比叙述，还是分步叙述？）。

## Step 2: 融合生成 (Synthesis Generation)
基于 Step 1 的规划，撰写最终的标准答案。
* **有机串联**：不要机械地按“主题1、主题2”罗列。请使用过渡句，将各个知识点串联成一篇连贯的短文。
* **事实查核**：确保所有引用的参数、名称、逻辑都严格源自“参考资料”。
* **风格要求**：保持“专家教学”的口吻，清晰、丝滑、有见地。

# Output
请直接输出 **最终的标准答案** (Markdown格式)。
*(不需要输出 Step 1 的思考过程，直接给我结果)*

黄金集构建_标准答案审核Prompt

# Role
你是一位严格的内容审计员。你的任务是检查一份由 AI 生成的“标准答案”是否合格。

# Input Data
## 1. 用户问题:**
{粘贴你的问题}

## 2. 原始参考资料 (Ground Truth Contexts):**
{粘贴你标记的contexts原文}

## 3. 待审核的答案 (Generated Answer):**
{粘贴标准答案}

# Audit Criteria (审核标准)
请检查“待审核的答案”是否满足以下条件：
1. **忠实性 (关键)**：答案中的所有事实是否都能在“参考资料”中找到依据？是否存在幻觉（编造资料中没有的信息）？
2. **完整性**：是否回答了“用户问题”的核心痛点？
3. **准确性**：是否存在逻辑错误或误导性描述？

# Output
请简要输出：
- **结果**：【通过】 或 【需修改】
- **理由**：(如果需修改，请指出具体哪一句话有问题)

Rag Agent，迭代史（五）：量化评估体系——从“感觉还行”到“数据说话”最先出现在0260。

随着WordPress内容增多，产生了多平台分发的需求，但原生WP编辑器的兼容性差（图片、排版），导致每次跨平台发布都需频繁调整格式，耗时费力。核心痛点在于：

如何实现一次写作，多平台格式兼容与统一图片资源引用？

基于以上痛点，本文将详细介绍分层解耦式的内容生产工作流，旨在通过Markdown纯文本和公有图床实现内容的统一管理与高效分发。内容涵盖：

• 内容生产工作流介绍
• 内容资源托管层（GitHub）
• 写作层（Obsidian）
• 发布层（PicGo/COS）及WordPress同步实操。

1. 内容生产工作流介绍

工作流框架介绍

2. 内容资产托管层实操指引（GitHub）

本次实操指引主要采用GitHub

2.1 GitHub介绍

2.2 GitHub快速配置指南

第一步： 注册登录GitHub

进入官网	注册/登录GitHub

第二步： 新建仓库

进入仓库	点击新建	填写仓库信息

第三步： 下载github desktop

第四步： 打开github desktop，登录GitHub账号，克隆之前创建的仓库并和本地文件夹绑定

至此，使用GitHub Desktop克隆仓库至本地文件夹，在指定文件夹中增删改查后，实现本地文件与远程仓库的快速commit和push同步。

如需更高级的版本管理操作，可查阅Git官方文档或在AI辅助下学习相关命令。

3. 写作层实操指引（Obsidian）

3.1 Obsidian介绍

Obsidian 是一款本地优先的知识管理和笔记软件。它基于纯文本 Markdown 文件格式存储数据，利用本地文件夹结构（称为“库”）来组织笔记。

核心特性：

• Markdown 原生：** 所有笔记都是标准的 Markdown 文件，这确保了极高的可移植性和长期可用性。
• 双向链接： 允许用户在笔记间建立联系，并可视化这些关系（如通过关系图谱 View），帮助用户构建一个相互连接的知识网络。
• 高度可定制： 通过丰富的插件系统和主题，用户可以根据需求将 Obsidian 配置成强大的写作工具、知识库或项目管理系统。

3.2 Obsidian简易指引

第一步： 下载安装Obsidian

第二步： Obsidian设置

按下图设置即可，由于在写作层中咱们要遵循markdown格式，需配置以下信息

• 链接路径应选择相对路径
• 链接禁止使用WikiLink方式，否则在拖拽或粘贴时会默认为WikiLink格式
• 建议将所有的媒体文件都单独放到一个文件夹中，比如下图中的_assets。
  

第三步： 媒体链接格式确认

确保链接格式的兼容性，写作层要求严格的Markdown。

Obsidian插件LinkConverter用于批量将已有的WikiLink格式转换为Markdown格式，

（可选项）LinkConverter插件安装

进入obsidian插件市场	安装启用LinkConverter插件	插件设置(相对路径)

LinkConverter使用

右键note，可以直接进行批量替换，如下图：

tips：若文章需要被知识库引用，建议给所有的图片链接加上ALT属性，默认为唵，可以利用linkconverter先全部转为WikiLink，再全部转为markdown链接，会自动添加ALT属性。

[!NOTE]

至此，便可以用Obsidian专注于写作。

重要的事情说三遍：
写作层要极度克制，克制是平台兼容的前提，遵循标准Markdown格式。
写作层要极度克制，克制是平台兼容的前提，遵循标准Markdown格式。
写作层要极度克制，克制是平台兼容的前提，遵循标准Markdown格式。

4. 发布层实操指引

4.1 创建原稿副本

发布层的任何操作都不建议在原稿中进行。

• 建立一个文件夹，用作于发布车间
• 对原稿进行副本创建，并将副本放入发布车间文件夹中(如下图)
  

4.2 图床实操指引

4.2.1 存储服务购买及设置

作者目前使用存储服务为：腾讯COS
大致介绍
主要作用：将本地存储的媒体文件上传到云端存储服务器中，再通过公网进行图片访问。
执行步骤
第一步： 点击前往腾讯COS官网购买COS资源包

前往腾讯COS官网_优惠界面	尝试：购买一个最便宜的资源包

第二步： 进入COS管理后台

进入腾讯云控制台	搜索COS或存储服务	进入COS管理后台

第三步： 创建存储桶

不用过多在意计费环节，第一次使用时若担心计费问题，就将所有计费选项都关闭。

创建存储桶1	创建存储桶2	创建存储桶3
注意：权限选择公有读私有写	标签输入即可	确认配置信息

（可选项）第四步： 存储桶其他配置
主要是域名设置和跨域访问设置

第五步： API密钥配置-新建子账户&授权

后台搜索API密钥	建议建一个子账号	授权配置

访问方式选择编程访问，授权范围选择COSFULLACCESS

第六步：API密钥获取

选择授权的账户	新建API密钥并保存

[!NOTE]

至此，图床服务搭建完毕，用户可直接在存储桶文件列表中手动操作，也可通过API进行编程交互。如果不懂如何通过API进行访问，不着急，介绍一款应用：Picgo，该应用已将API封装，方便将媒体文件与图床服务进行交互。

4.2.2 Picgo应用介绍及设置

介绍及下载链接

• PicGo 是一款开源的、跨平台的桌面应用程序，它的核心功能是快速地将图片上传到图床（图片存储服务器）并自动获取图片的在线链接。
• 下载Picgo

它能解决什么问题？

• 传统方式插入图片的流程是: 截图 -> 保存到本地 -> 打开图床网站 -> 登录 -> 上传 -> 复制链接 -> 插入到文档。这个过程非常繁琐。
• 使用 PicGo 后，流程简化为：截图 -> [快捷键上传] -> 链接已自动复制到剪贴板 -> 直接粘贴到文档。

核心优势：

• 高效快捷：支持拖拽上传、剪贴板上传，并配合快捷键，真正做到“一步到位”。
• 多图床支持：支持包括 GitHub、SM.MS、阿里云OSS、腾讯云COS、七牛云、Imgur等在内的多种图床。
• 链接格式丰富：上传后可自动生成 URL链接、Markdown格式、HTML格式等，满足不同场景需求。
• 跨平台：支持 Windows、macOS 和 Linux。
• 插件系统：通过安装插件，可以扩展更多功能（如：图片压缩、水印、上传前重命名等）。

Picgo设置
打开picgo应用，选择腾讯云COS，进行设置，如图：

配置详情：

配置项	描述
图床配置名	随意
COS版本	到本文发布时间为V5，可以直接问智能售后
SecreId	4.2.1中获取的密钥信息
SecretKey	4.2.1中获取的密钥信息
设定存储路径	存储桶的具体某个文件夹
其他必要参数如右图

Picgo试用

[!NOTE]

至此，便可以用Picgo高效地和图床服务进行交互，记得选Markdown链接格式。

4.2.3 媒体链接公有化

在4.2.1和4.2.2中，我们不仅有了云端图床服务，也具备了和图床服务交互的能力，接下来，便是对原稿副本进行媒体链接进行处理，简单来说：

将原稿副本中的媒体文件上传到图床服务中，生成公有URL后替换，达到跨平台展示的目的。

我们使用Obsidian插件 Image Auto Upload 配合 PicGo/COS 实现。

（必须） 插件_Image Auto Upload快速指南

第一步： Obsidian安装插件Image Auto Upload

第二步： Image Auto Upload设置

照着设置即可，强烈建议将自动上传和上传后删除关闭，我们只在发布时才进行链接替换，写作时使用文件本地路径。

第三步： 在原稿副本中进行链接替换

单媒体文件上传	文档所有文档上传CTRL+P

[!NOTE]

至此，原稿副本的媒体文件链接便处理完成，你可以在Picgo中查看，也可以在图床服务中查看。

4.3 内容渲染与同步（WordPress为例）

介绍如何使用Obsidian插件： WordPress。

4.3.1 安装发布到wordpress的插件

安装插件wordpress并启用	插件设置

4.3.2 获取WordPress的密钥

登录WordPress站点后台，安装插件orange mini api
按下图所示一直往下点，获得账号和密码

4.3.3 发布操作

配置API用户信息(XML-RPC TYPE)	配置yaml信息	发布到worpress(CTRL+P)

[!NOTE]

至此，发布层的内容全部结束

5. 总结

本文提出了一种解耦式写作工作流，旨在解决多平台分发时，因平台排版和图片兼容性差异导致的格式调整繁琐、耗时长的问题。该方案的核心理念是将内容创作（写作层）与格式适配/资源公有化（发布层）彻底分离，确保内容源头的单向流动性和原子级一致性。

Blog，分层解耦式知识生产工作流最先出现在0260。

在《Rag Agent，迭代史（三）》_V3版本的基础上为召回上下文增加topic(主题描述)元数据，即：通过对Chunk进行主题预抽取的方式，得到主题列表”，LLM基于主题列表先进行大纲制作再参考上下文进行回答，以此降低割裂感。

[!NOTE]

coze自带的知识库将作为简化的向量数据库，本版本及以后，知识库仅作为语义检索使用。

2. 执行步骤

第一步： 设计document表 → 设计chunks表 → 准备向量数据库(coze知识库)

设计document表	设计chunks表	准备向量数据库(coze知识库)
用于记录文章原始内容、重构化的内容及其元数据	文章语义分段后，将父层级单元（上下文）存入chunks表，并记录相应的元数据	用coze自带的表格类型知识库近似替代，文章语义分段后，将子层级单元（索引）存入该库，并记录元数据，此版本的元数据主要是指document_id和chunk_id，指向文章和chunks（上下文）。

第二步： 文章内容迁移 → 导入chunks内容 → 导入index向量索引表内容

文章内容导入	导入chunks内容	导入index向量索引表内容
将V3的文章内容导入到文章document表	即新增父层级单元内容，其会被作为上下文召回给到LLM	即新增子层级单元内容，其将会被作为向量检索的索引

第三步： 遍历提取每一段chunk的自由主题信息 → 主题归一化处理

遍历提取chunk的自由主题信息	主题归一化
先对每一段chunk进行自由主题信息的提取	基于提取的自由主题，进行归一化处理

第四步： 创建工作流-知识库检索 且 获取chunks（上下文）及其元数据(主题信息)

检索召回工作流图：知识库检索→获取chunks（上下文）及其元数据(主题信息)

第五步： Agent设置，提示词和工作流配置

Agent设置：提示词和工作流配置

第六步： 预览调试

预览调试1：纯文	预览调试2：回答带图

3 评估&问题分析

3.1 评估结论

核心功能已达预期：

基于上下文的“动态大纲生成”策略（先生成大纲，后生成内容）效果显著。它为LLM提供了清晰的生成脚手架，极大降低了回答内容的逻辑跳跃和“割裂感”，提升了阅读体验。

次要发现：

直接使用LLM生成的“自由主题”比“归一化主题”在生成大纲时表现更好。

• 自由主题包含的语义更为丰富。
• 个人认为归一化的主题信息适用于两个方向：1）一些严谨的领域不需要创意，比如法律、医疗等领域，可以使用归一化的主题生成大纲。2）归一化的主题信息可作为逻辑筛选条件，为程序处理提供便利。

3.2 关键问题

在评估中发现了一个比“答案结构”更底层的问题： 召回内容不准确或不全面。

具体表现为：系统经常召回与查询词高度相似的“干扰项”，反而过滤掉了措辞不同但包含正确答案的文档。

召回内容不准或不全

问题分析内容由AI生成

3.2.1 原因：相关性陷阱

你遇到的不是简单的数量问题，而是一个更深层、更棘手的“相关性陷阱” (Relevance Trap) 问题。这是所有RAG系统都会遇到的最经典、最痛苦的问题之一。

问题的核心是：向量相似度高的，不等于对用户最有用的。

系统召回了它认为“语义上最像”的内容，但这些内容可能是“正确的废话”或者“看似相关但答非所问”的干扰项，反而把那个措辞不同但真正能解决问题的答案给挤掉了。

为什么会掉入“相关性陷阱”？

让我们来诊断一下，为什么一个“特别像”的错误答案，其相似度得分会高于一个“不那么像”的正确答案。

1. “表面文本”的胜利 (Surface-level Textual Similarity)
   • 场景：用户问：“如何安装ComfyUI-Manager？”
   • 陷阱：知识库里有一篇写得很好的通用教程，标题是“新手必看：如何安装任何自定义节点”，里面用了大量“安装”、“节点”、“文件夹”等词汇。它的用词和用户的提问高度重合。
   • 被过滤掉的正确答案：另一篇专门讲ComfyUI-Manager的文档，可能标题是“Manager节点的进阶用法与故障排查”，它可能花了很多篇幅讲如何更新、解决冲突，只有一小部分讲安装。
   • 结果：对于Embedding模型来说，那个通用的、表面文字更匹配的教程，其向量相似度得分可能高达0.92，而真正有用的那篇，得分可能只有0.88。如果你设置了top_k=1或者阈值卡得很高，正确答案就被无情地过滤掉了。
2. 通用模型的“领域知识盲点” (Domain Knowledge Blind Spot)
   • 通用的Embedding模型是在海量互联网数据上训练的。它知道“安装”和“节点”是相关的，但它并不知道ComfyUI-Manager是一个极其特殊且重要的实体。它无法像你一样，给这个特定的名词赋予更高的权重。它只是把它当作一个普通的、由几个字母组成的词。

4. 改进方向

既然问题的本质是向量检索的内在缺陷（即“相关性陷阱”），那么改进必须围绕“提升召回的精准度”和“丰富召回的维度”来展开。

4.1方向一：优化Embedding策略

换模型，换向量维度。

• 换模型： 尝试更换为针对特定领域精调过的Embedding模型。
• 换维度： 调整向量维度，寻找更适合当前数据量和复杂度的表征空间。

4.2 方向二：提高召回率

此为“兜底”策略。承认第一阶段检索的局限性，通过扩大召回数量来保留正确答案进入下一阶段的机会。

• 扩大Top-K： 在Rerank（重排序）机制之前，将初步检索的top_k从（例如）3提升到15。
• 目标： 确保“不那么像但正确”的答案能有机会进入Rerank阶段，用更精细的Rerank模型将其打捞上来。

4.3 方向三：查询改写

既然知识库与用户查询（Query）的表述存在“鸿沟”，那么可以尝试改写Query来匹配知识库。

具体操作： 利用LLM将用户的单个原始问题，扩展或转义为多个具有不同表述、不同侧重点的子问题，然后进行多路检索并合并结果。

4.4 方向四：强化混合检索，引入NER

向量检索既然存在内在缺陷（”相关性陷阱”），那就引入事实检索策略进行互补和强化。

• 问题： 传统的“关键词检索 + 向量检索”通常以“或”逻辑简单合并，虽然提升了召回率，但引入的关键词噪音反而可能拉低语义的精准度。
• 方案升级： 引入NER作为高级的“事实检索”手段。

可以这样理解NER，可以对关键词检索进行升级，为每个检索目标预提取关键词，这个关键词主要表式实体概念，而这些实体概念与其他实体概念又能建立某种关系，比如从属、因果、使用、同义等，让检索目标与检索目标间接产生关联关系。这样就能按照实体关键词精确找到检索目标，又能按照实体关系，找到相关检索内容，丰富召回的上下文。

NER的核心价值（以下是AI回答内容）：

1. 绝对精确性与歧义消除 (Precision & Disambiguation)
   • 对比关键词： 关键词检索“model”会返回所有包含该字符串的文档。
   • NER方案： NER在预处理时就能识别出不同语境下的“model”，并打上结构化标签（如 entity: Checkpoint 或 entity: LoRA）。在检索时，系统可以根据查询上下文（如“加载一个SD1.5的model”）执行基于实体的精确过滤，只召回与 Checkpoint 相关的文档，从根本上消除歧义。
2. 赋能关系推理 (Relationship-based Reasoning)
   • 向量检索的局限： 面对“IPAdapter和ControlNet可以一起使用吗？”这类问题，向量检索最多只能找到同时包含这两个词的文档，但无法理解它们之间的关系（如是并联、串联还是冲突）。
   • NER方案： 在预处理时，NER识别出 IPAdapter 和 ControlNet 为两个节点实体，而关系提取 (RE) 进一步识别出它们之间存在 CONNECTS_TO（连接）或 CONFLICTS_WITH（冲突）的关系。
   • 查询革命： 检索查询因此可以从“模糊的文本相似度搜索”升级为“精确的图数据库查询”：“请找到那些同时包含 **IPAdapter** 和 **ControlNet** 实体，并且这两个实体之间存在 **CONNECTS_TO** 关系的知识单元。”

Rag Agent，迭代史（四）最先出现在0260。

本版本基于《Rag Agent，迭代史（二）》，暂时搁置“提炼要点→Q&A Pairs转换”的路线，采用改进方向二：索引与上下文分离，即：

尝试文章内容父子层级切分，子级单元作为索引，父级单元内容作为召回的上下文。

[!NOTE]

为快速实验效果，”索引+上下文分离”在coze中可以通过COZE的表格知识库近似实现，需将子级单元设为索引。

2. 执行步骤

第一步： 文章结构化处理→父子层级切分

文章_结构化处理	内容_父子层级切分
将原文处理层Markdown格式，并符合3级标题模式，实验暂定格式。	按三级标题的单元进行切分，并且每个三级标题单元指向对应的父级单元(二级标题单元）

第二步： coze中创建表格知识库→上传父子层级切分表格→设置索引

创建表格知识库	上传父子层级切分表格	设置表格知识库索引

第三步： 设置提示词和输出模板，预览调试

3 评估&问题分析

3.1 评估结论

核心功能已达预期：

对于基于现有知识的单次查询，系统的回答广度与内容还原度已达到预期标准(在整体感觉上)。

待评估范围

连续查询（多轮对话）与增量知识更新的功能模块，暂不纳入本次评估范围。

主要发现：

答案在内容上准确，但在结构上存在一种不协调感 ，未能形成逻辑流畅的整体。

3.2 关键问题

回答结构不协调，该问题的根源在于《Rag Agent，迭代史（二）》采用的“模板引导生成”策略与召回内容的非适配性。

3.2.1 原因：模板与内容的“错配”

该策略类似于一个固定的“食谱”（输出模板），它预设了答案应包含的特定“食材”（如概念定义、原理解释、实现方式等结构化信息）。

然而，当召回的上下文（即“食材”）本身不包含模板所要求的所有信息时，就会出现错配。例如：

若召回的父级Chunk未深入探讨“为什么”，而模板中却有“原理解释”这一项，LLM为了填充模板，可能会强行重复“是什么”的内容，或直接留白，从而导致最终答案内部逻辑断裂，结构不协调。

3.2.2 深层原因：固定模板的错误假设

更深层次的原因在于，固定模板策略基于一个核心假设：

我们预先了解该领域所有问题的典型回答模式。

这个假设在知识体系成熟的领域或许成立，但在快速发展或高度复杂的新兴领域中则难以维系。

本质上，任何固定的模板都是一种固化的视角，试图用单一视角去匹配多样化的知识内容，必然会导致部分场景下的结构性失配。

4. 主要改进方向

4.1 方向一：从“模板驱动”变为“内容驱动”

鉴于固定模板与召回内容之间存在“错配”风险，新方向的核心思想是：不再强制内容去适应模板，而是让内容本身来决定答案的结构。 这相当于从“按既定食谱备菜”转变为“根据现有食材动态设计菜谱”。

1. 第一步：主题发现
   • 操作： 对召回的上下文Chunk进行开放式主题分析。利用LLM的理解能力，让其在无预设偏见的情况下，自由地识别并描述该内容块的核心主题、信息类型或意图（例如，这是一个概念定义、一个操作步骤、一个原因分析等）。
   • 目的： 从内容本身，无偏见地“发现”其内在的逻辑主题。
2. 第二步：主题归一化
   • 操作： 第一步自由发现的主题可能存在表述多样化或语义重叠的问题（如“原理阐述”与“工作机制”）。本步骤旨在对这些原始主题进行聚类和标准化，将它们映射到一个预定义的、有限的规范主题集合中。
   • 目的： 消除主题的模糊性和冗余，为每个内容块生成一组干净、一致的标准化主题标签，为下游处理提供可靠的结构化输入。
3. 第三步：基于召会内容生成动态大纲
   • 操作： 汇总所有被召回Chunks的归一化主题，构建一个临时的回答大纲。
   • 目的： 生成一个即时的、为本次查询量身定制的回答结构或“脚手架”。这个动态大纲将作为最终Prompt的一部分，引导LLM组织语言，确保生成的答案既能全面反映召回内容，又具备逻辑连贯性，从根本上避免固定模板带来的结构失配问题。

Rag Agent，迭代史（三）最先出现在0260。

在《Rag Agent，迭代史（一）》_V1MVP版本的实践后，先采用改进方向一，即 加工内容源数据。

在知识入库前，对源数据进行预处理。通过格式化、标注或重构等手段，将原本松散的非结构化文本，加工成更结构化的、自包含的知识单元。

具体措施即将文章整理成独立的问答对（Q&A pairs）、带有元数据（Metadata）的段落、或功能完整的代码块。试着将文章变为问答对，让每个问答对相对来说语义完整。

重大调整：
由于云端dify没有自带的数据库，为了快速验证MVP，从V2版本开始切换到了COZE平台。

2. 执行步骤

**第一步：**新建数据库&设计表结构→存入文章内容

新建数据库 & 设计表结构	存入文章内容
表结构：：id，title，content，url，qa_pairs	先将文章原始内容导入，其他字段暂时为空

第二步： 先将文章进行要点提炼 → 围绕要点进行Q&A Pairs转换 → 存入知识库

文章要点提炼工作流	QA转换工作流	QA存入知识库

第三步： 调试预览

3. 评估&问题分析

3.1 评估结论

QA Pair的方式确实让召回内容每一个都语义完整，较V1版本有较大的提升，但整体回答离预期扔有较大距离。

3.2 关键问题1

问题的广度不够，即问题不全，不足以覆盖用户咨询场景。

问题分析内容由AI生成

3.2.1 原因一：LLM一次性处理造成的信息过载**

当我们给LLM一个指令，比如“请为这篇文章生成QA对”，我们其实是要求它在一次“思考”中，同时完成好几件复杂的事情：

• 阅读理解：通读并理解全文的每一个细节。
• 要点识别：在脑中标记出所有可能成为考点的重要信息。
• 问题构思：为每一个识别出的要点，构思出一个或多个好问题。
• 格式化输出：将所有构思好的QA对，按照要求的格式组织起来。

这就像让一个学生只读一遍课文，就立刻写出覆盖所有知识点的模拟试卷一样。模型会很自然地“走捷径”，它会优先处理那些最明显、最容易转化成问题的内容，而很多隐藏在段落深处、需要结合上下文才能提炼的知识点，就在这次“匆忙”的处理中被忽略了。

结果就是： 生成的问题只覆盖了文章的“主干”，而大量的“枝叶”被漏掉了。

3.2.2 原因二：中心议题的引力偏见

LLM在阅读文章时，会像我们人类一样，抓住文章的“中心思想”。文章中反复强调的核心概念、最长的章节，会对模型的“注意力”产生巨大的引力。

• 例如：一篇关于ComfyUI中KSampler节点的文章，可能花了80%的篇幅讲解sampler_name和scheduler这两个核心参数。而只用了一个小段落，提了一句“注意，如果图片模糊，可以尝试调整denoise参数”。
• 在这种情况下，一个简单的Prompt生成的10个问题里，可能有8个都是关于sampler_name和scheduler的，而那个对于用户排错至关重要的denoise知识点，很可能一个问题都不会生成。

结果就是： 问题的广度严重不足，过度集中在文章的“明星内容”上，忽略了那些同样重要但篇幅较少的“配角内容”。

3.2.3 原因三：缺乏“提问视角”

一个简单的Prompt，通常没有给LLM设定一个具体的“角色”或“视角”。因此，它会从一个非常中立、泛泛的角度来提问，但实际上，对于同一篇文章，不同的人会有完全不同的问题：

• 新手会问：“KSampler是什么？它在哪里可以找到？”
• 进阶用户会问：“euler和dpmpp_2m这两个scheduler有什么区别？哪种情况下用哪个更好？”
• 开发者会问： “KSampler节点的输入和输出分别是什么数据类型？我如何开发一个自定义的采样器？”

如果你不明确指令LLM从这些不同的视角出发去提问，它就只会生成那些最“安全”、最“平均”的问题，从而错失了大量有价值的、特定于用户意图的问题。

结果就是： 生成的问题缺乏层次感和多样性，无法覆盖不同深度和不同用户群体的需求。

3.3 关键问题2：

Q&A对的深度不够，主要提现在答案的深度不够，具体表现在过于精炼，“正确而无用”，不具备引导性

问题分析内容由AI生成

3.1.1 原因一：模型的“最小化提取”倾向

在RAG任务中，LLM的首要指令（无论是显式还是隐式）是“忠于原文”，以避免产生幻觉。为了“安全”地完成这个任务，模型会采取最保守的策略：直接从你提供的上下文中，找到并复述那个能够直接回答问题的句子。如：

• 问题Q：“在ComfyUI里，denoise参数是做什么用的？”
• 上下文Chunk：“…KSampler节点可以控制生成过程。其中，denoise参数控制了对原始潜空间图像的重绘程度，值为1代表完全重绘，值为0代表不做任何改变…”
• 模型生成的“精炼”答案A：“denoise参数控制了对原始潜空间图像的重绘程度。”

这个答案是100%正确的，也完全基于上下文。但它毫无“深度”和“引导性”可言。模型只是做了一个精准的“复制-粘贴”工作，因为它认为这是最安全、最直接地完成指令的方式。

3.3.2 原因二：全局上下文的丢失

这是导致深度不足的最核心、最隐蔽的原因。

V2版本虽然保证了召回内容的语义完整性，但本质上召回内容仍然是是文章的“碎片”，而不是“全貌”。

一个好的、有深度的答案，往往需要结合多个不同部分的信息：

• 定义：这个东西是什么？（可能在文章的第2段）
• 原因：为什么要用它？（可能在第4段）
• 影响：不正确地使用它会有什么后果？（可能在第7段的一个小提示里）

当只召回了与“定义”最相关的第2段作为上下文时，LLM根本就看不见第4段和第7段的内容。它无法“无中生有”，自然也就不可能提供关于“原因”和“后果”的引导性信息。它被我们自己提供的、过于聚焦的上下文给“限制”住了。

3.3.3 原因三：指令中的“引导性”要求过于模糊

在提示词中对LLM做出的回答约束目前非常抽象模糊，它不知道你所谓的“引导性”具体指什么。是指要提供代码示例？还是解释背后的原理？还是给出常见错误的排查方法？

当指令模糊时，模型就会退回它最擅长的“最小化提取”模式。

4. 主要改进方向

针对知识内容的的广度和深度问题，有两条核心改进路径：方向一旨在深度优化现有的“要点提炼→Q&A转换”工作流；方向二则探索一种全新的、基于“索引与上下文分离”的数据架构。

4.1 方向一：深化“要点提炼→Q&A转换”策略

提升回答内容的的广度，需解决以下问题：

优化措施如下

提升回答内容的深度，需解决以下问题：

优化措施如下

4.2 方向二：实施“索引与上下文分离”架构

此方向旨在从根本上解决“要点提炼”过程中的信息压缩与损失问题。该策略的核心是，承认任何形式的“提炼”都可能丢失未来查询所需的关键信息，而丢失的这部分信息不仅影响广度，同时也影响深度。

核心思想

此方向旨在从根本上解决“要点提炼”过程中的信息压缩与损失问题。该策略的核心是，承认任何形式的“提炼”都可能丢失未来查询所需的关键信息。

改进策略(和V1版本的方向二及方向三一致)

• 对原文进行结构化处理： 将原始文章改写为具有清晰父子层级的Markdown格式。在此结构中，父级单元（如一个完整章节或逻辑段落）因其语义完整性，被定义为“上下文块”**。**子级单元（如段落中的一个核心论点或一个标题）因其主题明确，被定义为“索引块”。
• 基于“索引块”进行切分： 用于知识库的检索匹配。
• 小块检索，大块召回： 当用户查询命中某个“索引块”时，系统不再返回这个小块本身，而是召回其所属的、语义更完整的父级“上下文块”，并将其提供给LLM。

通过这种方式，既保证了检索的精准度，又为LLM提供了生成高质量答案所需的完整语境，有望同时改善广度和深度问题。

Rag Agent，迭代史（二）最先出现在0260。

《Rag Agent，迭代史》系列是通过Rag Agent应用的不断迭代，探索总结Rag应用的方法论。

本文记录版本V1的迭代内容。

1. 版本内容

目标：
搭建一个简单的教程助手类的Agent，在ComfyUI For StableDiffusion领域为小伙伴提供入门指导。
工具选型：
在AI的建议下，在coze和dify中选择了dify。
基本框架：
越简单越好，知识库+智能体(能检索知识库召回内容)

V1版本整体框架图

2. 执行步骤

Learn By Doing ,直接开干，整个过程为3个步骤：

第一步： 在dify中创建知识库→上传文章→自动清洗&分块

创建知识库	上传文章	默认设置&自动分块
1）dify中创建知识库	2）上传文章	3）默认设置&自动分块

第二步： 创建一个项目，应用类型选智能体，配置提示词和关联知识库

创建项目-智能体	配置智能体
1）创建项目，类型为聊天助手	2）配置提示词，关联知识库，其他配置默认

第三步： 调试预览

调试预览

3. 评估&问题分析

3.1 评估结论

实践结果未达到预期。Agent未能按设想基于文档内容回答，输出质量有较大偏差。

3.2 关键问题1

答案质量低下：Agent的回答与原文内容“毫不相关”。其输出为通用、模糊的泛化知识，而非文章中的具体观点和逻辑，表明它并未有效利用提供的知识库。

问题分析

原因1：默认文本切分导致上下文“碎片化”

默认的切分策略通常基于固定长度（e.g., 每N个字符/Token一切），粗暴地将完整的句子、段落和逻辑链条从中间斩断。但是在检索知识库时，只会将有相关性的碎片内容召回，如下图所示，这些碎片内容不足以组成一个完整的概念阐述，LLM接收到该召回内容后，只能按照模型资深的逻辑进行回答。

从知识库中召回的chunks

0.0？思考

既然粗暴切分是问题的根源，那我们为什么一定要切分呢？直接将整篇文章作为上下文传给LLM，不是更完整、更准确吗？(以下内容为AI生成)

0.0！答案

这是一个非常自然且重要的问题。答案是，对文本进行切分并非一个可选的优化项，而是由当前技术和工程现实决定的必要步骤。主要原因有三点：

1. 技术限制：模型的上下文窗口 (Context Window)
   • 每个LLM都有一个“上下文窗口”的限制，即它一次性可以接收和处理的文本总量（以Token计算）。例如，GPT-3.5的窗口是4k或16k tokens，而一篇几万字的深度文章或一本几十万字的书，其Token数量会轻易超出这个上限。强行输入超长的文本会导致API直接报错。虽然现在有像Gemini 1.5 Pro这样支持超长上下文（1M tokens）的模型，但窗口限制依然是绝大多数应用需要考虑的边界条件。
2. 工程限制：成本与延迟 (Cost & Latency)
   • LLM服务的调用成本与输入的Token数量正相关。在每次提问时都将整篇长文作为上下文发送，会产生巨大的计算开销，使得应用成本高昂。
   • 同时，处理的文本越长，模型的响应时间也越长。这会严重影响用户体验，无法满足实时问答的需求。切分和检索的模式，确保了每次只向LLM发送少量、高度相关的上下文，从而在成本和速度上实现了工程可行性。
3. 效果限制：“大海捞针”问题 (Needle in a Haystack Problem)
   • 即使在上下文窗口允许的情况下，向模型输入过长的、包含大量无关信息的文本，也可能降低其回答的精确度。模型需要在庞大的信息“噪音”中找到关键的几句话（“大海捞针”），这本身就是一个挑战。研究表明，在超长上下文中，模型可能会出现“中间遗忘”现象，即对文本开头和结尾的信息记得更牢。
   • RAG中的“检索”步骤，本质上是一个高效的**“降噪”和“聚焦”**过程。它预先筛选出与问题最相关的几个知识片段，让LLM可以集中“注意力”在这些高质量信息上，从而生成更精准的答案。

因此，文本切分是不可避免的。我们的目标不是消除切分，而是找到一个办法，让每个切分的知识块都有相对全局的语义信息。

4. 主要改进方向

既然问题的核心在于召回采纳的上下文存在“语义孤立”，从而导致LLM无法有效利用，那么改进就应围绕提升上下文的语义完整性这一目标展开。主要探索以下三个方向：

方向一：加工内容源数据

• 在知识入库前，对源数据进行预处理。通过格式化、标注或重构等手段，将原本松散的非结构化文本，加工成更结构化的、自包含的知识单元。例如，整理成独立的问答对（Q&A pairs）、带有元数据（Metadata）的段落、或功能完整的代码块。

方向二：智能的切分策略

• 引入重叠缓冲 : 在相邻的文本块（Chunks）之间保留一部分重叠内容。这是一种简单有效的“缓冲”机制，能确保在切分边界处的关键信息不会被割裂。
• 利用语义边界 : 依据文本的内在结构进行切分，例如Markdown的标题层级、自然的段落、完整的句子，甚至是代码中的函数或类定义。这种方法尊重原文的逻辑结构，切分出的内容单元更为合理。

方向三：检索召回策略
任何切分策略都只能缓解而无法根除语义孤立问题。

• 索引与内容分离： 不再将检索到的小文本块直接作为最终上下文。而是将其视为“索引”或“指针”，用它来定位并召回一个更大的、包含更完整上下文的父级文档或段落。例如，先精准地检索到某个句子，再将该句子所在的整个段落提供给LLM。这种“小索引，大内容”（Small Chunk for search, Large Chunk for context）的模式，兼顾了检索的精确性和上下文的完整性。

Rag Agent，迭代史（一）最先出现在0260。

本文的作用是搭建第一个AI Agent。

一、平台选择

最后选择了Dify作为初步的学习工具。

选择过程很简单，直接问国内的deepseek

• Dify和Coze的各自特点和企业应用情况
• 若以提升职场竞争力为目标，初步选择哪个平台更好

1.1 平台基础对比

特性维度	Dify	Coze
核心定位	企业级AI应用开发平台	低代码/零代码AI应用搭建平台，侧重对话机器人和轻量级自动化
私有化部署	支持强大（社区版免费，企业版功能更全），适合对数据安全要求高的场景	开源版功能受限（插件、调试等缺失），且其商业版仅支持云端部署（字节火山引擎），数据不在本地
企业级特性	完善（RBAC权限、多租户、监控审计、知识库集成等）	开源版缺失（团队协作、权限管理、监控审计等工具较弱）
典型企业场景	多语言客服系统、智能助理平台、需深度定制的SaaS化AI服务、金融风控、医疗文档处理等	电商运营、内容创作、社交媒体机器人、轻量级客服机器人（尤其擅长抖音、飞书生态）
模型支持	丰富且灵活（支持100+主流模型，OneAPI协议动态切换）	较多，但生态绑定（国内版主推豆包、通义千问等，国际版支持GPT-4o等）
开发者生态与社区	非常活跃（GitHub stars 超10万，社区贡献活跃，文档完善，支持二次开发）	插件生态丰富（闭源版插件超3000个，但开源版目前仅18个内置插件，深度集成字节系生态）
学习与上手成本	中等学习曲线，1-2天掌握基本操作	上手速度非常快，几小时内可创建简单AI应用
企业市场反馈	服务全球150个国家用户，支撑超400万次应用部署；在大型企业、政府机构、金融医疗等合规要求高的领域认可度高	在中小型企业、初创公司、以及对数据安全不敏感的轻量级应用场景中更受欢迎

1.2 市场占有率和落地情况

• Dify：
  • 占有率特点：虽然绝对用户数量可能不如Coze（因为Coze上手门槛更低，吸引了大量个人和轻用户），但Dify在高价值企业客户中的渗透率和认可度非常高。
  • 落地行业：主要集中在金融科技（风控、投研、智能投顾）、软件与SaaS服务商（为客户集成AI能力）、教育科技、医疗健康（智能问诊、文档处理）、以及大型企业的内部知识管理和自动化平台。
  • 原因：这些行业对数据的私密性、系统的稳定性和可定制性要求极高，Dify的开源+私有化部署能力是它们的刚需。企业愿意为此支付更高的费用（企业版）并获得更深度的技术支持。
• Coze：
  • 占有率特点：凭借字节的流量和生态优势，Coze在用户数量和市场声量上非常庞大，尤其是在中小型企业、电商、新媒体运营、MCN机构等领域快速普及。
  • 落地场景：主要集中在智能客服（尤其抖音电商）、内容创作（自动生成文案、视频脚本）、社交媒体机器人（抖音、微信群助手）、以及飞书上的各种办公自动化小程序。
  • 原因：这些场景追求极致的上线速度和与现有生态（抖音、飞书、微信公众号）的无缝对接。Coze丰富的插件市场和模板市场正好满足了这一需求，让运营人员甚至无需技术背景也能快速搭建应用。

1.3 企业偏好

1.4 对你的职场竞争力的影响（经验移植性）

• 学习 Dify 的经验更偏向“底层”和“通用”：
  • 你积累的工作流设计、RAG优化、模型微调、API编排、私有化部署运维等经验，是高度可移植的。这些技能让你理解AI应用的核心架构，无论以后是用Dify、LangChain还是自己手写代码，这些概念都是相通的。
  • 这意味着你的经验更容易受到技术驱动型公司的认可，职业路径可以走向AI工程师、解决方案架构师等更核心的技术岗位。
• 学习 Coze 的经验更偏向“上层”和“生态”：
  • 你积累的插件使用、快速Prompt工程、多Agent社交编排、与字节系产品（抖音/飞书）的集成等经验，非常实用和高效。
  • 这些经验在特定的业务场景（运营、增长、电商）和特定的生态（字节系）内价值极高。你的职业路径可以走向AI产品经理、智能运营专家、业务赋能专家等岗位。

二、Hello，AI agent

• 本次选择云端部署，私有部署会遇到大量环境问题
• 进入dify官网，注册登录
• 创建Agent类型的应用

• 选择LLM供应商，此次采用的是通义千问，然后获取API Key。有点坑，最新的版本会报错，建议安装0.0.40版本。(可在右上角个人头像->设置->模型供应商中去选择配置)

• 提示词设定，测试，发布。搞定

最后

Hello，AI Agent最先出现在0260。

本文的目的：

• 阐述为何开启AI Agent领域的原因
• 制定MVP执行路径

一、为何开启AI Agent领域

1.1 AI Agent能提供职场竞争力

为啥，目前AI Agent在企业的落地方向有：

• 效率提升及自动化，这是目前最集中的方面，场景归类有：
  • 常见问题处理/信息查询通知等场景自动化。理解用户意图，调用内部知识库或API（如订单查询、物流跟踪），甚至能处理复杂的对话流程，并在必要时无缝转接给人工。显著降低响应等待成本。
  • 内部流程自动化，自动化执行重复性、规则明确的办公室任务，如数据录入、报告生成、邮件分类与回复，释放员工精力到更具创造性的工作中。大幅提升信息流转效率。
• 决策支持与数据洞察？策略输出
  • 通过访问公网数据（社交媒体、行业报告）等，自动洞察分析报告，实时监控市场动态、竞争对手情报和消费者情绪，为产品开发和市场策略提供数据驱动的依据。如：新产品上市前的市场调研Agent、舆情监控Agent。

• 创新业务与个性化服务
  • 原有业务过程中嵌入Agent提升服务效率或体验。企业助理，员工AI助理，用户小秘等概念。
  • AI Agent本身也是一种产品形态，可切入垂直领域，做业务创新。

1.2 探索一人成军的可能

作为人，受限于工具，不仅记忆、思维方式又或是解决能力，有很多事情都无法做成，而如果有机会一人成军，光是想象都兴奋。要达成这种目标，还需借助工具的力量，AI agent是一个不错的途径。

二、制定MVP执行路径

1. 选定AI Agent工具平台
2. 制作一个自己的第一个AI Agent，Hello Agent
3. 输出《Hello，AI Agent》

AI Agent，启动最先出现在0260。

为避免陷入学习陷阱，以阶段性目标为导引，约束学习路径。

本期学习目标为实现一致性角色，最终表现为训练一个Flux LoRa模型，整体思路为：

• 人物角色初始化：得到一张满意的T-POSE正面全身照和高清的头部图像。
• 角色多视角实现：基于初始化角色，得到不同视角的的图片。
• 丰富角色表情：给所有图片增加表情。
• 丰富背景：给增加表情后的图片增加背景。（至此，得到训练模型的图片素材）
• 素材处理：给素材批量修改大小及打标。
• 模型训练。

一、人物角色初始化

此步骤较为简单，目标有两个。

• 获得一张T-POSE正面全身照。
• 得到头部的高清放大图，作为之后脸部特征的依据。

1.1 T-Pose角色图生成

此处采用的是FLUX模型。

一般来说，获取一个角色要么随机，要么是想这个角色带有某个目标人物的脸部特征。在Flux中，可加入一个PuLID模块，用于提取目标人物的脸部特征。

工作流图示如下：

1.2 头部高清放大

基本思路：

• 提取T-Pose角色的头部区域
• SD放大+FaceDetail，SD放大过程中为防止和原图相差过大，通过图片反推提示词+ControlNet_Tile保留原图特征。
• 为保留原角色图片色彩风格，增加一个色彩匹配节点。

工作流图示如下：

二、角色多视角图

此步骤主要目的是基于第一步得到的正面T-Pose图片得到多视角图，整体思路为：

• 获取多视角参考图，为后续的图片生成提供Controlnet引导(Pose，depth，cany)。(如果已经有了多视角CN控制图，可以省略此步)
• 基于T-Pose图，在多视角参考图提供的CN控制下，生成多视角图片。
• 由于参考生图通常会使得面部特征相差较大，还需进行脸部处理，用换脸思路即可。

2.1 获取多视角参考图

可以在网上搜寻多视角的参考图，关键词如：pose sheet，但通常很难得到能直接用的参考图。

有些UP/博主也会直接分享通用的CN控制图，如下图，但抽卡表现上稳定性不高。

在多次实践后，为生成较为稳定的结果，本次采用的思路是：

• 利用MV-Adapter，基于T-Pose图先生成六视角图，虽然细节特征会相差较大，但整体身型/色彩的一致性有较好表现，之后提取的CN控制图会较为契合目标。

工作流图示如下：

2.2 生成多视角角色图片

前置准备：

T-Pose图提供整体身型、服饰、发型等元素信息，多视角参考图提供CN-控制信息(本次使用是Pose图)。

整体思路：

• 利用Fill+Redux的组合，可以生成和T-Pose相似的图片(整体身型，内容，色彩等)，但缺点是姿势不能控制。（PS: Comfyui自带的Redux相当强大，极难更改姿势信息，建议使用Redux Adv）
• 在Fill+Redux的基础上，增加Controlnet模块，控制姿势。

工作流核心图示如下：

Fill+Redux组合工作流采用后得到想要的多视角图片

2.3 换脸

2.2 生成的多视角图虽然整体内容非常相似，但在脸部特征上会有较大区别，所以会在此基础上，利用换脸工作流进行脸部特征处理，此时1.2步骤中得到的头部图就起到了比较好的作用。

换脸工作流较多，SD1,5/XL或Flux都有较为成熟的处理方法，本次采用的是Flux，整体思路为：

• 将目标图片(需要换脸的图片)的头部区域截取下来。
• 将其Resize到100W像素左右(+-30%)，Flux在此大小上生成效果较好。
• 通过Fill重绘，对截取后图片的脸部区域进行重绘，此处同时采用了PuLID+Redux+Ace(Potrait)进行脸部特征提取。
• 将重绘后的图片还原到目标图片上。

工作流核心图示如下：

重绘前的准备

Fill+Redux+Ace(Portrait)+PuLID应用：

将重绘后的脸部区域还原到目标图片中

三、丰富角色表情

此步骤的目标为生成的多视角图进行表情处理，整体思路为：

• 图片剪裁，只保留肩部以上区域。这样大多的素材会集中在头部。
• 表情移植

3.1 图片剪裁

略，随便搭个工作流即能批量处理即可

3.2 表情移植

表情移植的一个准备工作是找到表情参考图片，方法有很多，这里列举一些：

• 可以自己生成一些表情图，但是通过基本模型生成的人物表情不够丰富，可以寻找一些表情LoRa.
• 寻找一些现成的表情参考图，如搜索关键词：Expression Sheet.

有了表情参考图后，就可以利用livePortrait进行表情移植，值得一提的是，LP在不同风格（写实、3D、2D）的表情移植上不如人意，特别是眼睛的表达上，在此，经过大量实践，得到以下工作流。

工作流图示如下：

四、丰富背景

丰富背景的方式有很多，Flux也可以利用Fill+Redux重绘的方式进行背景更换，本次采用的是IC-Light，截止写作为止，IC-Light本地部署只支持了SD15，效果上，会兼顾背景和光影效果。

工作流图示如下：

至此训练素材就生成完毕(生成过程中，其实也可以用InstantID保持脸部特征)

五、素材处理

5.1 图片大小的预处理

由于本次生成图片都是768*768，比较符合训练需要，所以实践中赞未涉及。

略

5.2 图片批量打标

很多模型训练工具都提供了打标功能，如Fluxgym、秋叶模型训练器等，但是都有其缺点，目前采用的是joy caption，注意：触发提示词尽量要用一个不常见的词，实践中用的Utwin其实并不可取。

工作流图示如下：

六、模型训练

模型训练，可以随便选一个训练器，本次实践中采用的是秋叶模型训练器。

主要参数：

• 每张图片训练次数/epoch，没地方设置，但是实际是5次/img，当你开始训练时，会将图片路径下的所有图片打包到一个文件夹，以times_randomtext的形式进行命名，times即表示每张图片训练多少次。
• epoch总数，实践设置为10
• 每2epoch保存一次模型
• network_dims为32
• 学习率：1e-4

这是第一次进行模型训练，有很多影响因素值得研究，仅这次而言。

• 模型明显将发型及晚礼服肩带特征学习进去，这不在目标范围，明显和素材及打标方式强相关。
• 脸部特征其实并没有达到我想要的程度，不过在3D风格上有意想不到的效果

实际生图效果如下：

至此，人物角色一致性的实战就到此告一段落，每个步骤都有多种方式实现，之后会尝试以视频的方式进行分享讲解，敬请期待。

ComfyUI，一致性角色实战篇最先出现在0260。

本篇文章的阅读前置条件(必须)：

• 需阅读《ComfyUI，SD基础总结篇》

介绍内容包含：

• 核心概念的理解
• 基本工作流及主要控制模块总结

在《ComfyUI，SD基础总结篇》中，我们已经了解了 Stable Diffusion 1.5 和 SDXL。它们就像拥有精湛技艺的“雕塑家”，从“混沌石料”中一步步雕刻出令人惊叹的作品，代表着当前主流的 AI 图像生成技术。

现在，是时候揭开 AI 绘画领域另一条前沿技术路径的面纱了——介绍 Flux。Flux 不再是 SDXL 的简单升级，它代表了图像生成方式上的一种架构创新，为 AI 绘画带来了新的可能性。它并非要取代 SDXL，而是提供了一个不同的、有潜力的技术方向。

一、Flux核心理解

虽然在底层技术原理上，会有较大的区别。但在应用层的理解上，我们仍然可以使用SD15/XL的理解《ComfyUI，SD基础总结篇》，一句话：

独具特色的雕塑家拿着原始石料在设计需求说明书的指引下按某种雕塑策略进行雕塑创作，同样的，也有以下核心概念。

• 雕塑家：Diffusion Model，每个雕塑家都有自己的特色，如：Flux1-dev，Flux1-fill-dev，Flux1-cany/depth-dev，Flux1-kontext等。
• 原始石料：latent image，潜空间图像，SD1.5&SDXL&FLUX都是在潜空间进行图像生成的，至于为什么需要在潜空间中进行，最大原因是能极大的压缩空间，使得寻常硬件得以计算。总之，可以将其理解为创作所需的原始石料，以下如何获取原始石料的方式：
  • 直接提供latent image，设定长宽。
  • 将原始空间图像(寻常人眼感知的图片)通过VAE Encode的方式转换成潜空间图像。
• 作品去色/上色器：VAE Encode/Decode，将原始空间图像(人眼寻常感知的图片)转变成潜空间图像，这个过程也称为编码Encode，好比对雕塑成品进行去色，从而得到石料本体；同时也支持从潜空间图像转换成原始空间图像，这个过程称为Decode，好比对雕塑完毕的石料本体进行上色。这个去色和上色规则记录在VAE model中，即需要加载这个模型。
• 设计需求说明书：Text Embedding(pos + neg)，用于指导雕塑家进行雕刻，雕塑家每次雕刻都需参照设计需求说明书。如何获得需求设计说明书：
  • 通过一个转换器Text Embedding Encode将自然语言(人类语言，通常是英文)转换成雕塑家能理解的设计需求说明书，转换规则被记录在CLIP model中，即需要加载这个模型。
• 雕塑策略：调度器(scheduler)、去噪步数(steps)，采样器(sampler)。其好比雕刻策略，先制定整个雕刻计划(“路线图”)，决定了在整个生成过程需要去除的石料应该如何逐渐减少；再定义执行步骤数量，越多，耗费时间越长，就越细致；最后，基于路线图，在每一步中具体执行雕刻动作，计算并将多余的石料进行雕刻去除。

二、核心组件/概念理解

主要介绍与SD15/XL有区别的一些组件和概念

• DualCLIPLoader：和在SD15及XL中一样，Flux依然需要一个CLIP模型将自然语言转换成设计需求说明书，只是这里需要指定两个模型：CLIP_I和CLIP_T5。其设计思路与SDXL基本一致。
• LoadVae：与SD15和XL不一样的是，Flux在使用上会单独指定配套的VAE模型，一般名称叫ae.sft或者ae.safetensors.
• FluxGuidance：此处与SD15和XL有较大区别，对标其CFG。
  • Flux将引导条件融合到一起，不再区分positive和negative。（若使用ksampler，negative可接空条件）
  • 在flux的实际使用中，不再使用cfg参数，取代而代之的是guidance参数，表示条件引导的程度。（若依然使用ksampler，将其设置为1，否则会产生糊图。）
  • guidance的参数值，在Flux1-dev中，一般设置为3.5，在Fill+redux组合使用中，一般在[30-50]中选择。
• Redux：Flux提供的配套风格模型，就实际使用效果来说，其实就是通过Clip vision encode提取参考图的细节信息，再通过apply style model(redux模型作为规则转换器)并将其补充到设计需求说明书中，值得注意的是，redux的引导强度相当强烈，若使用原生自带的节点，基本上很难和CN及其他控制模块共同作用与图像生成，建议使用redux adv节点(实测有效)。

三、Flux工作流总结

在实践探索过程中，FLUX在思路上和SD15/XL并没有什么大的差别。先学习了基本文生图/图生图/重绘之后，再加入一些其他控制模块，主要包括：

• LoRa：有一些比较有意思的LoRa，包括消除LoRa，图像编辑LoRa
• IP-Adapter：对雕塑家进行增强训练(风格内容参考）
• PuLID：对嗲苏佳进行增加训练(脸部参考)
• Controlnet：对需求设计说明书进行补充说明
• Redux：对需求设计说明书进行补充说明

这样就能得到FlUX工作流的各种变体。

本部分主要介绍内容：

• FLUX.1-DEV基本工作流
• FLUX.1-FILL-DEV基本工作流
• Redux模块&其余控制模块，和SD15/XL其实并为太大区别

FLUX.1-cany/depth模型并无太多应用场景，此处主要对FLUX特有的模块进行进行介绍，另外对FLUX.1-DEV和FLUX.1-FILL-DEV模型进行工基本作流总结。

3.2 FLUX.1-DEV 工作流

3.2.1 基本文生图

和SD15/XL差别不大，主要区别在于：

• model/clip/vae的加载方式不一样：
  • model的加载节点是Load Diffusion Model
  • clip是dualcliploader，需要指定一个Clip_I和T5模型
  • vae也要单独指定与Flux配套的模型，ae.sft
• ksampler使用变化
  • 中的cfg参数固定为1(该参数已经没啥用了)，设计需求说明书的遵循程度变为了另一个flux参数：guidance，越高，约束能力越强，反之越能发挥自由度。
  • 由于Flux不再区分正负prompt，使用ksampler时，neg-prompt为空即可。

3.2.2 基本图生图

没什么好说的，一般来说很少用到直接图生图的情况，目前就两种：

• 放大图生图重绘增加细节
• 粗略的风格转绘

3.2 FLUX.1-FILL-DEV工作流

3.2.1 局部重绘（inpaint）

大方向和SD15/XL类型，在使用上有以下差异：

• 重绘时，是用FILL模型
• 基本工作流中，FluxXGuidance参数一般设置为30，也可以尝试其他的。
• FILL模型的所有工作流中，都建议加入一个节点Differential Diffusion，它的核心作用正是参照一个已有的图像，从而让新生成的内容在风格、色彩或氛围上与之保持协调一致。

3.2.2 扩展绘制（outpaint）

所谓的扩展绘制其实和重绘区别不大，只是不图片原有区域进行绘制，增加新的区域进行内容补充。

3.3 FLUX其他控制模块

3.3.1 一些好玩的LoRa

• 消除LoRa，结合FILL模型，可以很好的消除不需要的元素，也能起到修复效果。
• 加速LoRa，能让出图步数控制在8步甚至4步内。
• 编辑LoRa，结合FILL模型，能实现图像编辑效果。具体在此不再细说

3.3.2 FLUX.1-Redux-DEV 模块

Redux是Flux中特有的一个模块，使用工作流图示如下：

基于输入输出来看这个模块，其实就两个步骤：

• 其实就是将图片信息抽取出来(CLIP Vision Encode)，CLIP Vision模型提供抽取规则。
• 再将抽取的信息通过一个转化器（Apply Style Model）增加到需求设计说明书中(Embedding)，Redux模型提供转换规则。

就实践而言，Redux对整体的色彩风格、内容、结构都提取得比较到位，但是在一些细节特征上表现不太好(如脸部特征)。

3.3.3 Flux IPAdapter模块

使用上，和SD15/XL区别不大，需使用xlabs团队提供的x-flux-comfyui插件

基于输入输出来看这个模块，

• 其实就是先基于CLIP Vision模型的规则将图片信息抽取出，在通过FLUX Adapter模型对雕塑家(diffusion model)进行训练。

3.3.4 PuLID模块

对标FaceID，SDXL中也可使用。
使用FLUX版本需要结合PuLID-Flux-Enhanced插件使用。

用于提取脸部信息，并让雕塑家(diffusion model)增强训练学习.

3.3.5 Controlnet

没什么好说的，为设计需求说明书增加额外条件信息。

三、最后

Flux的的变体工作流基本上就是基本工作流+控制模块的灵性组合，后续有机会可能出视频或者直播进行细致讲解，敬请期待。

ComfyUI，Flux入门总结篇最先出现在0260。