init

1. 基础篇/1.1 什么是AI产品经理.md

@@ -0,0 +1,67 @@
+## 一、工作内容
+
+1.  **及时跟进AI模型和产品发展情况：**对于模型最新的能力、限制、风险、成本有足够了解，这个是进行场景适配挖掘和方案设计的基础。其次是对于所在方向的AI产品有一定了解，可以开拓自己的思路。
+    
+2.  **在AI能力中，适配与挖掘有价值的业务场景：**
+    
+    1.  **适配：**即已有的哪些场景加入AI可以做的更好/效率更高，例如基于AI文本理解能力，可以对用户评价进行内容合规检测、情感分析、关键词提取，提升内容审核效率与准确性和前台评价查看效率促进转化；
+        
+    2.  **挖掘：**即哪些场景原来做不了，有了AI可以做了。例如淘宝AI万能搜，在大模型技术出来前，个性化导购是无法实现的。
+        
+    
+    列出所有可能的业务场景，然后计算各个场景的ROI，筛选出ROI为正向的场景。
+    
+3.  **在AI限制与风险下，寻找产品方案**：虽然AI能力很强，但是也存在很多限制，如幻觉问题、上下文长度有限、知识不是最新的、无法使用工具等。如果你的产品对于AI回答准确性有较高要求，比如AI客服产品，在设计方案时就需要考虑降低幻觉率（如提示词设计、RAG或微调)和兜底（如AI只做回答推荐，发送回复还是由真人客服操作）。
+    
+4.  **根据数据与反馈，评估验证与优化产品效果**：不同的提示词和RAG检索策略，最终的产品效果可能差别很大，好的AI产品效果是不断调出来的。对于AI产品经理来说，需要建立一个体系来评估与验证产品效果，比如个性化推荐产品可使用点击率、AI对话产品正负反馈率/留存率等。
+    
+
+## 二、工作流程
+
+```mermaid
+graph LR
+    A["1. 需求分析"] --> B["2. 数据集构建"]
+    B --> C["3. 提示词设计"]
+    C --> D["4. 模型选型"]
+    D --> E["5. 产品设计"]
+    E --> F["6. 产品开发"]
+    F --> G["7. 测试上线"]
+    G --> H["8. 迭代优化"]
+    H --> A
+```
+
+1.  **需求分析：**由于模型接口调用（按Token数计费）或部署（GPU显卡）相较于传统服务器的成本高得多，同时模型能力也有一定限制，因此需求分析阶段核心回答 3 个问题：
+    
+    1.  **实现价值**：能够带来什么用户价值、业务价值和商业价值。
+        
+    2.  **能不能做：**分析需求预期和现有模型能力的匹配度。
+        
+    3.  **值不值做**：分析实现成本和价值比，决定是否值得做。
+        
+2.  **数据集构建：**收集、清洗和标注高质量的训练/测试数据，这是AI产品效果的关键。需要设计合理的数据采集策略，制定标注规范，确保数据的准确性、多样性、安全性。
+    
+3.  **提示词设计：**编写清晰、准确的提示词来引导大模型输出期望的结果。需要反复测试和优化，掌握提示词工程的各种技巧，以提升AI回答的准确性和相关性。
+    
+4.  **模型选型：**根据业务场景、成本预算和性能要求，选择最合适的AI模型。需要对比不同模型的能力特点、API调用成本、响应速度等因素，需要在多个模型间进行测试评估，找到性价比最优的解决方案。
+    
+5.  **产品设计：**设计用户交互界面和产品功能流程，确保AI能力与用户体验完美结合。需要考虑AI输出的不确定性，设计合理的反馈机制和兜底方案。同时要平衡功能复杂度和易用性，让AI产品真正解决用户问题。
+    
+6.  **产品开发：**协调技术团队完成产品功能实现，包括前后端开发、模型接入、数据处理等。
+    
+7.  **测试上线：**进行全面的功能测试、性能测试和AI效果测试。
+    
+8.  **迭代优化：**基于用户反馈和数据分析持续改进产品。优化提示词、调整模型参数、改进RAG检索策略等，不断提升AI产品的准确性和用户满意度。同时关注新技术发展，适时引入新能力，保持产品竞争力。
+    
+
+## 三、能力要求
+
+AI产品经理，虽然加了AI，但归根结底还是产品经理，因此产品专业能力、业务能力和商业能力依旧是核心。
+
+1.  **产品专业能力：**包括需求分析管理、产品文档撰写与原型设计、竞品分析、数据分析、产品规划、商业设计等。
+    
+2.  **业务能力：**了解所处行业的业务运作流程模式，用户痛点。
+    
+3.  **技术能力：**与互联网产品设计，需要对前后端技术有一定了解一样，AI产品经理需要对不同模型API调用、微调、RAG等技术和成本结构有一定了解，能够设计出可落地的方案。
+    
+
+<br>

1. 基础篇/1.2 机器学习基础.md

@@ -0,0 +1,162 @@
+你可能有疑惑：我不是要学习大模型么，为什么要先学习机器学习，他们之间是什么关系？
+
+这是因为大语言模型属于机器学习的子集，模型的训练依然是采用的机器学习的训练方法。
+
+比如大家都在用的 DeepSeek模型是基于大语言模型（Large language model），采用深度神经网络构建，包含数十亿至数万亿参数。模型运行分为两个阶段：
+
+-   **训练阶段**：包括预训练和优化训练（微调）。预训练通过大规模自监督学习从通用文本数据学习语言模式；优化训练通过有监督微调（SFT）或强化学习（RL）使模型适应特定任务(如回答问题)。
+    
+-   **推理阶段**：模型部署后，基于输入内容预测下一个词元，采用自回归生成方式输出响应(如文本、表格或代码)。强调模型并非检索训练数据，而是基于语义理解动态生成内容，不存储原始训练数据。
+    
+
+<br>
+
+上面提到的深度神经网络、监督微调、强化学习都是机器学习的训练方法。如果不了解这些概念，理解起来会很困难。
+
+![](../../.resources/image-1778903558680.png)
+
+上面这张图直观展示了AI、机器学习、监督学习…等的边界关系。
+
+## 1、AI的发展历程
+
+人工智能的英文是 **Artificial Intelligence**，简称 **AI。**是计算机科学的一个分支，其目的是让计算机模拟人类智能，以解决问题和执行任务。 自1956年AI作为独立学科确立以来，经历了多次起伏，不断演进发展，发展历程如下：
+
+| **时期** | **年份** | **主要事件与特征** |
+| --- | --- | --- |
+| **诞生期** | 1956-1974 | 1956年达特茅斯会议标志AI正式诞生；早期专注于符号推理和问题求解；开发了首批AI程序如逻辑理论家和通用问题求解器 |
+| **第一次AI寒冬** | 1974-1980 | 计算能力限制和过高期望导致资金削减；研究进展缓慢，公众和投资者信心下降 |
+| **专家系统时代** | 1980-1987 | 专家系统兴起，如MYCIN医疗诊断系统；基于规则的系统在特定领域取得成功；商业应用带来新一轮投资热潮 |
+| **第二次AI寒冬** | 1987-1993 | 专家系统维护成本高昂，扩展性差；硬件（如LISP机器）市场崩溃；研究资金再次大幅减少 |
+| **机器学习兴起** | 1993-2011 | 机器学习方法兴起；互联网提供海量数据；计算能力显著提升；深蓝击败国际象棋冠军（1997） |
+| **深度学习革命** | 2012-2022 | 2012年AlexNet在ImageNet竞赛中取得突破；GPU加速深度神经网络训练；AlphaGo击败围棋世界冠军（2016）；自然语言处理取得重大进展 |
+| **大模型时代** | 2022-至今 | ChatGPT发布（2022年11月）引发AI应用热潮；大语言模型（LLM）展现通用智能潜力；多模态AI、生成式AI成为主流；AI开始深入各行各业 |
+
+## 2、什么是机器学习
+
+机器学习是 AI 的子集，它核心在于不需要人类做显示编程，而是让计算机通过算法自行学习和改进去识别模式，做出预测和决策。
+
+比如我们通过代码告诉电脑，图片里包含特征1、特征2、特征3…的动物是狗，那程序对动物的判断就是通过人类直接明确编写逻辑达成的，不属于机器学习。
+
+但如果我们给电脑大量狗的图片，让电脑自行识别模式，总结特征规律，从而能对没见过的图片进行预测和判断，这就是机器学习。
+
+机器学习能利用计算机的运算能力，从大量的数据中发现一个“函数”或“模型”，并通过它来模拟现实世界事物间的关系，从而实现预测、判断等目的。这个过程的关键是建立一个合适的模型，并能主动地根据这个模型进行“推理”，而这个建模的过程就是机器的“学习”过程。
+
+![](../../.resources/image-1778903573309.png)
+
+## 3、机器是如何学习的
+
+机器学习的模型本质上是一个函数，变量x1,x2,x3…xn 叫做特征，因变量y是标签。一批历史特征和一批历史标签的集合，就是机器学习的数据集。
+
+$$ y = f(x\_1, x\_2, x\_3, ..., x\_n; \\theta) $$
+
+其中:
+
+-   y 表示模型的输出（标签或预测值）
+    
+-   x₁, x₂, x₃, ..., xₙ 表示输入特征
+    
+
+### 3.1 数据集类型
+
+-   **训练数据集**（training dataset）：用来训练的数据集，就是训练数据集。
+    
+-   **验证数据集**（validation dataset）：当机器通过训练找到了一个函数，我们还需要验证和评估，也就是说，这时候我们要给机器另一批同类数据特征，看机器能不能用这个函数推出这批数据的标签。这一过程就是在验证模型是否能够被推广、泛化（训练数据集之外的数据也能表现良好），而此时我们用到的数据集，就叫验证数据集简单来说，在验证、评估的过程里，我们就是要验证这个函数到底好不好。
+    
+-   **测试数据集**（test dataset）：如果这个函数通过了评估，那就可以在测试数据集上做最终的测试；如果通过不了，就需要继续找新的模型。
+    
+
+### 3.2 模型训练过程
+
+机器的学习过程就是在已知数据集的基础上，通过反复的计算，选择最贴切的函数去描述数据集中自变量 x1, x2, x3, …, xn 和因变量 y 之间的因果关系。这个过程，就叫做机器学习的训练，也叫拟合。
+
+> 在训练数据上表现很好，但是在测试数据或者上线真实数据上表现不好，则叫做“过拟合”。有些大模型厂商采用公开的评测数据集来训练，但是真实场景的训练不足，使得训练出来的模型榜单上跑分很高，但是实际使用一般的核心原因。
+
+训练模型就是用训练集中的特征变量和已知标签，根据当前样本的**损失**大小来逐渐拟合函数，确定最优的内部参数，最后完成模型。训练核心是减少损失，使函数对特征到标签的模拟越来越贴切。
+
+那什么是损失呢？它其实是对糟糕预测的惩罚，同时也是对模型好坏的度量。损失也就是模型的误差，也称为成本或代价。名字虽多，但都是一个意思，就是当前预测值和真实值之间的差距的体现。它是一个数值，表示对于单个样本而言模型预测的准确程度。如果模型的预测完全准确，则损失为 0；如果不准确，就有损失。
+
+![](../../.resources/image-1778903632449.png)
+
+在机器学习中，我们追求的是比较小的损失。不过，模型好不好，还不能仅看单个样本，还要针对所有数据样本，找到一组平均损失“较小”的函数模型。样本的损失大小，从几何意义上基本可以理解为预测值和真值之间的几何距离。平均距离越大，说明误差越大，模型越离谱。在下面这个图中，左边是平均损失较大的模型，右边是平均损失较小的模型，模型所有数据点的平均损失很明显大过右边模型。
+
+![](../../.resources/image-1778903645243.png)
+
+因此，针对每一组不同的参数，机器都会基于样本数据集，用损失函数算一次平均损失。而机器学习的最优化过程，就是逐步减小训练集上损失的过程。具体到我们今天这个回归模型的拟合，它的关键环节就是通过梯度下降，逐步优化模型的参数，使训练集误差值达到最小。在这里面，线性回归中计算误差的方法很好理解，就是数据集中真值与预测值之间的残差平方和。那梯度下降又是怎么一回事呢？为了让你直观地理解，我用一张图来展示一下，梯度下降是怎么一步一步地走到损失曲线中的最小损失点的。
+
+![](../../.resources/image-1778903659166.png)
+
+## 5、机器学习的分类
+
+-   **监督学习**（Supervised learning）**：**训练数据集全部有标签，叫监督学习。
+    
+-   **无监督学习**（Unsupervised learning）**：**训练数据集没有标签，叫做无监督学习。
+    
+-   **半监督学习**（Semi-supervised learning）**：**在训练数据集中，有的数据有标签，有的数据没有标签，我们叫做半监督学习。
+    
+-   **强化学习（Reinforcement Learning）：**让模型在环境里采取行动，获得结果反馈，从反馈里学习，从而能在给定情况下采取最佳行动来最大化奖励或是最小化损失。
+    
+
+监督学习、强化学习是目前最主流的类型。
+
+### 5.1 监督学习
+
+在监督学习里，机器学习算法会接受有标签的数据训练，数据标签就是期望的输出值，所以每个训练数据点都既包括输入特征，也包括期望的输出值。
+
+算法的目标是学习输入和输出之间的映射关系，从而在给定新的输入特征后，能够准确预测出相应的输出值。
+
+经典的监督学习任务包括回归和分类：
+
+-   **回归：**拿一些房子特征的数据，比如面积、卧室数、是否带阳台等，和相应的房价作为标签继续训练，然后让模型根据没见过的房子的特征预测房价，这就属于回归。
+    
+-   **分类：**就是把数据划分为不同的类别以及回归，也就是对数值进行预测。比如拿一些猫猫狗狗的照片，和一堆对应猫狗的标签，给模型训练，然后让模型根据没见过的照片预测是猫还是狗，这就属于分类。
+    
+
+![](../../.resources/image-1778903675127.png)
+
+### 5.2 无监督学习
+
+无监督学习和监督学习不同的是，他学习的数据是没有标签的，所以算法的任务是自主发现数据里的模式和规律。经典的无监督学习任务包括聚类：也就是把数据进行分组，比如来一堆新闻文章，让模型根据主题或内容的特征自动把相似文章进行组织。
+
+![](../../.resources/image-1778903690602.png)
+
+### 5.3 强化学习（Reinforcement Learning，简称RL)
+
+强化学习则是让模型在环境里采取行动，获得结果反馈，从反馈里学习，从而能在给定情况下采取最佳行动来最大化奖励或是最小化损失。
+
+类似于训小狗，刚开始的时候小狗会随心所欲做出很多动作。但随着和训犬师的互动，小狗会发现某些动作能够获得零食，某些动作没有零食，某些动作甚至会遭受惩罚。通过观察动作和奖惩之间的联系，小狗的行为会逐渐接近训犬师的期望。
+
+强化学习可以应用在很多任务上，比如说让模型下围棋，获得不同行动导致的奖励或损失反馈，从而在一局局游戏里优化策略，学习如何采取行动达到高分。
+
+![](../../.resources/image-1778903704776.png)
+
+### 5.4 深度学习
+
+深度学习是机器学习的一种方法，其关键在于使用人工神经网络来模仿大脑处理信息的方式，从而逐层提取和表示数据的特征。
+
+神经网络可以用于监督学习、无监督学习、强化学习，所以深度学习不属于他们的子集。
+
+为了更好地理解这一概念，我们可以通过一个形象的例子来说明。
+
+想象你是一个艺术家，正在学习如何画一只小猫。刚开始，你没有任何指导，只能通过观察来画。在这个过程中，你的眼睛就像是神经网络的输入层，负责采集图像。在深度学习中，数据首先被传递到输入层，就像你用眼睛看到图片一样。
+
+接着，你开始关注小猫的不同特征，比如耳朵的形状、眼睛的位置和它柔软的毛发。这就像你的大脑通过多个隐藏层对信息进行处理一样。每一层隐含层都可以看作是你逐步细化和完善你绘画技能的过程，每一层负责识别、分析和理解图片中的某一特定特征。
+
+比如，第一层可能会关注图片中的边缘和线条，就如同你大致勾勒出小猫的轮廓。第二层可能会识别出更复杂的图案，如小猫的耳朵和眼睛。第三层继续深入，识别出更具体的许多细节，如猫的毛发质感和颜色。
+
+最终，通过这些层层的分析和处理，数据到达输出层。
+
+这个输出层给出一个明确的答案，即这张图片是否是一只小猫。就像你通过多次尝试和修正，终于能够画出一只逼真的小猫一样。
+
+![](../../.resources/image-1778903723641.png)
+
+### 5.4 生成式Al
+
+生成式Al是深度学习的一种应用，它利用神经网络来识别现有内容的模式和结构，学习生成新的内容。 之所以被称为“生成式”，是因为它的主要功能是生成新的内容。与传统AI模型不同，这些模型并不只是分析或识别既有数据，而是通过学习大量的示例数据，掌握其中的模式和结构，从而能够创造出全新的数据。这种“生成”的特性，使它能够在多个领域进行内容创作，包括文本、图像、音乐等。
+
+### 5.5 大语言模型
+
+大语言模型也叫LLM （Large Language model），也是深度学习的一种应用，专门用于进行自然语言处理任务。大语言模型里面的大字说明模型的参数量非常大，可能有数十亿甚至到万亿个。而且训练过程中也需要海量文本数据集，所以能更好的理解自然语言以及生成高质量的文本。 大语言模型的例子有非常多，比如国外的GPT、LLama，国内的Kimi、豆包等，可以进行文本的理解和生成。以GPT这个模型例子，它会根据输入提示以及前面生成过的词，通过概率计算，逐步生成下一个词或token来输出文本序列。
+
+![](../../.resources/image-1778903734521.png)
+
+到这里，我们就已经了解了机器学习的基础概念。

1. 基础篇/1.3 大模型的生成和训练机制.md

@@ -0,0 +1,134 @@
+> 作为应用型AI产品经理，你不需要了解大模型的算法细节，但是理解大模型的底层运作机制，能帮助你更好地设计产品、评估技术可行性、与研发团队高效沟通。
+
+## 一、大模型是如何生成内容的？
+
+当你输入"今天天气真"，模型会计算下一个最可能出现的字——"好"。
+
+然后把"今天天气真好"作为新输入，再预测下一个字……
+
+如此循环，就生成了一整段流畅的文字。
+
+**大语言模型的本质，就是一个超级强大的"文字接龙"机器。**
+
+### （一）分词（Tokenization）
+
+计算机看不懂人类的文字，需要把长句子切分成最小单位Token（词元）。例如：句子 `I love playing games` 会被切分成 `I` `love` `playing` `games`。然后通过**词汇表**将每个词映射成一个数字，送入模型。
+
+> 词汇表是模型的"字典"，包含了模型能够识别和处理的所有 Token。 通常包含几万到几十万个 Token，包括常见的单词、汉字、标点符号,还有常见的词组、数字、甚至 emoji 表情。 每个 Token 都对应一个唯一的数字 ID。例如：I：40，love：3047
+
+Token计算器： [https://platform.openai.com/tokenizer](https://platform.openai.com/tokenizer)
+
+![](../../.resources/image-1778903795673.png)![](../../.resources/image-1778903807898.png)![](../../.resources/image-1778903823955.png)![](../../.resources/image-1778903831939.png)
+
+### （二）自回归生成
+
+当你输入"今天天气真好"，模型并不是一次性输出完整回答，而是一个字一个字地生成。这个过程叫做**自回归生成（Autoregressive Generation）**。
+
+具体流程如下：
+
+1.  模型接收到输入"今天天气真好"，计算出下一个token的概率分布，并从中选择最合适的token进行生成（假设是”，“。
+    
+2.  将"今天天气真好，"作为新的输入，再预测下一个Token（假设是"适"）。
+    
+3.  继续循环：输入变成"今天天气真好，适"，预测"合"……
+    
+4.  直到模型输出特殊的结束符号（EOS），或达到设定的最大长度，生成过程才停止。
+    
+
+## 二、大模型是怎么"学会"语言的？
+
+**预训练（Pre-training）和后训练（Post-training）**是构建一个强大、实用且安全的人工智能模型的两个核心阶段。
+
+<br>
+
+-   **预训练（学习各种知识）**
+    
+
+学习认字、语法、常识、逻辑，吸收大量的知识，但还不知道怎么用。
+
+-   **后训练（学习和人沟通）**
+    
+
+学习如何与人沟通（礼貌、服从指令），遵守社会规则（不说脏话、不违法），成为一个讨人喜欢的助手。
+
+![|53%](../../.resources/image-1778903845740.png)
+
+### （一）预训练（Pre-training）
+
+1.  **概念**
+    
+
+预训练是模型生命的起点。它是指在一个随机初始化的神经网络模型上，使用海量的、未标注的数据（如整个互联网的网页、书籍、维基百科、代码库）进行长时间的训练。这个阶段产出的模型被称为“基座模型”（Base Model），例如 GPT-3、Llama 3 的 Base 版本。
+
+2.  **原理**
+    
+
+预训练的核心原理是模型在大量无标注数据上进行**自监督学习**，通过将被遮蔽的词或下一个词作为标签来学习语言的的统计规律与语义标识。
+
+训练数据示例所示：
+
+| **输入** | **标签** |
+| --- | --- |
+| 白日依山 | 尽   |
+| 白日依山尽 | ，   |
+| 白日依山尽， | 黄   |
+| ….  | ….. |
+
+如果预测对了，模型不会调整参数；如果预测错了，模型内部的参数（权重）就会根据数学算法（反向传播）进行微小的调整降低损失。
+
+经过几万亿个词的训练后，模型不仅学会了语法，还“记住”了世界上大部分的知识，甚至涌现出了基础的逻辑推理能力。
+
+![](../../.resources/image-1778903898269.png)
+
+### （二） 后训练（Post-training）
+
+1.  **概念**
+    
+
+后训练主要是指**人类对齐（Human Alignment）**。即使经过了微调的问答训练，模型可能依然会产生有害内容（如教人做炸弹），或者回答啰嗦、不符合人类偏好。后训练就是为了纠正这些行为，塑造模型的“价值观”。
+
+> 注：在目前大模型（特别是 OpenAI 等头部公司的语境）中，“后训练”是一个更宽泛的概念，它通常**包含了**指令微调（SFT）以及后续的“对齐（Alignment）”阶段。它的核心目的是将一个聪明的模型变成一个“安全、有用、讨人喜欢”的 AI 助手（如 ChatGPT）。
+
+2.  **原理**
+    
+
+后训练最核心的机制是**监督学习（Supervised Learning）**、**基于人类反馈的强化学习（RLHF）**，或者**直接偏好优化 （DPO）**。
+
+-   **监督学习：**
+    
+    -   **指令微调 (SFT - Supervised Fine-Tuning)**：告诉模型应该如何回答问题。
+        
+        -   数据示例：`Input`: "中国的首都在哪？" -> `Output`: "中国的首都是北京。"
+            
+        -   模型通过学习这些对答，从“文本接龙大师”转变为“问答小能手”。
+            
+    -   **高效参数微调 (PEFT - Parameter-Efficient Fine-Tuning)**：因为全参数微调（改动模型所有的参数）极其昂贵，现在流行**LoRA (Low-Rank Adaptation)** 等技术。
+        
+        -   LoRA 原理：冻结原本预训练好的庞大模型参数，在旁边外挂一个非常小的“补丁模块”。训练时只更新这个小模块的参数。就像在不修改原版百科全书的情况下，在旁边贴了张小纸条。
+            
+-   **RLHF**：
+    
+    1.  人类给出各种Prompt，让模型生成多个回答。
+        
+    2.  人类标注员对这些回答进行打分、排序（比如回答A比回答B更有礼貌且准确）。
+        
+    3.  用这些排序数据训练一个**奖励模型（Reward Model）**，它相当于一个“AI裁判”，学会了人类的喜好标准。
+        
+    4.  最后，使用强化学习算法（如 PPO），让主模型不断去答题。如果“裁判”给高分，模型就强化这种答题策略；如果给低分，就调整策略。
+        
+-   **DPO**： 当模型输出的质量或风格不符合预期，例如会输出不安全内容等情况；或者目标数据难以大量生产或者标注，例如需要模型输出幽默风趣的句子，会消耗大量人力和时间来构建这种数据。可以使用直接偏好优化方法，来调整参数，使得模型输出和目标偏好差异减少。 它用数学方法绕过了复杂的“训练裁判（奖励模型）”和强化学习的环节。直接拿“人类喜欢的回答”和“人类讨厌的回答”去更新模型的参数，让模型在概率上倾向于生成前者，极大简化了训练流程。
+    
+
+3.  **目的与输出结果**
+    
+
+-   **三个核心目标（HHH标准）**：Helpful（有帮助）、Honest（诚实，减少幻觉）、Harmless（无害，遵守安全红线）。
+    
+-   **输出**：经过后训练的模型被称为\*\*Chat Model（对话模型）\*\*或 **Instruct Model（指令模型）**，这也就是我们平时使用的 ChatGPT、Kimi、豆包等最终形态。
+    
+
+## 三、Transfomer架构（可选）
+
+有兴趣和能力的同学可观看下面的视频，进一步了解 Transfomer 架构。
+
+[Transformer从零详细解读(可能是你见过最通俗易懂的讲解)\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1Di4y1c7Zm/?spm_id_from=333.788.videopod.episodes&vd_source=1eb45e0163084fb6fa12174054d9d96e)

2. 进阶篇/2.1 提示词工程.md

@@ -0,0 +1,298 @@
+## 提示词工程简介
+
+在自然语言处理（NLP）和对话系统中，提示（prompt）通常是指用户输入的文本或问题。通过仔细设计和选择提示，可以指导模型的生成过程，使其更符合用户的需求。
+
+提示词工程是指设计和优化提示的过程，以使人工智能模型能够更好地理解用户的意图和要求，并生成更准确、有用的响应。提示词工程的主要目标是：
+
+-   了解如何格式化和设计提示使模型效果最佳。
+    
+-   探索不同 prompt 对模型输出的影响。
+    
+-   创造出能优化模型输出的提示。
+    
+
+一般业务优化的过程，主要包括三个环节：
+
+![](../../.resources/image-1778904087718.png)
+
+如下我们分别分三个部分来进行介绍：
+
+## 一、Prompt 设计
+
+**目标**：选择适当的提示格式和语言，以清晰明确地表达用户的意图。
+
+**过程：** 首先，需要明确目的，在使用 prompt 之前，明确目的是什么，即准备让模型做什么样的事情。在明确目的之后，然后构造 prompt，构造的过程，主要包括如下关键点：
+
+### 1、提供更多相关的细节，可以获得更准确的答案
+
+如背景、目的、受众、要求等。
+
+| **原始 prompt** | **更好的 prompt** |
+| --- | --- |
+| 编写一篇太空探索的文章 | 为一群10-15岁的孩子编写一篇介绍太空探索历史的文章。 |
+| 请写一篇文章，关于环保的，500字 | 请撰写一篇500字的文章，讨论城市绿化对空气质量改善的影响。文章应包括以下方面的内容：城市绿化的定义，如树木和公园的增加，它们如何减少空气中的污染物，以及在城市规划中推广城市绿化的可行性措施。请提供相关数据和案例研究以支持你的论点。 |
+
+### 2、使用分隔符去更清晰地区分输入的不同部分
+
+```
+请把三个引号括起来的文本，分别总结成为一句话 '''文本内容1''' '''文本内容2'''
+```
+
+### **3、引导结构和组织要求**
+
+在这个过程中，可以为任务提供明确的结构和组织要求。指明任务的各个部分应该包括什么内容，有助于模型组织思维和材料。
+
+<aside>
+
+```
+请撰写一篇500字的文章，讨论城市绿化对空气质量改善的影响。文章应包括以下方面的内容：
+1. 引言：介绍城市绿化和其重要性。
+2. 影响空气质量的机制：解释树木和公园如何减少空气中的污染物。
+3. 可行性措施：讨论在城市规划中推广城市绿化的方法和挑战。
+4. 数据和案例研究：提供相关数据和至少两个城市绿化成功案例，以支持你的论点。
+5. 结论：总结城市绿化对空气质量的积极影响
+```
+
+### 4、限制模型输出格式
+
+最后，针对模型的输出，可以限制输出的格式，一方面可以提高可读性，使结果更清晰明了；另一方面也可以方便后续的处理，提高稳定性。
+
+以提取“病症”的任务来展示下如何去限制模型的输出格式。要求直接以 json 的格式返回。
+
+```
+请提取参考资料中的所有病症，并且以json格式返回。 回答满足下面的格式要求： 1、以json的格式返回答案，json只包括一个key, key="disease"，对应的值为列表，存储参考资料中的病症。 参考资料： """ 失眠在《内经》中称为“目不瞑”、“不得眠”、“不得卧”，其原因主要有两种：一是其他病症影响，如咳嗽、呕吐、腹满等，使人不得安卧；二是气血阴阳失和，使人不能入寐。中医常用养心安神的方法治疗失眠,既可治标、又可治本,还可以避免西药安眠药容易成瘾的弊端。中医认为，失眠多因脏腑阴阳失调，气血失和所致。正如《灵枢大惑论》中记载：“卫气不得入于阴，常留于阳，留于阳则气满；阳气满则阳娇盛，不得入于阴则阴气虚，故目不瞑矣。”在临床上，治疗失眠应着重调理脏腑及气血阴阳，以“补其不足，泻其有余，调其虚实”，可采取补益心脾、滋阴降火、交通心肾、疏肝养血、益气镇惊、活血通络等治法，使气血和畅，阴阳平衡，脏腑功能恢复正常。 """
+```
+
+在实际开发AI应用中，虽然我们提示词中指定了输出json格式，模型还是可能会在前后输出一些无关的文本，比如“好的，接下来我将输出json格式的结果”，造成解析错误。
+
+因此我们可以在API中指定输出格式为`text`、`json_object` 或 `json_schema`（适用于输出格式复杂且有严格要求，只有部分模型支持），可参考文档 [火山方舟大模型服务平台](https://www.volcengine.com/docs/82379/1585128#%E7%BB%93%E6%9E%84%E5%8C%96%E8%BE%93%E5%87%BA-beta)
+
+### 5、静态在前，动态在后
+
+模型API会对提示词缓存以降低成本提升效率，提示词缓存的运作原理基于前缀匹配。API会把从请求开头到每一个缓存控制断点的所有内容全部缓存下来。排列顺序的细微差别会带来天壤之别的结果。
+
+比如下面两种类型提示词：
+
+**动态在前，静态在后**
+
+-   #任务#总结以下内容#内容# 【内容正文】
+    
+-   #任务#提炼以下这段内容的要点#内容#【内容正文】
+    
+    > × 缓存匹配失败
+    
+
+**静态在前，动态在后**
+
+-   #内容#【内容正文】#任务#总结以上内容
+    
+-   #内容#【内容正文】#任务#提炼以上内容的要点
+    
+    > √ 缓存匹配成功
+    
+
+## 二、Prompt 优化
+
+### 1、让模型扮演一个角色
+
+让模型扮演一个具体的角色，模型的输出会更符合人类的表达方式，从而更容易被人类理解；同时输出也会更加一致。例如，在问答系统中，让模型扮演一个特定领域的专家可以使其回答更符合该领域的知识和语言习惯，从而提高回答的一致性。
+
+比如下面的案例，让模型分别扮演科学家和玄幻小说家生成一篇文章，文章的主题是：“黑洞是如何形成的”。在科学家的角度下，模型基于科学事实首先解释了黑洞是什么，然后回答了黑洞的形成过程；而在玄幻小说家的角度下，模型此时的输出不再基于科学事实，而是完全虚构，并且给人更多神秘的感觉，勾起读者的兴趣。
+
+![](../../.resources/image-1778904211059.png)![](../../.resources/image-1778904222194.png)
+
+<br>
+
+### 2、提供样例
+
+一般情况下，可以通过加入指令，来优化提示词，但是有时指令可能不容易描述清楚，提供示例会更容易。比如：我们让模型充当一个文本二分类器，对用户的评价进行二分类，分类结果为：正面评价或者负面评价。
+
+![](../../.resources/image-1778904233713.png)![](../../.resources/image-1778904244206.png)
+
+可以看出，正常情况下，模型暂时对于非绝对负面的评价都是分类为正面评价；而对于完全负面的评价才会分类为负面评价。但是我们希望**模型对用户的评价是绝对正面时，才输出正面评价；否则都输出负面评价**。比如，“我最近在这家餐厅用餐，还行，但也不是特别惊艳”这个 case，我们希望模型输出“负面评价”。此时，可以提供一些示例供模型来参考学习。
+
+```
+请根据以下分类的方式，帮我分辨用户输入文本的类别是正面评价或是负面评价，请直接输出：正面评价/负面评价。
+请参考如下样例： 示例1： 用户输入：我昨晚去了这家餐厅，他们的食物和服务都令人惊艳。我绝对会再次光顾。 输出：正面评价
+示例2： 用户输入：这本书我看过，部分情节还行，但是整体情节拖沓，比较一般。 输出：负面评价
+示例3： 用户输入：我昨天看了这部电影，我觉得还可以，但是有些部分也有点无聊。 输出：负面评价
+示例4： 用户输入：我上周去看了这部电影，简直浪费时间。情节枯燥无味，演员的表现也不尽人意。我真的后悔看了。 输出：负面评价
+请回答如下问题： 用户输入：我最近在这家餐厅用餐，还行，但也不是特别惊艳。 输出：
+```
+
+除此之外，对于一些比较难的 case，只给 label，可能不好理解，也可以尝试在给示例的同时，给出理由，这样模型会更容易理解。
+
+```
+请根据以下分类的方式，帮我分辨用户输入文本的类别是正面评价或是负面评价，请输出：正面评价/负面评价，并给出理由。
+请参考如下样例： 示例1： 用户输入：我昨晚去了这家餐厅，他们的食物和服务都令人惊艳。我绝对会再次光顾。 输出：正面评价，理由：食物和服务都令人惊艳，而且顾客会再次光临
+示例2： 用户输入：这本书我看过，部分情节还行，但是整体情节拖沓，比较一般。 输出：负面评价，理由：整体情节拖沓
+示例3： 用户输入：我昨天看了这部电影，我觉得还可以，但是有些部分也有点无聊。 输出：负面评价，理由：这部电影有些部分也有点无聊
+示例4： 用户输入：我上周去看了这部电影，简直浪费时间。情节枯燥无味，演员的表现也不尽人意。我真的后悔看了。 输出：负面评价，理由：情节枯燥，演员表现也不尽人意，用户后悔看了
+请回答如下问题： 用户输入：我最近在这家餐厅用餐，还行，但也不是特别惊艳。 输出：
+```
+
+### 3、指定完成任务需要的步骤
+
+完成特定任务，如果有明确的步骤，通过指定完成任务需要的步骤，可帮助模型按照正确的顺序执行，从而更好地生成回复。
+
+```
+请按照以下步骤写一个故事： 1、先设定故事背景和角色。 2、描述角色的目标和遇到的困难。 3、讲述角色如何克服困难并最终实现了目标。 4、最后以一个有趣的结局来结束故事。
+```
+
+这个 prompt 优化的示例中，明确指定了完成故事任务的步骤，模型可以更有条理地构思和组织故事结构，从而提高故事的质量和连贯性。
+
+### 4、提供参考内容
+
+针对特定领域的问题，如果涉及到专业知识，提供相关的参考内容可以帮助模型更好地理解问题的背景和上下文，从而减少幻觉的出现。
+
+```
+请参考如下文档，回答用户问题：
+文档名：文档内容
+问题：[问题描述]
+```
+
+### 5、给模型 “思考”时间
+
+CoT（Chain of Thought，CoT）是一种思维工具，通过逐步延伸和拓展一个主要想法，帮助人们进行更深层次的思考，并得出更复杂、更全面的结论。
+
+对于非推理模型，在一些逻辑推理、数学运算等场景下，考虑使用 CoT 分解问题，通过输出一些推断过程，可以增加模型输出正确结果的概率。
+
+**开启思考模式**
+
+对于推理模式，开启深度思考后，模型会在回答前进行思考，可以大大提高输出正确结果概率。
+
+**zero-shot**
+
+在 prompt 中加上 `Let's think step by step` 或者 `让我们一步一步分析思考`。
+
+**few-shots**
+
+以下是将用户输入的数字进行一系列加减乘除的例子。
+
+```
+你是一个计算器，请你将用户输入的数字分别加上2，减去3，乘以3，除以2后直接输出计算结果，以','作为分隔符进行返回。 示例如下： """ 输入：1，2，3，4，5 答案：0, 1.5, 3, 4.5, 6 """ 输入：2，4，6，8，10
+```
+
+我们会发现，模型无法给出正确的答案，所以，让模型处理这种复杂、多步骤的问题时，我们可以遵循以下步骤：提供实例 > 分解问题 > 提供解释。
+
+以下是将 CoT 融入到 prompt 的例子，分步骤地提供解释。
+
+```
+你是一个计算器，请你将用户输入的数字分别加上2，减去3，乘以3，除以2后直接输出计算结果，以','作为分隔符进行返回。 你可以参考以下的计算过程来帮助解决， """ 对于输入：1，2，3，4，5 计算过程如下。 首先分别对输入1，2，3，4，5加上2，得到：3, 4, 5, 6, 7 然后将3，4，5，6，7分别减去3，得到：0, 1, 2, 3, 4 然后将0，1，2，3，4分别乘以3，得到：0, 3, 6, 9, 12 最后将0，3，6，9，12分别除以2，得到：0, 1.5, 3, 4.5, 6 答案是：0, 1.5, 3, 4.5, 6 """ 输入：2，4，6，8，10
+```
+
+### 6、使用Prompt优化工具
+
+火山引擎-火山方舟推出了PromptPilot工具，输入你写的Prompt，AI会返回优化后的Prompt。
+
+![](../../.resources/image-1778904417655.png)
+
+## 三、Prompt 评测
+
+### 1、系统地测试变更
+
+在完成上面的 prompt 设计和优化之后，prompt 会发生变更，但是如何判断这个变化，是否真的使系统变得更好。一般是先通过看几个例子来确定哪个更好，但是由于样本量小，很难区分是真正的改进还是运气导致，所以需要设计一个好的评估集，在经过若干次迭代之后，用评估集来判定系统是否真正得到了改进。
+
+好的评估集，一般具有如下特征：
+
+-   **多样性：**评估集中应该包含足够的多样性，以涵盖不同的领域、话题和语境。
+    
+-   **高质量：**评估集中的数据应该是高质量的，能准确反映了真实的业务情况。
+    
+-   **规模适中：**评估集的规模应该足够大，以便能够充分评估 prompt 的性能，但又不能太大以至于导致计算资源的过度消耗。通常，几百到几千个样本是一个合理的范围。
+    
+
+### 2、重复和迭代
+
+prompt 的生成过程，实际上是一项实验性很强的过程，在这个过程中，需要不断地尝试和调整不同的方法，以找到最优的 prompt。一个典型的迭代路径是：首先完成 prompt 设计，接着基于设计好的 prompt 获取实验结果，分析 bad cases，解 bad cases，并进一步优化 prompt，通过多次的重复和迭代，直到达到一个最优效果。
+
+prompt 工程迭代过程如下：
+
+![](../../.resources/image-1778904431034.png)
+
+最后，进一步需要说明的是，获取模型的最佳输出不仅需要优秀的 prompt，同时也取决于用户提供的反馈和修正。prompt 优化完成之后，通过线上持续的反馈和修正，模型才能更顺利地理解并满足用户需求。
+
+## 附录
+
+### 1、参考模版
+
+```
+三重引号、XML标签、章节标题定义结构
+
+##角色（可选）##
+让模型模拟特定身份（如科学家、玄幻小说家、律师），使其输出符合领域风格。
+如：你是一个资深的产品经理、你是一个用户体验研究员。
+
+##背景（可选）##
+我是一个社区产品经理，需要做一份小红书的竞品分析报告，以便于规划我们产品未来的方向。
+
+##任务（必须）##
+帮我做一份小红书的竞品分析报告
+
+##要求##
+{输出格式和内容}
+示例：问题{X}→输出{Y}
+示例：包括：市场分析、产品定位、公司资源、产品功能、用户体验，长度2000字
+
+##输入（可选）##
+规则：
+1. 步骤1...
+2. 步骤2...
+
+```
+
+### 2、提示词生成助手
+
+```
+# 角色设定
+你是一个AI提示词专家，精通提示词工程。
+# 背景
+用户现在要使用AI，但是他不了解提示词怎么写。
+# 任务
+为用户生成高质量的提示词。
+# 要求
+## 1. 高质量的提示词的标准如下：
+（1）角色 (Role)
+  - 描述：指定模型在回复中扮演一个最匹配任务的角色。
+  - 示例：“你是一个资深的提示词工程师，非常擅长把 AI 技术应用与教育产品设计中。”
+（2）指示 (Instruction)
+  - 描述：对任务的具体内容进行详细描述，明确 AI 需要做什么。
+  - 示例：“你需要认真理解用户提出的问题，并给到专业且精简的回答，建议控制在5条以内。”
+（3）上下文 (Context)
+  - 描述：介绍与任务相关的背景信息，帮助模型更好地理解情境。
+  - 示例：“我正在做一款 AI 教育产品，其中一门课程是帮助编程零基础的人提升工作效率。”
+（4）例子 (Examples)
+  - 描述：对关键信息做举例说明，为模型提供一个可参考的范本。
+  - 示例：“比如：在教育行业，可以利用 AI 助教来做课程答疑。”
+（5）输出 (Output)
+  - 描述：指定所需的输出长度和输出格式（如 JSON, XML, Markdown 表格等）。
+  - 示例：“输出一个表格，每行分为两个部分，分别是‘业务需求’和‘我可以向 AI 说什么’。”
+
+## 2. 上面的标准不是都是必须的，你需要根据用户的任务来判断。
+## 3. 每次问用户一个问题，直到收集完你需要的信息。
+# 最后输出
+XML标记格式的完整提示词。
+```
+
+### 3、参数设置
+
+**关键参数**
+
+-   Temperature：该参数用于控制模型输出结果的随机性。Temperature 的值越高，输出的随机性就越大，Temperature 的值越低，输出的随机性就越小。在实际应用方面，对于分类任务，我们可以设置更低的 `temperature` 值，以促使模型返回更真实和简洁的回答。 对于诗歌生成或其他创造性任务，你可以适当调高 `temperature` 值，从而增加多样性和创造性。
+    
+-   Top\_p：可以控制模型在生成响应时的确定性程度，从而影响生成结果的多样性和创造性。当提示语较长且描述得足够清楚时，模型生成的输出质量较好、置信度较高，此时可以适当调高Top\_p的值；反之，如果提示语很短、很含糊，再设置一个较高的Top\_p值，模型的输出可能就会变得不稳定。
+    
+
+**参考配置**
+
+一般情况下，采用默认值：temperature=0.7， top\_p=0.9
+
+对于分类或需要稳定输出的任务：temperature=0.01，top\_p=0.7
+
+对于需要创造性，多样性的任务：temperature=0.7
+
+实际效果以业务实测为准。
+
+**Token**
+
+Tokens定义说明： 通常1个中文词语、英文单词、数字、符号计为 1 个token，由于不同模型采用的分词器不同，同一段文本可能会分为不同的tokens数量。可通过火山引擎的 [Token计算器](https://console.volcengine.com/ark/region:ark+cn-beijing/tokenCalculator) 计算实际Token。

2. 进阶篇/2.2 模型微调.md

@@ -0,0 +1,189 @@
+## 一、什么是微调（Fine-tuning）
+
+预训练模型通常在海量通用数据上训练，具备广泛的语言理解能力。
+
+模型微调是指在预训练的大型语言模型基础上，使用特定领域或任务的数据进行进一步训练，使模型能够更好地适应特定应用场景的过程。
+
+## 二、微调的作用
+
+1.  **提高准确性：**使用垂直领域（如医疗、金融行业）的数据微调后，模型在该领域的准确率和可靠性会显著提升。
+    
+2.  **增强可控性：**通过微调可以调整模型的行为模式、输出格式和回答风格，使其更符合预期。
+    
+
+## 三、微调的场景
+
+1.  尽力优化提示词工程，但模型效果仍不理想，或提示词本身变得过于复杂。
+    
+2.  对模型输出有特定的格式要求，但它有时无法稳定地满足要求。
+    
+3.  希望精简提示词，以加快线上推理速度或降低Token。
+    
+
+## 四、如何进行微调
+
+可通过【火山方舟】或者【阿里云百炼】进行模型的微调
+
+<br>
+
+### （一）准备阶段
+
+1.  **明确目标**
+    
+
+首先要确定你希望模型微调后具备什么能力。比如：
+
+-   **知识注入**：让模型学会公司内部的规章制度。
+    
+-   **格式对齐**：让模型严格按照 JSON 格式输出结果。
+    
+-   **风格迁移**：让模型用特定的语气（如客服语气）进行回复。
+    
+
+2.  **收集与构建数据集**
+    
+
+微调需要成对的 `(指令/问题, 预期回答)` 数据。通常格式如下（通常保存为 JSONL 文件）：
+
+```bash
+{"messages":[{"role":"user","content":"请根据古诗内容，仅回复作者的名字：姑苏城外寒山寺，夜半钟声到客船"},{"role":"assistant","reasoning_content":"用户让我根据古诗内容回复作者名字，诗句是“姑苏城外寒山寺，夜半钟声到客船”。首先，我需要确定这句诗出自哪首诗。这句诗很有名，应该是张继的《枫桥夜泊》。记得以前学过，这首诗的作者是唐代诗人张继。用户要求仅回复作者名字，所以不需要其他内容。检查一下搜索到的信息，虽然这里显示没有具体资源，但根据已有的知识，确定作者是张继没错。所以直接回复名字即可，不用多余的解释。","content":"张继","loss_weight":1}]}
+{"messages":[{"role": "user", "content": "什么时候需要SFT？"}, {"role": "assistant", "content": "通过 prompt engineering 无法解决或 prompt 中描述过于复杂时；对大模型输出内容有格式要求时，而模型仍有部分 case 不符合要求；期望通过 SFT 来减少 prompt 中的内容，加速线上推理的耗时。"}]}
+```
+
+**数据的质量远比数量重要**。几千条人工精编、高质量的问答数据，微调效果往往好于几十万条粗糙拼凑的数据。
+
+> **数据量级建议**
+
+起初不需要构建大量 SFT 数据集，建议优先采用少量数据（50条~100条）对模型做 SFT 后观察真实评估是否有收益。如果有收益，可以尝试以部分数据为种子数据集继续扩充以优化表现。如果无明显作用，建议检查 SFT 数据集的质量。
+
+-   **针对不同场景下，数据量级的建议：**
+    
+    -   文案生成，剧本创作，小说续写等生成类任务：2～3k。
+        
+    -   参考问答：2k ~ 1w。
+        
+    -   文本分类：1～3k，和类别数量以及任务难易度强相关，类别较多/任务较难的场景可能需要1w条以上。
+        
+-   **如何扩充SFT数据：**
+    
+    -   明确数据扩充任务的输入输出映射关系，选用适配模型，通过前缀提示（PE）+ 小样本示例（Few Shots） 策略构建提示词。
+        
+    -   驱动模型生成补充样本，将其纳入 SFT 数据集候选池。
+        
+    -   校验生成样本与人工标注样本的风格、精度一致性；若不达标，迭代优化提示词并重新生成。
+        
+
+**数据质量判断**
+
+-   Badcase 的覆盖度：SFT 核心目标是解决已知 Badcase，需确保数据集充分覆盖存量 Badcase 场景，为模型优化提供明确优化目标。
+    
+-   贴合真实应用场景：示例的提示词与输出需与实际应用场景一致，尽可能贴近真实需求。
+    
+-   保证问答质量：问题与答案需具体、清晰。
+    
+-   高质量数据源：优选历史数据、专家标注数据、业务日志数据。
+    
+
+* * *
+
+### （二）技术与方案选型阶段
+
+针对你手头的预算和目标，选择合适的微调策略。
+
+1.  **选择基座模型 (Base Model)**
+    
+
+挑选一个经过预训练的开源模型。常见的有 Llama-3、Qwen (通义千问)、GLM-4 等。如果你想在普通电脑上跑，可能选 7B（70亿）或 8B 量级的参数；如果在服务器上，可能选 70B 或更大。
+
+2.  **选择微调方法**
+    
+
+这是技术核心所在。目前主流有两类：
+
+-   **全参数微调 (Full Parameter SFT)**：
+    
+    -   把模型里所有的参数（几十到几千亿个）全都解冻，根据新数据重新训练一遍。
+        
+    -   **缺点**：极其烧钱，需要巨量显存（GPU），普通人玩不起。
+        
+    -   **优点**：模型吸收新知识非常通透，能力天花板高。
+        
+-   **高效参数微调 (PEFT, Parameter-Efficient Fine-Tuning) —— 以 LoRA 为代表**：
+    
+    -   **LoRA (Low-Rank Adaptation)** 的原理是：冻结原模型所有的巨大参数网，不改变它。而在它旁边挂载一个**非常小的附加网络（补丁）**。训练时，只更新这个“补丁”里的参数。 比喻：就像你买了一本昂贵的《辞海》（预训练模型），你不想在书上乱画（全参数微调），所以你拿了一本小小的便利贴（LoRA），把笔记写在便利贴上，贴在书旁边。
+        
+    -   **QLoRA (Quantized LoRA)**：进一步把原模型的数据精度压缩（从32位浮点数压到4位），极大地降低显存占用。现在甚至可以在单张普通游戏显卡（如 RTX 4090）上微调几十亿参数的大模型。
+        
+
+* * *
+
+### （三）训练阶段
+
+在这个阶段，让机器开始“啃教材”。现在开源社区有很多傻瓜式的框架（如 **LLaMA-Factory**），懂一点点参数配置就能跑起来。
+
+1.  **设置超参数**
+    
+
+你需要像老中医配药一样，调整模型学习的参数，决定它如何学习：
+
+-   **学习率 （Learning Rate）**：模型更新知识的跨度。设置过高可能导致陷入局部最优或过拟合，设置过低则会减慢训练速度或导致训练难以收敛。 **经验参考值**：
+    
+    -   **LORA 训练**：建议设置为 1e-5 到 5e-5。
+        
+    -   **全量 SFT**：建议设置为 1e-5 到 2e-5。
+        
+-   **批次大小（Batch Size）**：模型一次看多少道题。
+    
+-   **训练轮数（Epoch）**：这套教材让模型反复读几遍。读少了没学会（欠拟合），读多了会死记硬背变成了书呆子（过拟合）。
+    
+    -   **通用建议**：通常设置为 2 到 5 轮。
+        
+    -   **判断方法**：可以通过观察 loss 曲线来判断是否需要调整：
+        
+        -   **过拟合**：如果训练集 loss 下降而验证集 loss 上升，说明模型已过拟合，应停止训练。
+            
+        -   **未收敛**：如果训练集和验证集 loss 都在缓慢下降，说明模型尚未收敛，可以继续训练。
+            
+    -   **特殊场景**：对于文案生成、小说创作等生成类任务，loss 无法完全反映上下文逻辑和风格。根据经验，可将 epoch 适当增大，例如设置为 5 到 10 轮。
+        
+
+2.  **开始训练**
+    
+
+点击运行后，紧紧盯着一张叫做 **Loss（损失函数）下降曲线** 的图表。Loss 分数代表着“模型当前回答跟标准答案的差距”。
+
+理想状态下，Loss 线会平稳下降，最终稳定在一个低水平。
+
+![](../../.resources/image-1778904494574.png)
+
+3.  **警惕“灾难性遗忘”**
+    
+
+如果在微调时喂了太多某一领域的特定数据（比如一直让它背法律条文），模型可能会把原来预训练时学到的常识给忘了（比如忘记了基本运算或者无法正常对话）。这就叫灾难性遗忘。通常通过在微调数据中混入一些通用对话数据来缓解。
+
+* * *
+
+### （四）效果评估阶段
+
+1.  **确定性任务：**
+    
+    Label 标注准确、输出结果唯一的任务，如分类、实体抽取、信息提取等任务。
+    
+    核心评估依据为**训练集与验证集的 loss 指标**，重点关注两点：
+    
+    -   训练集与验证集的损失是否同步下降；
+        
+    -   多轮 epoch 训练后，loss 是否趋于收敛。
+        
+2.  **生成式任务：** 输出结果多样、无固定标准答案的任务，如问答、文案生成、角色扮演对话等任务。
+    
+    采用**训练集 loss 参考 + 真实评估集业务指标主导**的评估策略：
+    
+    -   **训练集 loss 仅作参考**：验证集 loss 计算依赖 token 级 KL 散度损失，与真实业务场景的输出要求不完全匹配，可能出现验证集 loss 无明显下降但业务指标提升的情况；
+        
+    -   **真实评估集指标为核心**：服务发布后，基于真实评估集的业务指标（如内容相关性、流畅度、用户满意度等）判定最终微调效果。
+        
+
+## 五、微调的价格
+
+[https://www.volcengine.com/docs/82379/1544106?lang=zh#b3a42676](https://www.volcengine.com/docs/82379/1544106?lang=zh#b3a42676)

2. 进阶篇/2.3 RAG.md

@@ -0,0 +1,691 @@
+# 一. 什么是 RAG
+
+RAG 即 **检索增强生成**（Retrieval-Augmented Generation），是一种将 **信息检索** 与 **大语言模型生成** 相结合的 AI 架构。
+
+它的核心思路非常简单：
+
+1.  用户提出问题
+    
+2.  系统先从知识库中 **检索** 出相关内容
+    
+3.  将检索到的内容连同问题一起交给大模型
+    
+4.  大模型基于这些"证据"**生成** 回答
+    
+
+**类比理解**：大模型像一个博学的老师，但不了解你公司的具体情况。RAG 就是给老师配了一个助手，先帮老师查阅公司的规章制度和业务资料，老师再基于这些材料给出建议。
+
+RAG 的概念最早来自 2020 年 Meta/FAIR 的论文，提出了 RAG-Sequence 与 RAG-Token 两种经典范式（按序列或按 Token 融合检索证据），此后迅速成为 AI 应用的主流架构。
+
+# 二. 为什么需要 RAG
+
+## 1\. 大模型的固有缺陷
+
+尽管大模型能力强大，但存在几个无法回避的问题：
+
+| **问题** | **表现** | **举例** |
+| --- | --- | --- |
+| 知识固化 | 训练后无法自动更新知识，存在"知识截止日期" | 无法回答最新发布的产品信息 |
+| 幻觉问题 | 没有答案时会"一本正经地胡说八道" | 编造不存在的政策条文 |
+| 缺乏私有知识 | 不具备企业内部数据和业务规则 | 无法回答"我们平台退货包运费吗？" |
+| 上下文窗口有限 | 无法一次性处理超长文档 | 无法读完一本超长的产品手册再回答 |
+
+## **2\. RAG 的优点**
+
+-   **回答更准确**：基于真实数据生成，避免"凭空编造"的问题
+    
+-   **知识实时更新**：更新知识库即可，无需重新训练模型
+    
+-   **可溯源、可验证**：每个回答都能追溯到具体的检索来源
+    
+-   **成本更低**：相比模型微调，RAG 是更轻量的解决方案
+    
+-   **领域适配强**：接入私有知识库，瞬间变成"领域专家"
+    
+
+## 3\. RAG 的缺点
+
+-   **系统复杂度增加**：引入检索环节会增加响应延迟，研究表明检索环节占 RAG 总耗时的 60% 以上
+    
+-   **可能会降低准确性：**对于长文档问答，和给完整的文档作为上下文相比，检索召回的数量有限，比如你跟他说“帮我总结整本书的内容”，可能只总结了一部分
+    
+-   **不能完全消除幻觉**：RAG 降低了幻觉概率，但不能让模型完全无误
+    
+
+## 4\. RAG 典型应用场景
+
+| **场景** | **描述** | **RAG 价值** |
+| --- | --- | --- |
+| 🛒 电商客服 | 回答商品咨询、退换货政策、订单查询 | 基于平台真实数据回答，避免模型胡编 |
+| 📚 企业知识库 | 员工查询内部制度、SOP、产品文档 | 让内部知识即时可查，提高查询效率，降低沟通成本 |
+| 🏥 医疗问答 | 基于医学文献和诊疗指南回答专业问题 | 降低幻觉风险，提供可溯源的专业回答 |
+| ⚖️ 法律咨询 | 基于法规条文和判例回答法律问题 | 引用具体法条，提升回答权威性 |
+| 📊 研究分析 | 基于行业报告和市场数据生成分析 | 整合多源信息，提供有据可依的洞察 |
+
+## 5\. RAG vs 微调：如何选择？
+
+作为 AI 产品经理，经常需要在 RAG 和微调之间做选择。两者的目标相同——让模型在特定领域表现更好，但路径完全不同。
+
+| **对比维度** | **RAG** | **微调（Fine-tuning）** |
+| --- | --- | --- |
+| 核心思路 | 让模型"查资料"再回答 | 让模型"学会"特定领域知识 |
+| 知识更新 | ✅ 更新知识库即可，秒级生效 | ❌ 需要重新训练，周期长 |
+| 成本  | ✅ 低，无需大量 GPU | ❌ 高，需要算力和标注数据 |
+| 可解释性 | ✅ 可追溯到具体来源 | ❌ 黑箱，难以解释 |
+| 适用场景 | 知识密集型问答、客服、搜索 | 风格迁移、格式规范、特定推理能力 |
+| 数据需求 | 非结构化文档即可 | 高质量标注数据 |
+
+**实践建议**：在大多数业务场景中，**优先考虑 RAG**，因为它成本低、见效快、易维护。只有当 RAG 无法满足特定需求（如调整模型的输出风格或推理模式）时，才考虑微调。两者也可以结合使用。
+
+# 三. RAG 的整体架构
+
+RAG 系统的完整工作流程可以分为两大阶段：**离线数据准备** 和 **在线查询响应**。
+
+## **1\. 📦 离线阶段：数据准备**
+
+```mermaid
+flowchart LR
+    A["原始文档<br>(PDF/网页/FAQ等)"] --> B["数据清洗<br>与提取"]
+    B --> C["文本分片<br>(Chunking)"]
+    C --> D["向量化<br>(Embedding)"]
+    D --> E["存入向量数据库"]
+```
+
+## **2\. 🔍 在线阶段：查询响应**（从向量数据库检索）
+
+```mermaid
+flowchart LR
+    F["用户提问"] --> G["Query 处理<br>(改写/扩展)"]
+    G --> H["向量检索<br>(Top-K)"]
+    H --> I["重排序<br>(Rerank)"]
+    I --> J["构建 Prompt"]
+    J --> K["LLM 生成回答"]
+    K --> L["返回用户"]
+```
+
+# 四. RAG 工作链路详解
+
+## 1\. 离线阶段：数据准备
+
+数据准备是 RAG 系统的"地基"，直接决定了后续检索和生成的质量。
+
+### 1.1 数据提取与清洗
+
+将各类原始数据（PDF、Word、网页、FAQ、音视频、图片等）统一处理为可用的文本格式
+
+> 现在也有多模态的向量模型，比如[Jina CLIP](https://jina.ai/zh-CN/news/jina-clip-v1-a-truly-multimodal-embeddings-model-for-text-and-image/)，可以直接将图片转为向量。
+
+**以电商客服为例：**
+
+-   **参考数据源**
+    
+    -   帮助中心与FAQ（退换货、运费、发票、质保）
+        
+    -   客服 SOP 与话术（不同场景的处理流程和话术）
+        
+    -   商品信息（规格参数、商品介绍、使用说明）
+        
+    -   订单与物流字段说明（状态含义、异常件类型解释）
+        
+    -   历史的客服对话记录
+        
+-   **提取与清洗步骤**
+    
+    1.  **结构化关键信息**：把政策中的 **适用范围、条件、例外、时效、责任方** 拆成清晰条目。
+        
+    2.  **标准化术语**：统一同义词（如“包邮”“免运费”“运费全免”）与字段命名（如“退款成功”“退款完成”）。
+        
+    3.  **补足上下文**：为容易歧义的条款补齐前提（如“7 天无理由”是否排除定制类目）。
+        
+-   **输出形态建议**
+    
+    -   **结构化知识：**如FAQ，方便精准命中高频问题。
+        
+    -   **非结构化知识**：不必硬改为 Q&A 格式，保持原有文档结构即可，具体的分片处理策略和最佳实践详见下一节。
+        
+
+### 1.2 文本分片（Chunking）
+
+将长文档切成语义相对独立、长度适中的小片段。这是影响 RAG 效果的**关键**。
+
+**主流分片策略：**
+
+| **分片策略** | **描述** | **优点** | **缺点** |
+| --- | --- | --- | --- |
+| 固定大小切片 | 按固定的 Token 或字符数量直接将文本截断，通常配合设置一定的重叠量防止语义被硬性切断 | 逻辑最简单，处理速度最快，计算成本极低，不需要复杂的解析逻辑 | 极其容易破坏句子的完整语义，导致检索到的内容缺乏上下文（例如把一个长句从中间劈开） |
+| 分隔符切片 | 根据多种字符（如\\n\\n、\\n、中文句号、英文句号）来分割。 | 实现简单，比固定大小切片更好地保留语义完整性，按自然段落或句子边界切分，通用性强 | 对于结构极其复杂的长篇文档，依然可能在极限情况下出现轻微的语义截断 |
+| 基于文档结构切片 | 针对特定格式文档（Markdown、HTML、PDF、Word），利用其自带的结构标签（标题层级、表格、段落节点）进行精准分割 | 完美保留作者的原始排版逻辑、章节上下文以及表格等富文本信息 | 极度依赖文档本身的格式规范度，且切分出的文本块大小可能极其不均匀（有的章节只有一句话，有的章节有几千字） |
+| 语义切片 | 先将文本拆分成极小的基本单元（如单句），计算相邻句子的 Embedding 向量相似度；当相似度急剧下降（出现"断崖"）时，在此处执行切分 | 能够最大程度保证每个文本块内部的语义高度聚焦、连贯且独立 | 需要进行大量的前置 Embedding 相似度计算，处理耗时较长，对算力资源要求较高 |
+| 基于大模型的切片 | 利用 LLM 在入库前预处理文档，通过"**命题提取**"将复杂长段落拆解、重写为多个独立、自包含的短陈述句（补全代词和缺失上下文），再进行切分和向量化 | 检索精度极高，彻底解决了传统切片中代词指代不明或上下文缺失导致的检索失败问题 | 预处理时的 Token 消耗巨大，构建知识库的速度非常缓慢。 |
+
+通常只适用于高价值、高频检索的核心数据 |
+
+**分片最佳实践：**
+
+除了选择合适的分片策略，以下实践可以显著提升分片质量和检索效果：
+
+-   **拼接上下文前缀**：每个分片自动拼接上级标题，确保单独检索到时仍能理解语境（如 `[第三章 退换货政策 > 3.2 七天无理由 > 适用范围] 正文内容……`）
+    
+-   **生成元数据**：为每个分片补充一句话摘要、适用场景标签、假设性问题，提升检索召回率
+    
+-   **保留完整步骤**：操作/流程类内容按步骤节点切分，避免把一个完整流程拆散到多个分片中
+    
+
+<br>
+
+**命题提取**是 RAG 中一种高级的文本预处理技术，核心思想是：**在入库前用大模型将复杂段落拆解、改写为多个独立、自包含的短陈述句**。
+
+**（1）为什么需要它？**
+
+传统切片方式有一个常见痛点：切出来的文本块里经常包含代词（"它""该产品""上述情况"）或省略了前文的关键上下文，导致这个片段**单独拿出来看时语义不完整**，检索时就容易匹配失败。
+
+**（2）怎么做？**
+
+用 LLM 对原始段落做如下处理：
+
+1.  **拆解**：把一个长段落拆成多个独立的事实陈述
+    
+2.  **补全**：把代词还原为具体实体，把省略的前提条件补上
+    
+3.  **重写**：确保每个短句**不依赖任何上下文就能被理解**
+    
+
+**（4）举个例子**
+
+**原始段落：**
+
+> 我们平台的七天无理由退货政策适用于大部分商品。但定制类和生鲜类除外。它的退货运费由买家承担。
+
+**命题提取后：**
+
+-   "该平台的七天无理由退货政策适用于大部分商品。"
+    
+-   "定制类商品不适用七天无理由退货政策。"
+    
+-   "生鲜类商品不适用七天无理由退货政策。"
+    
+-   "七天无理由退货的退货运费由买家承担。"
+    
+
+每一条都是**自包含、无歧义**的独立陈述，检索时匹配精度会大幅提升。
+
+### 1.3 向量化（Embedding）
+
+将每个文本分片通过 Embedding 模型转换为高维向量。向量之间的距离反映了语义相似度——意思越接近的内容，向量空间中的距离越近。
+
+**Embedding 模型选型**
+
+可以参考 MTEB LeaderBoard（目前最全面的向量模型评测榜单，覆盖检索、分类、聚类、语义相似度等多个维度，地址是 [https://huggingface.co/spaces/mteb/leaderboard](https://huggingface.co/spaces/mteb/leaderboard)[）](https://huggingface.co/spaces/mteb/leaderboard%EF%BC%89)
+
+**闭源商业 API**
+
+| **模型名称** | **特点与适用场景** | 链接  |
+| --- | --- | --- |
+| OpenAI `text-embedding-3-small/large` | 目前性价比和综合效果的标杆，适合追求极致效果、不想折腾部署的场景 | [https://developers.openai.com/api/docs/models/text-embedding-3-small](https://developers.openai.com/api/docs/models/text-embedding-3-small) |
+| Cohere `embed-multilingual-v3.0` | 多语言支持极佳，配套 Rerank 模型业界顶流 | [https://cohere.com/blog/introducing-embed-v3](https://cohere.com/blog/introducing-embed-v3) |
+| 豆包 `doubao-embedding` | 字节跳动火山引擎出品，支持中英双语，维度最高 2048，适合国内网络环境 | [https://www.volcengine.com/docs/82379/1521766?lang=zh](https://www.volcengine.com/docs/82379/1521766?lang=zh) |
+| 通义千问 `text-embedding-v3` | 阿里云出品，支持多语言，维度最高 2048，中文语境表现稳定 | [https://help.aliyun.com/zh/model-studio/text-embedding-synchronous-api](https://help.aliyun.com/zh/model-studio/text-embedding-synchronous-api) |
+
+**开源私有化部署**
+
+| **模型名称** | **特点与适用场景** |
+| --- | --- |
+| BGE (BAAI General Embedding) | 中文及多语言开源领域标杆，各大榜单长期霸榜，闭眼选默认方案 |
+| M3E (Moka Massive Mixed Embedding) | 中文开源圈经典，垂直领域理解深，FastGPT/Dify 等常作默认推荐 |
+| Jina Embedding | 支持超长上下文（如 8k+ Token），适合超大文档整体向量化 |
+| Nomic Embed | 全开源、支持长上下文，英文和代码检索表现优异 |
+
+<br>
+
+**选型建议：**
+
+-   **0-1 测试项目**：直接接 OpenAI 的 `text-embedding-3-small`，省心且便宜。
+    
+-   **企业级应用**：考虑到数据合规与安全，本地部署开源的 `BGE-m3` 或 `M3E` 是目前最稳妥的方案。 </aside>
+    
+
+### 1.4 存入向量数据库
+
+将生成的向量及其对应的原文和元数据存入向量数据库，构建可快速查询的索引。
+
+**（1）结构**
+
+向量数据库包括集合（相当于表）和集合数据（想到于表里的每行的数据）
+
+每个集合有向量和标量字段
+
+-   **ID（必须）：**主键
+    
+-   **向量字段（必须且只有一个）：**就是存储向量化后的数据
+    
+-   **标量字段（可选，可自定义多个）**：原文内容、来源文档名、章节标题、更新时间、标签等
+    
+
+**（2）检索机制**
+
+将用户查询向量化后通过集合的**向量字段**进行检索
+
+**（3）和传统数据库的核心区别**
+
+| **对比维度** | **传统数据库（MySQL）** | **向量数据库（Milvus）** |
+| --- | --- | --- |
+| 查询方式 | `WHERE name = '退货政策'`（精确匹配） | "退货怎么办"（语义相似搜索） |
+| 核心数据 | 字符串、数字、日期 | 高维向量 + 原始文本 + 元数据 |
+| 索引类型 | B-Tree、Hash | HNSW、IVF\_FLAT 等向量专用索引 |
+| 返回结果 | 精确匹配的行 | 按相似度排序的 Top-K 条结果 |
+
+**（4）常见向量数据库**
+
+Milvus、FAISS、Pinecone、Weaviate、Chroma、PGVector 等。
+
+## 2\. 在线阶段：查询响应
+
+当用户发起提问时，系统实时执行以下流程：
+
+### 2.1 Query 处理
+
+用户的原始提问往往不是最佳的检索查询。通过查询改写、扩展等手段优化检索效果。
+
+**常见优化策略：**
+
+**（1）查询改写**
+
+核心思路是用 LLM 把用户的口语化问题转成更适合检索的表述。在用户提问和检索之间加一步 LLM 调用，用 Prompt 指示模型改写查询。常见手段包括：
+
+-   **去口语化**：去除语气词、缩写，提炼正式表述（如「买的东西到了发现坏了咋办」→「商品签收后发现损坏的售后处理流程」）
+    
+-   **补全指代**：结合对话上下文，把"它""这个"替换成具体实体
+    
+-   **HyDE（假设性文档嵌入）**：让 LLM 先生成一段"假设性答案"，再用这段答案去做检索，因为答案和知识库文档的语义更接近
+    
+
+**（2）查询扩展**
+
+核心思路是从多个角度生成子查询，提升检索的 **召回率**。用 LLM 将一个问题拆成多个子查询，分别检索后合并结果。例如：
+
+-   用户原始问题：「RAG 系统怎么提升效果？」
+    
+-   扩展子查询 1：「RAG 检索阶段有哪些优化方法？」
+    
+-   扩展子查询 2：「RAG 生成阶段如何提升回答质量？」
+    
+-   扩展子查询 3：「RAG 知识库建设的最佳实践是什么？」
+    
+
+每个子查询分别检索 Top-K，将所有结果去重、合并后送入 LLM 生成最终回答，覆盖问题的不同侧面，避免单一查询遗漏相关内容。
+
+**（3）意图识别**
+
+核心思路是先判断用户问的是什么类型的问题，再 **路由到不同的处理逻辑**，避免所有问题都走同一套检索流程。
+
+| **识别到的意图** | **路由策略** |
+| --- | --- |
+| 查询事实类（"退货政策是什么"） | 走向量检索知识库 |
+| 查询数据类（"上个月销量多少"） | 调用数据库 / BI 接口 |
+| 闲聊类（"你好呀"） | 直接用 LLM 回复，不走检索 |
+| 操作类（"帮我下个单"） | 路由到对应的业务 API |
+
+<br>
+
+**实践建议**：这三者通常**组合使用**——先做意图识别决定走哪条路，再对需要检索的查询做改写和扩展，最后去检索知识库。LangChain 和 LlamaIndex 等框架都提供了现成的模块来实现这些策略。
+
+### 2.2 向量检索（Retrieval）
+
+将处理后的查询向量化，在向量数据库中搜索最相似的 Top-K 个分片。
+
+**检索方式对比：**
+
+| **方式** | **原理** | **优势** | **劣势** |
+| --- | --- | --- | --- |
+| 向量检索 | 基于语义相似度匹配 | 理解语义，支持模糊匹配 | 精确关键词匹配较弱 |
+| 关键词检索（BM25） | 基于关键词匹配和词频统计 | 精确匹配强，速度快，成本低 | 不理解语义，同义词匹配差，这也就是以前智能客服机器人很智障的原因 |
+| **混合检索（推荐）** | 结合向量检索 + 关键词检索 | 兼顾语义和精确匹配 | 系统复杂度略高 |
+
+### 2.3 重排序（Rerank）
+
+重排序的目标是：在“第一阶段检索”拿到的一批候选证据里（通常 20–200 条），用更强但更慢的模型做**精排**，把真正与问题最相关的 Top-N（通常 3–10 条）挑出来。
+
+**（1）为什么需要重排序？**
+
+-   **向量检索的打分不够“精确”**：Embedding 更像“粗筛”，擅长语义相近，但对细节约束（时间、条件、否定、数字）不敏感。
+    
+-   **混合检索会带来噪声**：BM25 和向量检索合并后，召回更高，但不相关片段也会混入。
+    
+-   **Top-K 不能太大也不能太小**：
+    
+    -   开得太大：Prompt 变长、成本上升、注意力被稀释；
+        
+    -   开得太小：容易漏掉关键信息，准确度降低。
+        
+    
+    Rerank 让你“先多召回，再精挑”。
+    
+
+**（2）它到底做了什么？**
+
+把问题和每条候选片段**拼成一对**（Query, Doc），用模型直接判断“这条证据对回答问题有多有用”，输出一个相关性分数，然后排序。
+
+**（3）实现方式**
+
+把 Query 和 Doc 放在一起编码，直接输出相关性分数。
+
+-   优点：精度高，能理解细粒度约束（条件、时间、否定、数值）。
+    
+-   缺点：需要对每条候选都跑一次推理，成本随候选数线性增长。
+    
+
+工作流程：
+
+```python
+用户问题: "七天无理由退货包运费吗？"
+        ↓
+第一阶段：向量检索召回 Top-50 条候选片段
+        ↓
+第二阶段：Cross-Encoder 逐一打分
+  - ("七天无理由退货包运费吗？", 片段1) → 0.92
+  - ("七天无理由退货包运费吗？", 片段2) → 0.87
+  - ("七天无理由退货包运费吗？", 片段3) → 0.23
+        ↓
+按分数排序，取 Top-5 + 过滤低于阈值的 → 送入 LLM
+```
+
+代码实现最常用的是**Hugging Face** 的`sentence-transformers` 库
+
+```python
+from sentence_transformers import CrossEncoder
+
+# 1. 加载模型（常用模型见下方）
+model = CrossEncoder("BAAI/bge-reranker-v2-m3")
+
+# 2. 构造 (query, doc) 对
+query = "七天无理由退货包运费吗？"
+docs = ["退货运费由买家承担", "定制类不支持无理由退货", "..."]
+pairs = [(query, doc) for doc in docs]
+
+# 3. 打分
+scores = model.predict(pairs)
+
+# 4. 按分数排序，取 Top-N
+ranked = sorted(zip(docs, scores), key=lambda x: x[1], reverse=True)
+top_docs = [doc for doc, score in ranked[:5] if score > 0.3]
+```
+
+**（4）常见 Rerank 模型选型**
+
+**闭源商业 API**
+
+| **模型名称** | **特点与适用场景** |
+| --- | --- |
+| Cohere `Rerank` | 业界顶流，多语言支持极佳，API 接入简单，适合不想自己部署、追求极致效果的场景 |
+| Jina `Reranker v2` | 支持多语言和长文档，性价比高 |
+
+**开源私有化部署**
+
+| **模型名称** | **特点与适用场景** |
+| --- | --- |
+| `BAAI/bge-reranker-v2-m3` | 中文效果最佳的开源方案，支持多语言，闭眼选默认方案 |
+| `cross-encoder/ms-marco-MiniLM-L-6-v2` | 轻量级，速度快，适合英文场景和对延迟敏感的应用 |
+
+<br>
+
+**选型建议：**
+
+-   **0-1 测试项目**：直接用 Cohere Rerank API，省心。
+    
+-   **企业级应用**：本地部署 `bge-reranker-v2-m3` 是目前最稳妥的方案。
+    
+-   **在 Dify / FastGPT 等平台中**：直接在知识库设置里开启 Rerank 并选模型即可，无需写代码。
+    
+
+**（5）关键参数怎么选**
+
+-   **Top-K（召回数）**：常见 20–100 起步；知识库噪声大时可更高，但要配合重排序。
+    
+-   **Top-N（送入生成的证据数）**：常见 3–8；如果答案需要多条证据拼接，可提高到 10–15。
+    
+-   **阈值过滤（score threshold）**：低于阈值的证据不喂给 LLM，减少“带着错证据生成”。
+    
+
+**（6）最小可用实现（推荐路径）**
+
+1.  先用向量或混合检索拿 Top-K。
+    
+2.  用 Cross-Encoder rerank 得到排序。
+    
+3.  取 Top-N + 分数阈值过滤。
+    
+4.  在 Prompt 里要求模型“只基于证据回答，并引用片段来源”。
+    
+
+### 2.4 构建 Prompt
+
+将用户原始问题 + 检索到的相关内容组装成增强 Prompt，明确指示模型"只能依据以下资料回答"。
+
+**Prompt 模板示例：**
+
+```
+你是一个专业的客服助手。请根据以下参考资料回答用户问题。
+如果参考资料中没有相关信息，请诚实告知用户。
+
+【参考资料】
+{检索到的文档片段}
+
+【用户问题】
+{用户的原始提问}
+
+请基于参考资料给出准确、简洁的回答，并标注信息来源。
+```
+
+### 2.5 LLM 生成回答
+
+大模型基于增强 Prompt 生成最终回答，并可以引用来源，方便用户验证。
+
+# **五. 效果评估**
+
+RAG 系统的效果评估通常可以划分为 **黑盒评估** 和 **白盒评估** 两种方式。
+
+## 1\. 黑盒评估
+
+黑盒评估将整个 RAG 系统视为一个“黑盒”，不关心中间检索了什么文档，只关心 **“用户输入问题”** 后，**“系统最终输出的回答”** 质量如何。通常适合用来向业务方汇报系统整体可用性。
+
+### 1.1 **人工评估**
+
+由人类评估员（如产品经理、业务专家、数据标注员）对 RAG 系统的最终输出进行抽检和打分。
+
+-   **常见形式**：人工抽检的准确率、Bad Case 的归因分析等。
+    
+-   **优点**：**准确度最高**，人工抽检是最终的“黄金标准”，能发现自动化评估和模型难以察觉的微妙业务错误或常识问题。
+    
+-   **缺点**：**成本高、周期长**，耗费人力，无法做到高频、实时的自动化反馈；且评估标准有时难以完全统一，存在一定主观性。
+    
+
+### 1.2 **业务指标评估**
+
+基于真实的线上业务数据和用户行为反馈，来衡量 RAG 系统在真实场景下的表现。
+
+-   **常见指标**：
+    
+    -   **用户侧**：每次 AI 独立结束会话后推送的 1-5 星评价、点赞/点踩率等。
+        
+    -   **业务侧**：如智能客服的转人工率、拦截率、问题解决率等。
+        
+-   **优点**：**贴近真实业务**，能直接反映 RAG 系统带来的最终商业价值和真实用户体感（比如到底省了多少客服人力）。
+    
+-   **缺点**：反馈数据往往存在 **稀疏性**（用户主动留评率通常很低）；且评价有时容易受到产品规则或用户情绪的干扰，存在噪音（例如用户对公司退货政策本身不满，而不是对 AI 回答不满，却给 AI 打了 1 星）。
+    
+
+### 1.3 **LLM-as-a-Judge（大模型裁判）**
+
+利用 GPT-5 等高级模型作为裁判进行打分，这在自动化评估中非常流行。
+
+RAGAS是目前业界非常流行的基于 **LLM-as-a-Judge** 的 RAG 自动化评估框架。它无需大量人工标注的“标准答案”，而是让大模型自己去对比“问题”、“检索到的上下文”和“生成的答案”，给出多维度的评分。
+
+-   **Faithfulness（忠实度）**：最终答案是否完全基于检索到的上下文生成的？有没有胡编乱造？（评估生成幻觉）
+    
+-   **Context Precision（上下文精确度）**：检索到的上下文中，真正有用的信息是否排在前面？（评估检索排序）
+    
+-   **Context Recall（上下文召回率）**：检索到的上下文是否包含了回答问题所需的全部信息？（评估检索覆盖度）
+    
+-   **Answer Relevance（答案相关性）**：最终答案有没有直接回答用户的原始问题？（评估生成质量）
+    
+
+**RAGAS 基础使用示例（Python）：**
+
+```python
+from datasets import Dataset
+from ragas import evaluate
+from ragas.metrics import (
+    faithfulness,
+    answer_relevance,
+    context_recall,
+    context_precision,
+)
+
+# 1. 准备评估数据（通常是 RAG 系统运行后记录的真实日志）
+data_samples = {
+    "question": ["七天无理由退货包运费吗？"], # 用户提问
+    "answer": ["一般商品退货运费由买家承担，生鲜类不支持七天无理由。"], # RAG 生成的最终回答
+    "contexts": [
+        ["七天无理由退货的退货运费由买家承担。", "生鲜类商品不适用七天无理由退货政策。"]
+    ], # RAG 检索到的文档片段
+    "ground_truth": ["不包运费，由买家承担。生鲜不支持。"] # 人工标准答案（部分指标如 Recall 需要）
+}
+# 将数据转换为 HuggingFace Dataset 格式
+dataset = Dataset.from_dict(data_samples)
+
+# 2. 执行评估
+# 注：RAGAS 默认调用 OpenAI 的大模型作为裁判，需要配置环境变量 OPENAI_API_KEY
+result = evaluate(
+    dataset=dataset,
+    metrics=[
+        context_precision,
+        context_recall,
+        faithfulness,
+        answer_relevance,
+    ],
+)
+
+# 3. 输出评分（0~1分，分数越高越好）
+print(result)
+# 输出类似：{'context_precision': 1.0, 'context_recall': 1.0, 'faithfulness': 1.0, 'answer_relevance': 0.95}
+```
+
+## 2\. 白盒评估
+
+白盒评估是将 RAG 系统拆解开，分别对 **检索与重排阶段（Retrieval）** 和 **生成阶段（Generation）** 进行独立诊断，精准定位问题（是没搜到，还是生成错了），适合产品经理和研发用来调优。
+
+### 2.1 检索与重排阶段评估
+
+主要评估 **“有没有捞到相关信息，且排得靠不靠前”**：
+
+| **指标** | **含义** | **适合场景** |
+| --- | --- | --- |
+| **Recall@K**（召回率） | 在返回的前 K 条结果中，命中了多少条真正相关的内容。关注"**有没有捞到**"，不关心排在第几位。 | <br> |
+
+例：标准答案需要 3 条证据，你检索 Top-10 里命中了 2 条 → Recall@10 = 2/3 ≈ 66.7% | 评估召回覆盖度，K 越大召回越高但噪声也越多 | | **MRR**（平均倒数排名） | 第一条正确结果排在第几位，取其倒数，再对所有查询求平均。关注"**最相关的那条排得多靠前**"
+
+例：Query A 第一条正确结果在第 2 位 → 1/2；Query B 在第 1 位 → 1/1；MRR = (0.5 + 1) / 2 = 0.75 | 只需命中一条关键证据的场景（如 FAQ） | | **NDCG**（归一化折损累积增益） | 不仅看是否命中，还看**相关度高的结果是否排得更靠前**，排名越靠后得分"打折"越狠。关注"**整体排序质量**"
+
+例：假设有 3 条结果，相关度分别为 3、2、1（3 最相关）。如果实际排序把相关度 3 排第一，得分最高；如果把 1 排第一，虽然也命中了，但 NDCG 会低很多。 | 需要多条证据、且证据重要性有差异的场景 |
+
+### 2.2 生成阶段评估
+
+主要评估 **“大模型基于检索到的内容，发挥得怎么样”，**评估方法：**受控生成测试。**
+
+-   **实现思路：**我们不再让模型去自己检索，而是直接将"金上下文"(GoldenContext，即人工准备的、最完美的上下文信息)和用户问题一起喂给生成模型。
+    
+-   **核心目标：**通过控制输入，我们可以隔离生成模型的能力，专门评估它在理解和总结给定信息上的表现，而不用担心它被糟糕的检索结果所干扰。
+    
+-   **评估指标：在这种受控环境下，我们可以再次使用忠实度（Faithfulness）和答案相关性（Answer Relevancy）**这两个指标。但此时，它们衡量的就是生成模型纯粹的"看文说话"能力。如果此时的忠实度依然很低，那就说明问题出在生成模型本身，它可能过于"富有想象力"，需要通过调整Prompt或进行微调来约束。
+    
+
+# 六. RAG 的演进方向
+
+## **1\. 初级 RAG**
+
+最基础的"检索 + 生成"流程，适合入门和简单场景
+
+## **2\. 进阶 RAG**
+
+引入查询改写、混合检索、重排序、答案合成等优化手段，显著提升效果
+
+## **3\. 代理式 RAG**
+
+Agentic RAG 是当前 RAG 领域最受关注的演进方向，核心思路是将 **AI Agent（智能体）引入 RAG 管道**，让系统从"固定流水线"进化为"自主决策的智能体系统"。
+
+<br>
+
+**一句话理解**：传统 RAG 像一台自动售货机（投入问题 → 固定流程 → 吐出答案），Agentic RAG 像一个会思考的研究助理（拿到问题 → 判断该查哪里 → 查完不满意再换个方式查 → 综合多轮结果给出答案）。
+
+<br>
+
+**Agentic RAG 的四大设计模式：**
+
+1.  **反思（Reflection）**：Agent 对检索结果和生成内容进行自我评估，质量不达标就重新检索
+    
+2.  **规划（Planning）**：将复杂问题拆解为多个子任务，制定执行计划，逐步完成
+    
+3.  **工具使用（Tool Use）**：不仅能查向量库，还能调用搜索引擎、数据库、API 等外部工具
+    
+4.  **多智能体协作（Multi-Agent）**：多个专门化的 Agent 各司其职（检索 Agent、分析 Agent、生成 Agent），协作完成复杂任务
+    
+
+**传统 RAG vs Agentic RAG：**
+
+| **维度** | **传统 RAG** | **Agentic RAG** |
+| --- | --- | --- |
+| 工作方式 | 固定流程：检索 → 拼 Prompt → 生成 | Agent 动态决策：要不要检索、检索哪里、要不要再查一次 |
+| 数据源 | 通常单一知识库 | 可跨多个数据源、工具、API 灵活调度 |
+| 复杂问题 | 只能一次性检索，难以处理多跳问题 | 支持多步推理，迭代检索，逐步逼近答案 |
+| 自我纠错 | 无，检索到什么就用什么 | Agent 可反思检索质量，判断是否需要补充检索 |
+| 适用场景 | 简单知识问答、FAQ | 复杂分析、跨领域推理、多步任务 |
+
+# 七. RAG 实战清单
+
+作为 AI 产品经理，在落地一个 RAG 项目时，需要包含以下步骤：
+
+## 1\. 知识库建设
+
+-   明确数据源范围（哪些文档需要纳入？）
+    
+-   确定数据更新机制（多久更新一次？）
+    
+-   选择合适的 Embedding 模型
+    
+-   确定分片策略和参数
+    
+-   数据质量保障流程（清洗、去重、格式化）
+    
+
+## 2\. 检索策略
+
+-   选择检索方式（向量检索 / 关键词检索 / 混合检索）
+    
+-   是否需要查询改写和意图识别
+    
+-   是否引入 Rerank 重排序，如果引入选择哪个 Rerank 模型
+    
+-   确定 Top-K和Top-N 参数
+    
+
+## 3\. 生成策略
+
+-   设计高质量的 Prompt 提示词
+    
+-   选择合适的生成模型（性能 vs 成本权衡）
+    
+-   是否需要答案溯源和引用标注
+    
+-   兜底策略设计（检索不到相关内容时如何处理）
+    
+
+## 4\. 效果评估
+
+-   定义和监控评估指标
+    
+-   建立测试集（覆盖核心业务场景的 Q&A 对）
+    
+-   线上 Bad Case 收集与归因闭环
+    
+
+**记住**：RAG 系统的效果 = 知识库质量 × 检索质量 × 生成质量。三个环节环环相扣，任何一个短板都会拖累整体效果。作为产品经理，核心工作就是在这三个环节之间找到最优平衡。

2. 进阶篇/2.4 Agent.md

@@ -0,0 +1,405 @@
+## 一、什么是Agent（智能体）
+
+大模型上知天文下知地理，你问它什么它答什么，但是它有个最大的缺陷，就是没有“手”不能干活。
+
+而Agent（智能体）相当于是给大模型装上了“手”，让它可以感知外部世界、思考并采取行动。
+
+**LLM**
+
+用户输入指令→模型检索知识后回答
+
+**Agent**
+
+用户输入指令→Agent自主识别可用的工具进行调用，给用户交付结果
+
+传统编程、Workflow和Agent 的区别：
+
+-   **传统编程：**程序员在做决策，把所有可能的情况都提前想好，写成代码；
+    
+-   **Workflow：**产品/开发在做决策，设计固定的流程路径；
+    
+-   **Agent：**AI 在做决策，根据实际情况动态调整策略；
+    
+
+## 二、Agent核心原理
+
+目前，Agent 基本采用 ReAct 模式。该模式由姚顺雨等人于 2022 年在《[ReAct: Synergizing Reasoning and Acting in Language Models](https://blog.csdn.net/weixin_44191845/article/details/148403313)》一文中提出，其核心思想是将推理（Reasoning）与行动（Acting）相结合。CoT 思维链主要提升 LLM 的推理能力，但由于缺少与外部世界的交互，难以获得外部反馈来拓展知识空间；ReAct 在一定程度上弥补了这一不足。
+
+ReAct Agent 的工作方式很像人类解决问题的过程：在整体目标明确的前提下，边做边调整。具体来说，它会先观察当前情况，再思考下一步行动，随后执行动作并观察结果，最后根据结果决定下一步。上述过程不断循环，直到任务完成。
+
+-   **思考**（Reasoning）：帮助模型分解任务、制定计划、跟踪进度、处理异常、识别信息需求。这本质上是LLM的内部"独白"或元认知。
+    
+-   **行动**（Action）：允许模型与外部世界（如知识库API、交互式环境）交互，以获取当前思考步骤所需的信息，或执行计划中的某个具体操作。
+    
+-   **观察**：（Observation)：行动的结果，反馈给模型，作为下一步思考的依据。
+    
+
+ReAct 的实现主要依赖于精心设计的 `Few-Shot Prompting`[https://github.com/ysymyth/ReAct。Prompt](https://github.com/ysymyth/ReAct%E3%80%82Prompt) 中包含若干个“思考-行动-观察”的完整轨迹示例，指导 LLM 在新的任务实例上生成类似的交错序列。
+
+对于 Agent 应用开发者而言，无需在提示词中额外加入这些示例来引导模型生成。大多数模型厂商已在 API 内部进行了处理，一般通过 **Function Calling** （\*\*函数调用）\*\*的方式实现。
+
+## 三、Agent运行流程
+
+![](../.resources/image-1778904762459.png)![](../.resources/image-1778904772586.png)
+
+工具调用具体过程
+
+以天气查询为例，用户指令：今天上海天气怎么样？
+
+1.  **初始化：**Agent 接收用户指令初始化上下文，并定义一个天气查询工具 `get_weather`
+    
+
+```python
+# 初始化上下文
+messages = [
+   {
+       "type": "message",
+       "role": "user",
+       "content": "查询北京今天的天气"
+   }
+]
+# 定义工具
+tools = [
+    {
+        "type": "function",
+        "name": "get_weather",
+        "description": "根据城市名称查询该城市当日天气（含温度、天气状况）",
+        "parameters": {
+            "type": "object",
+            "properties": {
+                "location": {
+                    "type": "string",
+                    "description": "城市名称，如北京、上海（仅支持国内地级市）"
+                }
+            },
+            "required": ["location"]
+        }
+    }
+]
+```
+
+2.  **第一轮请求：**将上下文和工具定义发送给大模型，大模型返回 `function_call` \*\*\*\*类型指令，包括工具名`name`和参数`arguments`，告诉Agent需要调用工具。
+    
+
+```python
+{
+    "created_at": 1756980000,
+    "id": "resp_02175698000123456789abcdef0123", 
+    "model": "doubao-seed-1-6-251015",
+    "object": "response",
+    "output": [
+        {
+            "arguments": "{\\"location\\":\\"北京\\"}", 
+            "call_id": "call_abc123def456ghi789jkl0",
+            "name": "get_weather",
+            "type": "function_call",
+            "id": "fc_02175698000abcdef0123456789gh",
+            "status": "completed"
+        }
+    ],
+    "status": "completed",
+    "store": true,
+    "expire_at": 1757239200
+}
+```
+
+3.  **执行工具调用：**Agent `响应控制器`中解析响应数据，发现返回了 `function_call` \*\*\*\*类型指令，然后根据工具名和参数去调用外部的天气API获取天气数据。获取后将模型响应数据和查询到的天气数据存入上下文。
+    
+
+```python
+{
+    "city": "北京",
+    "date": "2025-10-13",
+    "temperature": "18~28℃",
+    "condition": "晴转多云",
+    "wind": "东北风2级"
+}
+```
+
+4.  **第二轮请求：**将上下文发送给模型生成最终响应。
+    
+
+```python
+curl <https://ark.cn-beijing.volces.com/api/v3/responses> \\
+  -H "Authorization: Bearer $ARK_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "model": "doubao-seed-1-6-251015",
+    "previous_response_id": "resp_02175698000123456789abcdef0123",  # Associate with the previous request
+    "input": [
+        {
+            "type": "function_call_output",  # Return tool results
+            "call_id": "call_abc123def456ghi789jkl0",   #  Consistent with the call_id of the instruction
+            "output": "{\\"city\\":\\"北京\\",\\"date\\":\\"2025-10-13\\",\\"temperature\\":\\"18~28℃\\",\\"condition\\":\\"晴转多云\\",\\"wind\\":\\"东北风2级\\"}"
+        }
+    ]
+  }'
+```
+
+最终响应如下，响应控制器解析响应发现没有 `function_call` \*\*\*\*指令了，说明本次指令模型完成处理了，则可以直接返回模型的结果：北京今天（2025-10-13）的天气为晴转多云，气温在18~28℃之间，东北风2级。否则继续执行工具调用。
+
+```python
+{
+    "created_at": 1756980100,
+    "id": "resp_02175698010abcdef0123456789gh",
+    "model": "doubao-seed-1-6-250615",
+    "object": "response",
+    "output": [
+        {
+            "type": "message",
+            "role": "assistant",
+            "content": [
+                {
+                    "type": "output_text",
+                    "text": "北京今天（2025-10-13）的天气为晴转多云，气温在18~28℃之间，东北风2级。"
+                }
+            ],
+            "status": "completed",
+            "id": "msg_02175698010abcdef0123456789ij"
+        }
+    ],
+    "status": "completed",
+    "store": true
+}
+```
+
+## 四、MCP
+
+<br>
+
+对于产品经理来说，不需要了解MCP协议具体是如何实现的、如何开发一个MCP。
+
+只需要了解：MCP概念、交互流程、判断是使用已有MCP还是自己开发、以及MCP需要什么参数和返回什么响应数据。
+
+就像我们只需要了解前后端是什么、前后端是如何交互的、判断是使用外部现成 API 还是自己开发一样、以及API需要什么参数和返回什么响应数据一样，便于我们和技术更好的沟通。
+
+<br>
+
+### 1\. MCP解决了什么问题
+
+**Function Calling** 解决了核心问题：让LLM能够稳定地输出结构化的工具调用请求，实现了"非结构化→结构化"的转换。这是AI Agent工具能力的基础。
+
+但在实际应用中，开发者很快发现了几个新的问题：
+
+1.  每个工具的API接口都不一样，需要特殊适配。
+    
+2.  在A应用里做了适配，B应用里又得适配一遍，无法复用。
+    
+
+这时候，MCP（Model Context Protocol 模型上下文协议）作为一个连接应用和工具的桥梁就派上用场了。
+
+举个例子：
+
+我们的AI应用是台笔记本电脑，每个工具是外接设备（摄像头、显示器、鼠标、键盘…）。
+
+-   **MCP出现之前：**每个外接设备都使用不同的端口（HDMI、Type-C、VGA….），每台笔记本电脑都要适配各种端口，不仅端口特别多，而且出现了新的设备又得进行适配。另外，不同品牌适配的端口也可能存在差异。
+    
+-   **MCP出现之后：**MCP相当于Type-C设备端口，不同外接设备厂商只要支持Type-C端口，就可以在所有支持Type-C端口的电脑上使用，而不同笔记本厂商只要支持Type-C端口，也就可以使用所有支持Type-C端口的外接设备。
+    
+
+![](../.resources/image-1778904815118.png)![](../.resources/image-1778904822749.png)
+
+### 2\. Agent、大语言模型和MCP是如何交互的
+
+-   **Agent**：整个系统的编排中心（如 Claude Desktop、Cursor 或自定义 App），负责管理用户交互、协调大语言模型调用与 MCP 客户端 通信，进行权限管理。Agent 内部包含 MCP 客户端 和 大语言模型调用逻辑。
+    
+-   **大语言模型**：Agent 内部调用的推理引擎，负责理解用户意图、决策是否调用工具，并生成结构化的工具调用请求（function\_call）或最终回答。
+    
+-   **MCP 客户端**：Agent 内部的通信模块，负责与 MCP 客户端 建立连接、发现能力、转发工具调用请求并接收结果。
+    
+-   **MCP 服务端**：独立运行的外部服务，提供具体的工具和资源（如 Google Drive 读取器、SQLite 数据库接口等），响应 MCP 客户端 的请求并返回执行结果。
+    
+
+```mermaid
+sequenceDiagram
+    autonumber
+    
+    actor User as 用户 (User)
+    participant Host as Agent
+    participant LLM as 大语言模型
+    participant Client as MCP 客户端 (内部模块)
+    participant Server as MCP 服务端
+
+    Note over Host,Client: Agent 集成了 MCP 客户端
+
+    %% ================= Phase 1: 连接与初始化 =================
+    Note over Client,Server: 阶段一：连接
+    
+    Host->>Client: 1. 读取 MCP 配置，启动 Client
+    Client->>Server: 2. 请求连接
+    Server-->>Client: 3. 连接成功
+    
+    %% ================= Phase 2: 能力发现 =================
+    Note over Client,Server: 阶段二：能力发现
+    Client->>Server: 4. 拉取可用工具列表、资源列表
+    Server-->>Client: 5. 返回工具、资源清单
+    Client-->>Host: 6. 将发现的工具、资源返回给Agent
+
+    %% ================= Phase 3: 核心交互与执行 =================
+    Note over User,Server: 阶段二：用户交互与任务执行
+    
+    User->>Host: 7. 发送自然语言指令<br/>(例如: "分析服务器日志资源并总结")
+    Host->>LLM: 8. 用户指令 + 工具定义
+    
+    Note over LLM: 9. 推理决定是否需要调用工具
+    
+    LLM-->>Host: 返回 function_call 指令<br/>(工具名 + 参数)
+    
+    Host->>Client: 10. 解析指令，转发工具调用请求
+    
+    Client->>Server: 11. 发送工具调用请求
+    Server-->>Client: 12. 返回工具执行结果
+    
+    Client-->>Host: 13. 返回执行结果
+    Host->>LLM: 14. 将工具结果注入上下文，再次请求 LLM
+    
+    Note over LLM: 15. 综合上下文生成最终回答
+    
+    LLM-->>Host: 返回最终文本响应
+    Host-->>User: 16. 输出最终结果
+```
+
+### 3\. 如何使用MCP
+
+阿里魔塔（[https://modelscope.cn/mcp）上集成了近万个MCP，可以搜索和筛选需要的MCP。](https://modelscope.cn/mcp%EF%BC%89%E4%B8%8A%E9%9B%86%E6%88%90%E4%BA%86%E8%BF%91%E4%B8%87%E4%B8%AAMCP%EF%BC%8C%E5%8F%AF%E4%BB%A5%E6%90%9C%E7%B4%A2%E5%92%8C%E7%AD%9B%E9%80%89%E9%9C%80%E8%A6%81%E7%9A%84MCP%E3%80%82)
+
+![](../.resources/image-1778904851109.png)
+
+在MCP详情中有个服务配置，就是MCP配置数据，可以通过Remote或者stdio进行调用。
+
+| 对比项 | Remote（远程调用） | Stdio（本地进程标准输入输出） |
+| --- | --- | --- |
+| 连接方式 | 通过网络请求连接远程服务器上的 MCP Server，只需填一个 URL 地址即可。 | 在本地启动一个进程，通过标准输入（stdin）和标准输出（stdout）与 MCP Server 通信，MCP Server 和你的应用运行在同一台机器上。 |
+| 优点  | 不需要本地安装任何依赖，配置简单，填个地址就能用。 | 本地通信开销小，通常更低延迟 |
+| 缺点  | 受网络、带宽影响，可能更高延迟 | 需要在本地安装对应的运行环境（如 Node.js、Python 等）和相关依赖包，配置相对复杂。 |
+| 适用场景 | 适合快速体验、轻量集成、不想管理本地环境的场景。 | 适合对性能和安全性要求较高、需要频繁调用的生产环境。 |
+
+![](../.resources/image-1778904872406.png)![](../.resources/image-1778904888142.png)
+
+## 五、Skill
+
+**Skill 是由 Anthropic 于 2025 年 10 月提出的一种开放标准**，核心思想是把指令、脚本和资源打包成一个标准化的文件夹（"技能包"），让 AI Agent 能够按需动态加载和执行特定任务。
+
+### 1\. Skill 解决了什么问题
+
+**Function Calling** 让 LLM 能调用工具，**MCP** 统一了工具接口标准。但在实际应用中，还有一个问题没解决：
+
+1.  Agent 虽然通用能力很强，但缺乏特定领域的专业知识和流程。
+    
+2.  每次都要在 System Prompt 里塞入大量指令，导致上下文污染、复用性差。
+    
+
+这时候，**Skill（代理技能）** 就派上用场了。Skill 由 Anthropic 于 2025 年 10 月提出，是一种开放式构建标准，核心是将复杂的业务逻辑、操作指令和外部知识封装为标准化的模块，让 AI Agent 能像调用"技能包"一样，按需动态加载和执行特定任务。
+
+举个例子：
+
+Agent 就像一个刚入职的新员工，虽然综合素质很强（大模型能力），但对公司业务流程一无所知。
+
+-   **Skill 出现之前：**每次给新员工布置任务，都要口头从头讲一遍完整流程（把所有规则塞进 System Prompt），不仅费时费力，而且容易遗漏。
+    
+-   **Skill 出现之后：Skill 相当于给新员工准备了一套标准化的岗位 SOP 手册**，需要做什么任务就翻对应的手册，里面有详细的操作指令、脚本和参考资料，按需查阅即可。
+    
+
+### 2\. Skill 的组成
+
+一个 Skill 本质上就是一个包含 `SKILL.md` 的文件夹，结构如下：
+
+```
+my-skill/
+├── SKILL.md          # 入口文件：技能描述、触发条件、基本指令
+├── scripts/          # 可执行脚本（Python、Shell 等）
+├── templates/        # 模板文件（报告模板、代码模板等）
+└── resources/        # 参考资料（文档、数据、示例等）
+```
+
+-   [**SKILL.md**](http://SKILL.md)**（入口文件）**：描述这个技能是做什么的、什么时候触发、基本操作指令
+    
+-   **scripts（脚本）**：可执行的代码，让 Agent 从"建议者"变为"执行者"
+    
+-   **templates（模板）**：标准化的输出模板
+    
+-   **resources（资源）**：参考文档、数据等辅助材料
+    
+
+### 3\. 核心机制：渐进式披露
+
+Skill 采用**渐进式披露**（Progressive Disclosure）机制，信息按需分级加载，而不是一次性全部塞入上下文：
+
+**传统 System Prompt**
+
+所有规则一次性全量塞入上下文→Token 浪费、注意力分散、指令漂移
+
+**Skill 渐进式披露**
+
+Agent 按需加载技能片段→Token 高效利用、执行精准
+
+具体分为三个层级：
+
+1.  **目录层（低成本）**：Agent 平时只知道有哪些 Skill 可用（相当于只看手册目录）
+    
+2.  **摘要层（按需加载）**：当用户请求匹配某个 Skill 时，加载该 Skill 的详细指令
+    
+3.  **执行层（深度加载）**：需要执行具体操作时，加载脚本、模板等完整资源
+    
+
+### 4\. Skill vs MCP
+
+| 对比项 | Skill（工作手册 📖） |
+| --- | --- |
+| 定位  | 教 Agent **怎么做**：封装流程、知识、指令 |
+| 组成  | [SKILL.md](http://SKILL.md) • 脚本 + 模板 + 资源 |
+| 加载方式 | 渐进式披露，按需加载 |
+| 关系  | **互补关系**：一个 Skill 内部可以调用 MCP 提供的工具来完成任务。Skill 定义"做什么、怎么做"，MCP 提供"用什么工具做"。 |
+
+简单来说：**Skill 是 SOP 手册，MCP 是工具箱。** 手册里会写"第三步用扳手拧螺丝"，而扳手就是通过 MCP 提供的。
+
+### 5\. 应用场景
+
+Skill 特别适合需要**标准化、流程化**的企业任务：
+
+-   **客户服务**：封装投诉处理、退换货等特定流程的 SOP
+    
+-   **数据分析**：根据文件类型自动选择分析方法并生成报告
+    
+-   **文档编辑**：如 Claude 的 PDF 编辑功能，就是通过 PDF Skill 实现的
+    
+
+### 6\. 如何使用 Skill
+
+Skill 目前已获得多个平台的支持：
+
+| 平台  | 支持状态 | 使用方式 |
+| --- | --- | --- |
+| Claude Code | 完整支持 | 原生集成 |
+| [Claude.ai](http://Claude.ai) | 完整支持 | 设置上传 |
+| VS Code | 完整支持 | chat.useAgentSkills |
+| Cursor | 完整支持 | 文档支持 |
+| GitHub Copilot | 完整支持 | 原生集成 |
+| OpenAI Codex | 完整支持 | 官方支持 |
+
+Anthropic 官方 Skill 仓库：[https://github.com/anthropics/skills](https://github.com/anthropics/skills)
+
+Agent Skills 开放标准官网：[https://agentskills.io](https://agentskills.io)
+
+## 六、Harness
+
+![](../.resources/image-1778904905130.png)
+
+Agent = Model + Harness。
+
+图中最核心的位置是 Model——那个蓝色芯片图标，代表 Claude 的大语言模型。但模型本身只是一个推理引擎，它不能独立行动。真正让它变成 Agent 的，是包裹在它周围的五个 Harness 组件。
+
+-   **Tools（工具），**模型的手脚。Read、Write、Edit、Bash、Grep……这些工具赋予模型与文件系统、终端、网络交互的能力。没有工具，模型只能说，不能做。
+    
+-   **Context（上下文）**，模型的记忆加载器。[CLAUDE.md](http://claude.md/)、系统提示词、对话历史、工具定义——这些上下文在每一轮循环中被注入模型，决定了模型看到什么、知道什么。上下文管理的精妙之处是，它不仅是被动的信息传递，还包括主动的压缩和重注入策略。
+    
+-   **Memory（记忆）**，模型的长期存储。跨会话的记忆持久化，让模型能“记住”你的偏好、项目规则和历史决策。[CLAUDE.md](http://claude.md/) 是显式记忆，自动记忆（~/.claude/memory/）是隐式记忆。没有 Memory，每次对话都从零开始。
+    
+-   **Hooks（钩子）**，模型的神经反射。事件驱动的自动化机制，在工具执行前后触发自定义逻辑。比如每次保存文件前自动格式化，每次提交前自动运行 lint。Hooks 让 Harness 有了“条件反射”的能力——不需要模型主动决策，某些行为会自动发生。
+    
+-   **Permissions（权限）**——模型的安全围栏。哪些工具可以自由使用，哪些需要人工审批，哪些完全禁止——权限系统是 Harness 的安全底线。它解决了一个核心矛盾：你希望 Agent 足够自主以提高效率，但又不希望它自主到失控。
+    
+
+注意图中的空间关系：Model 在中心，五个组件围绕它排列，整体被一个名为 Harness 的边框包裹。这不是随意的布局，它精确表达了一个架构事实：模型不直接接触外部世界，所有交互都通过 Harness 的组件中转。Harness 是模型和现实之间的唯一接口。
+
+这五个组件也不是孤立的。Tools 的执行结果变成 Context 的一部分；Hooks 在 Tools 执行前后触发；Permissions 决定哪些 Tools 可以被调用；Memory 用于跨会话保留 Context 中的关键信息。它们构成了一个协同运转的系统，少了任何一个，Agent 的能力都会大打折扣。

3. 实战篇（客服Agent)/3.1 项目计划.md

@@ -0,0 +1,19 @@
+一家电商公司有100+客服，公司希望建设智能客服，提升客服接待效率，降低人力成本，提升客户体验。
+
+| 阶段  | 责任方 | 任务项 | 时间  |
+| --- | --- | --- | --- |
+| **一、需求分析** | 产品/客服/运营 | 1\. 目标/愿景分析  <br>2\. 干系人识别和分析  <br>3\. 详细需求分析 | 第 1-3 周 |
+| **二、整体设计** | 产品/开发 | 1\. 产品架构设计  <br>2\. 技术方向选型  <br>3\. 产品路线图规划 | 第 4-5 周 |
+| **三、详细设计** | 产品/开发 | 1\. 知识库设计：数据源范围、更新机制、分片策略  <br>2\. 检索策略设计  <br>3\. 工具调用设计（订单查询、商品查询等）  <br>4\. Prompt 设计：系统提示词、品牌调性、转人工策略  <br>5\. 评测流程、指标和看板设计 | 第 6-8 周 |
+| **四、测试数据集构建** | 产品/客服 | 基于场景和方案设计标注评测集 | 第 9-10 周 |
+| **五、模型选型** | 产品/开发 | 候选模型评测与选型 | 第 10-12 周 |
+| **六、知识库构建** | 产品/客服/运营 | 知识库整理、清洗和入库 | 第 12-14 周 |
+| **七、开发** | 开发/产品 | 知识库问答模块、工具调用模块、企微客服接口对接  <br>数据埋点与监控看板开发 | 第 13-20 周 |
+| **八、Prompt 调优** | 产品/客服 | 基于评测集反复调优 Prompt、检索策略和兜底逻辑 | 第 18-22 周 |
+| **九、安全合规审查** | 产品/开发/法务 | 敏感信息过滤、兜底策略、异常处理机制验收 | 第 22-23 周 |
+| **十、验收测试** | 产品/测试/客服 | 根据历史对话和评测集进行准确度测试 | 第 23-24 周 |
+| **十一、灰度测试** | 产品/客服/运营 | 30% 客服账号切换至智能客服，观测核心指标 | 第 25-27 周 |
+| **十二、全量上线** | 开发/产品 | 全部客服账号切换至智能客服 | 第 28 周 |
+| **十三、持续运营** | 产品/客服/运营 | 收集 badcase → 分析原因 → 改进策略和知识库 | 持续  |
+
+<br>

3. 实战篇（客服Agent)/3.2 需求分析.md

@@ -0,0 +1,185 @@
+## （一）目标/愿景分析
+
+### 1\. 业务现状
+
+通过企业微信客服接待顾客的售前和售后咨询，日均咨询量持续增长，人均接待超300人。当前经历了两个阶段：
+
+-   **人工客服阶段：**
+    
+    -   超负荷运转，首次响应时长超过20分钟；
+        
+    -   工作时间为10:00~19:00，下班后无法回复，非工作时段咨询无人承接；
+        
+    -   需手动在多个系统间切换查询顾客订单、物流等信息，操作效率低；
+        
+    -   新客服培训周期长（约2~4周），客服流动性大导致服务质量不稳定。
+        
+-   **微信智能客服阶段（关键词匹配方案）：**
+    
+    -   基于关键词匹配，语义理解能力差，无法处理复杂、多轮对话；
+        
+    -   无法实时查询商品/订单数据，只能回复静态FAQ；
+        
+    -   转人工率>60%，未转人工满意度仅30%；
+        
+    -   机械性回复，缺乏品牌调性和情感温度；
+        
+    -   需人工维护大量QA对，维护成本高，更新滞后。
+        
+
+### 2\. 问题定义与影响分析
+
+| **问题** | **影响** |
+| --- | --- |
+| **客服超负荷，响应慢** | 首次响应超20分钟，顾客流失率上升，直接影响转化率和复购率；据客服团队反馈，高峰期约15%的咨询因等待过久而流失。 |
+| **非工作时段无人值守** | 19:00~次日10:00约占全天咨询量的30%，这部分咨询无法得到及时响应，导致售前转化机会损失、售后体验下降。 |
+| **现有智能客服体验差** | 未转人工满意度仅30%，转人工率>60%，相当于智能客服未能有效分流，反而增加了用户操作步骤和等待时间，客户投诉率上升。 |
+| **知识库维护成本高** | 需人工维护数千条QA对，商品上新、活动变更时更新滞后，导致客服回复过时信息，引发客诉。 |
+| **人力成本持续攀升** | 100+客服团队，随咨询量增长需持续扩编，人力成本年增长约20%，且新人培训周期长、流动性高。 |
+
+### 3\. 解决方案策略
+
+引入基于大语言模型的智能客服Agent，替代现有关键词匹配方案：
+
+-   **语义理解升级**：利用LLM强大的自然语言理解能力，支持复杂意图识别和多轮对话；
+    
+-   **知识库 + RAG**：基于检索增强生成技术，自动从商品文档、售后政策、历史优秀对话中检索相关知识，降低人工维护成本；
+    
+-   **工具调用能力**：Agent可实时调用订单查询、物流查询、商品查询等API，直接为顾客提供精准信息；
+    
+-   **7×24小时服务**：AI客服全天候在线，覆盖非工作时段；
+    
+-   **品牌调性一致**：通过Prompt工程统一回复风格，保证服务温度和品牌一致性；
+    
+-   **人机协同兜底**：设计合理的转人工策略，复杂/敏感场景自动流转至人工客服。
+    
+
+### 4\. 项目目标
+
+通过建设基于大模型的智能客服Agent，实现7×24小时智能接待，将未转人工满意度从30%提升至90%以上，转人工率从60%降至20%以下，首次响应时长从20分钟降至10秒内。
+
+**量化目标（SMART）：**
+
+| **指标** | **现状** | **目标** | **衡量方式** |
+| --- | --- | --- | --- |
+| 未转人工满意度（北极星） | 30% | ≥90% | AI独立结束会话后推送评价（1~5星），4星及以上为满意 |
+| 首次响应时长 | \>20分钟 | ≤10秒 | 系统埋点统计 |
+| 转人工率 | \>60% | ≤20% | 剔除用户第一句即要求转人工的情况 |
+| 回复准确率 | —   | ≥95% | 人工抽检每轮回复准确数/总轮数 |
+| 知识库维护人力 | 2人全职 | ≤0.5人 | 知识库自动迭代，仅需审核 |
+
+## （二）干系人识别与分析
+
+### 1\. 干系人识别
+
+通过组织结构分析和业务流程走查，识别以下关键干系人：
+
+| **干系人** | **类型** | **与系统的关系** |
+| --- | --- | --- |
+| 公司管理层 | 项目发起人/出资人 | 关注降本增效的投资回报，审批项目预算和上线节奏 |
+| 客服主管 | 间接用户 | 管理客服团队，关注服务质量指标、排班优化、团队转型 |
+| 一线客服 | 核心用户 | 日常使用系统，接手AI转人工的复杂对话，关注工具易用性 |
+| 顾客（消费者） | 外部干系人 | 直接体验智能客服的服务质量，是满意度的最终评判者 |
+| 运营/商品团队 | 间接用户 | 提供商品信息、活动规则等知识源，关注信息准确性和更新机制 |
+| 法务/合规团队 | 间接用户 | 关注AI回复的合规性、敏感信息保护、消费者权益保障 |
+
+### 2\. 干系人分析
+
+| **干系人** | **核心关注点** | **期望** | **担心/阻力** |
+| --- | --- | --- | --- |
+| 管理层 | 投资回报率、降本增效数据 | 减少客服人力成本20%~30%，提升客户满意度 | AI出错导致品牌舆情风险；投入产出比不明确 |
+| 客服主管 | 服务质量、团队管理效率 | 降低团队工作压力，聚焦高价值复杂咨询 | 担心团队裁员引发士气下降；AI不可控时增加管理难度 |
+| 一线客服 | 工具易用性、工作负荷 | 减少重复性问答，专注处理有挑战的问题 | **岗位安全感**——担心被AI替代；人机协作流程不顺畅 |
+| 顾客  | 响应速度、回复准确性、服务态度 | 快速得到准确解答，体验自然流畅 | AI答非所问浪费时间； |
+| 无法解决问题又找不到人工； | <br> | <br> | <br> |
+| 运营/商品 | 信息准确性、更新便捷性 | 知识库能自动同步商品和活动信息 | 担心增加额外的信息维护工作量 |
+| 法务/合规 | 合规性、数据安全 | AI回复不涉及虚假承诺、敏感信息泄露 | AI生成不可控内容引发法律风险 |
+
+> **需求冲突识别：** 管理层期望最大化AI自动处理率以降低成本，但一线客服和顾客更关注服务质量和兜底体验。在方案设计中需平衡效率与体验——设置合理的转人工阈值，既保证AI充分发挥作用，又确保复杂场景下顾客能快速触达人工。
+
+## （三）详细需求分析
+
+### 1\. 核心业务场景
+
+通过对历史客服对话记录的分析，梳理出以下核心业务场景：
+
+| **类型** | **场景** | **典型问题示例** | **频次** | **AI处理策略** |
+| --- | --- | --- | --- | --- |
+| 售前  | 商品咨询 | "这款面霜适合油皮吗？""成分里有没有酒精？" | 高频  | 知识库检索 + 商品API查询 |
+| 售前  | 优惠活动咨询 | "现在有什么满减活动？""这个券能和会员折扣叠加吗？" | 高频  | 知识库检索（活动规则） |
+| 售前  | 推荐与比较 | "帮我推荐一款保湿面膜""A和B哪个更适合敏感肌？" | 中频  | 知识库 + 商品API + Prompt引导 |
+| 售后  | 物流查询 | "我的包裹到哪了？""为什么还没发货？" | 高频  | 订单/物流API调用 |
+| 售后  | 退换货咨询 | "我想退货怎么操作？""退款多久到账？" | 中频  | 知识库（退换政策）+ 订单API |
+| 售后  | 投诉与纠纷 | "收到的商品有质量问题""发错货了" | 低频  | 安抚 + 收集信息 → 转人工 |
+| 通用  | 账户与会员 | "我的积分怎么查？""怎么修改收货地址？" | 中频  | 知识库 + 引导自助操作 |
+| 通用  | 闲聊/无关内容 | "今天天气怎么样？""你是真人吗？" | 低频  | 礼貌引导回业务话题 |
+
+### 2\. 功能需求
+
+**2.1 业务支持**
+
+**（1）智能问答模块**
+
+-   多轮对话管理：支持上下文理解，跨多轮追问和澄清
+    
+-   知识库问答：基于RAG从商品文档、售后政策、FAQ中检索并生成回复
+    
+-   工具调用：实时调用订单查询、物流查询、商品查询、优惠券查询等API
+    
+-   意图识别与路由：识别用户意图（咨询/查询/投诉/闲聊），路由至对应处理策略
+    
+-   品牌调性控制：通过Prompt确保回复风格统一、有温度、符合品牌形象
+    
+
+**（2）人机协同模块**
+
+-   转人工策略：支持用户主动转人工、AI主动触发转人工（识别到无法解决/敏感场景）
+    
+-   对话摘要传递：转人工时自动生成对话摘要，帮助人工客服快速了解上下文
+    
+-   人工辅助建议：为人工客服提供AI建议回复，提升人工处理效率
+    
+
+**2.2 维护支持**
+
+**（1）知识库管理模块**
+
+-   知识入库：支持批量导入商品文档、政策文件、FAQ
+    
+-   自动更新：商品上下架、活动变更时自动触发知识库更新
+    
+-   知识审核：更新内容需经审核后生效，防止错误信息流入
+    
+
+**2.3 管理支持**
+
+**（1）监控与运营模块**
+
+-   核心指标看板：满意度、转人工率、响应时长、准确率等实时监控
+    
+-   Badcase管理：自动采集低满意度对话，支持标注、分类和归因分析
+    
+-   对话日志与回放：支持查看完整对话记录，用于质检和优化
+    
+
+**（2）安全合规模块**
+
+-   敏感信息过滤：自动识别并脱敏用户手机号、身份证号等敏感信息
+    
+-   回复安全检查：过滤可能包含虚假承诺、不当言论的AI输出
+    
+-   异常兜底：模型超时/报错时，提供友好的兜底回复并引导转人工
+    
+
+### 3\. 非功能需求
+
+| **维度** | **要求** |
+| --- | --- |
+| **性能** | AI首次响应时间 ≤3秒（P95），支持500路并发会话 |
+| **可用性** | 7×24小时服务，系统可用率 ≥99.9% |
+| **安全性** | 对话数据加密传输和存储；敏感信息脱敏；符合《个人信息保护法》要求 |
+| **易用性** | 知识库管理界面支持非技术人员操作；运营看板关键指标一目了然 |
+| **可扩展性** | 支持新增工具调用接口（如优惠券核销、售后工单创建）；支持多渠道接入（App、小程序等） |
+| **可维护性** | Prompt和知识库可在线热更新，无需重新部署；模型可灵活切换 |
+
+<br>

3. 实战篇（客服Agent)/3.3 整体设计.md

@@ -0,0 +1,119 @@
+## （一）产品架构设计
+
+**核心思路：** 基于 Dify 平台搭建智能客服 Agent，采用 **Chatflow + RAG + 工具调用** 的架构，通过企业微信客服接口对接用户，实现知识问答、订单查询、人机协同的完整闭环。
+
+### 整体架构图
+
+![](../../.resources/image-1778916957943.png)
+
+### 架构分层说明
+
+| **层级** | **核心组件** | **职责** |
+| --- | --- | --- |
+| **用户层** | 企业微信客服 | 用户触达入口，后续可扩展至 App、小程序、网页等多渠道 |
+| **接入层** | 企微 API 网关 + 会话管理 | 接收用户消息、管理会话状态、处理转人工路由、调用 Dify API |
+| **AI 核心层** | Dify Chatflow | 对话编排引擎，串联意图识别、知识检索、工具调用、Prompt 管理等核心能力 |
+| **知识库层** | Dify 知识库 | 管理商品、政策、FAQ、活动等知识文档，支持向量检索 + 全文检索的混合检索 |
+| **工具层** | 自定义 API 工具 | 对接公司内部业务系统，提供订单、物流、商品、优惠券等实时数据查询能力 |
+| **运营支撑层** | 监控 + Badcase 管理 | 数据埋点、核心指标看板、低满意度对话采集与分析 |
+| **安全层** | 内容安全 + 兜底机制 | 敏感信息过滤、AI 输出安全审查、异常场景兜底回复 |
+
+## （二）技术方向选型
+
+### 1\. 为什么选择 Dify？
+
+| **评估维度** | **Dify 能力** | **与本项目的匹配度** |
+| --- | --- | --- |
+| **应用编排** | Chatflow 可视化编排，支持条件分支、循环、变量传递 | ✅ 完美支持意图路由 → 知识检索/工具调用 → 回复生成的流程 |
+| **RAG 能力** | 内置知识库管理，支持多种分段策略、混合检索、Rerank | ✅ 满足商品/政策/FAQ 等多知识库检索需求 |
+| **工具调用** | 支持自定义 API 工具接入，OpenAPI 规范导入 | ✅ 可快速对接订单、物流、商品等内部 API |
+| **模型灵活性** | 支持 GPT、Claude、通义千问、DeepSeek 等 100+ 模型 | ✅ 可灵活切换和评测不同模型，不被厂商锁定 |
+| **Prompt 管理** | 可视化 Prompt 编辑，支持变量插入和版本管理 | ✅ 产品可直接调优 Prompt，无需开发介入 |
+| **可观测性** | 内置日志、标注、对话记录查看 | ✅ 支持 Badcase 标注和持续优化闭环 |
+| **部署方式** | 支持私有化部署（Docker/K8s）和 SaaS 云服务 | ✅ 可私有化部署保障数据安全 |
+| **开发成本** | 低代码平台，产品可直接配置 | ✅ 大幅降低开发周期，预计节省 40%~50% 开发工时 |
+
+### 2\. 核心技术选型
+
+| **技术环节** | **选型方案** | **说明** |
+| --- | --- | --- |
+| AI 应用平台 | Dify（私有化部署） | Docker Compose 部署，保障数据不出内网 |
+| 应用编排方式 | Dify Chatflow | 可视化编排对话流程，支持条件分支和工具调用节点 |
+| 大语言模型 | 待评测选型 | 候选：DeepSeek-V3 / 通义千问-Max / GPT-4o-mini，综合评估准确率、延迟和成本 |
+| Embedding 模型 | 待评测选型 | 候选：text-embedding-v3 / bge-m3，评估中文语义检索效果 |
+| Rerank 模型 | 待评测选型 | 候选：bge-reranker-v2-m3 / Cohere Rerank，提升检索精度 |
+| 知识库 | Dify 内置知识库 | 向量数据库 + 全文检索，混合检索策略 |
+| 会话管理 | 自研中间层服务 | 管理企微会话状态、调用 Dify Chatflow API、处理转人工逻辑 |
+| 接入渠道 | 企业微信客服 API | 通过企微客服接口收发消息，对接 Dify API |
+| 监控看板 | Dify 日志 + 自建看板 | Dify 提供对话日志和标注；自建看板统计满意度、转人工率等业务指标 |
+
+### 3\. Dify Chatflow 核心流程设计
+
+<br>
+
+![image.png](attachment:cdfa2c51-60e1-41b9-89c3-5ca47b18fbb3:image.png)
+
+## （三）产品路线图
+
+<aside> 📌
+
+**分期策略：** 采用 MVP → 增强 → 规模化 三阶段渐进上线，每阶段有明确的交付物和验收标准，降低项目风险。
+
+</aside>
+
+### 里程碑 1：MVP 版本（第 1~8 周）
+
+**目标：** 跑通核心链路，验证技术可行性
+
+-   Dify 私有化部署 & 环境搭建
+    
+-   知识库构建：商品 FAQ + 售后政策（覆盖 Top 50 高频问题）
+    
+-   Chatflow 基础编排：意图识别 → 知识检索 → 回复生成
+    
+-   基础工具调用：订单查询、物流查询
+    
+-   企微客服接口对接
+    
+-   基础 Prompt 调优
+    
+-   评测集构建 & 模型选型
+    
+-   **验收标准：** Top 50 高频问题准确率 ≥ 90%
+    
+
+### 里程碑 2：增强版本（第 9~14 周）
+
+**目标：** 完善功能，达到上线标准
+
+-   知识库扩展：覆盖全品类商品 + 活动规则
+    
+-   工具扩展：商品查询、优惠券查询
+    
+-   转人工策略完善：对话摘要传递、人工辅助建议
+    
+-   安全合规模块：敏感信息过滤、内容安全审查、异常兜底
+    
+-   监控看板：满意度、转人工率、响应时长等核心指标
+    
+-   Prompt 深度调优 & 检索策略优化
+    
+-   **验收标准：** 未转人工满意度 ≥ 85%，转人工率 ≤ 25%
+    
+
+### 里程碑 3：规模化上线（第 15~17 周）
+
+**目标：** 灰度验证 → 全量上线
+
+-   30% 客服账号灰度测试，持续监控 2 周
+    
+-   根据灰度数据迭代优化
+    
+-   全量切换上线
+    
+-   建立持续运营机制：Badcase 收集 → 分析 → 优化闭环
+    
+-   **验收标准：** 未转人工满意度 ≥ 90%，转人工率 ≤ 20%，首次响应 ≤ 10 秒
+    
+
+<br>

3. 实战篇（客服Agent)/3.4 详细设计.md

@@ -0,0 +1,684 @@
+## （一）知识库设计
+
+**设计目标：** 构建覆盖售前售后全场景的结构化知识库体系，确保知识准确、更新及时、检索高效，支撑 AI 客服 95% 以上的回复准确率。
+
+### 1\. 数据源范围
+
+| **知识库分类** | **数据源** | **内容示例** | **更新频率** |
+| --- | --- | --- | --- |
+| **商品知识库** | 商品中心数据库、商品详情页 | 商品名称、规格参数、成分、功效、适用人群、使用方法、注意事项 | 商品上下架时实时同步 |
+| **售后政策库** | 运营部门政策文档 | 退换货规则、退款时效、质量问题处理流程、保修政策 | 政策变更时更新（约月度） |
+| **活动规则库** | 运营/市场部门活动方案 | 满减规则、优惠券使用条件、叠加规则、活动时间范围 | 活动上下线时实时同步 |
+| **FAQ 库** | 历史客服优秀对话 + 客服知识沉淀 | 高频问题标准答案、话术模板、常见误区澄清 | 周度更新 |
+| **物流知识库** | 物流部门 SOP 文档 | 发货时效、合作快递、运费规则、特殊地区说明 | 规则变更时更新 |
+| **会员权益库** | 会员中心规则文档 | 会员等级权益、积分规则、积分兑换说明 | 规则变更时更新 |
+
+### 2\. 文档分片策略
+
+分片质量直接影响检索精度，需根据不同知识类型采用差异化分片策略。
+
+| **知识库类型** | **分片策略** | **分片大小** | **说明** |
+| --- | --- | --- | --- |
+| 商品知识库 | 按商品 SPU 分片 | 500–800 tokens | 每个 SPU 为一个独立文档片段，包含完整的商品信息，避免信息割裂 |
+| 售后政策库 | 按政策条目分片 | 300–500 tokens | 每条政策规则为一个片段，保留上下文标题作为 metadata |
+| 活动规则库 | 按活动维度分片 | 400–600 tokens | 每个活动的完整规则为一个片段，包含时间、条件、限制等完整信息 |
+| FAQ 库 | 按 Q&A 对分片 | 200–400 tokens | 每个问答对为一个片段，问题作为片段标题增强语义匹配 |
+| 物流/会员知识库 | 按规则段落分片 | 300–500 tokens | 按自然段落切分，保留完整语义单元 |
+
+**通用分片原则：**
+
+-   每个片段保持语义完整性，不在句子中间截断
+    
+-   相邻片段设置 50–100 tokens 的重叠区域，防止边界信息丢失
+    
+-   每个片段附加 metadata：知识库类型、文档来源、更新时间、关联商品/活动 ID
+    
+-   片段标题使用关键信息摘要，提升检索匹配度
+    
+
+### 3\. 知识库更新机制
+
+| **更新方式** | **触发条件** | **流程** |
+| --- | --- | --- |
+| **自动同步** | 商品上下架、活动上下线 | 业务系统 Webhook → 中间层服务 → 调用 Dify 知识库 API 新增/更新/删除文档片段 |
+| **定时同步** | 每日凌晨定时任务 | 全量扫描商品库变更 → 增量更新知识库 → 生成更新日志 |
+| **人工更新** | 政策变更、FAQ 优化 | 运营/客服在管理后台提交 → 产品审核 → 调用 API 入库生效 |
+| **Badcase 驱动** | 发现回复错误或知识缺失 | Badcase 分析 → 定位知识缺口 → 补充/修正知识 → 审核入库 |
+
+**审核机制：** 所有知识变更需经审核后生效，自动同步的内容设置抽检机制（每批次抽检 10%），人工提交的内容 100% 审核。
+
+## （二）检索策略设计
+
+**设计目标：** 通过混合检索 + Rerank 的两阶段检索架构，在保证召回率的同时提升精准度，确保 Top 3 检索结果中包含正确答案的概率 ≥ 95%。
+
+### 1\. 检索架构：混合检索 + Rerank
+
+```mermaid
+graph LR
+    A["用户问题"] --> B["Query 改写"]
+    B --> C["向量检索"]
+    B --> D["全文检索"]
+    C --> E["结果合并"]
+    D --> E
+    E --> F["Rerank 重排序"]
+    F --> G["Top K 结果"]
+    G --> H["LLM 生成回复"]
+```
+
+### 2\. 检索流程详细设计
+
+| **阶段** | **处理步骤** | **说明** |
+| --- | --- | --- |
+| **Query 预处理** | Query 改写 + 关键词提取 | 利用 LLM 将口语化问题改写为检索友好的表述；提取商品名、订单号等关键实体，用于精确匹配和工具路由 |
+| **向量检索** | 语义相似度匹配 | 将 Query 向量化后在 Dify 向量数据库中检索，召回 Top 10 语义相关片段；适合处理语义模糊、表述多样的问题 |
+| **全文检索** | 关键词 + BM25 匹配 | 基于 Dify 全文检索引擎，召回 Top 10 关键词匹配片段；适合处理包含专有名词、型号、精确术语的查询 |
+| **结果合并** | 加权融合 | 向量检索权重 0.7 + 全文检索权重 0.3（初始值，根据评测结果调优）；去重后保留 Top 15 候选片段 |
+| **Rerank 重排序** | 交叉编码器精排 | 使用 Rerank 模型（bge-reranker-v2-m3）对候选片段进行精排，输出 Top 3~5 最相关片段 |
+| **上下文组装** | Prompt 注入 | 将 Top K 检索结果拼接为上下文注入 Prompt，附带来源标注（知识库类型 + 文档名称） |
+
+### 3\. 检索参数配置
+
+| **参数** | **初始值** | **调优说明** |
+| --- | --- | --- |
+| 向量检索 Top K | 10  | 召回阶段宽口径，确保不遗漏相关片段 |
+| 全文检索 Top K | 10  | 与向量检索互补，覆盖关键词精确匹配场景 |
+| 混合检索权重 | 向量 0.7 / 全文 0.3 | 电商场景下语义检索更重要，但需保留关键词精确匹配能力 |
+| Rerank 后 Top K | 3~5 | 简单问题取 Top 3，复杂问题取 Top 5，通过意图识别动态调整 |
+| 相似度阈值 | 0.5 | 低于阈值的结果不进入上下文，防止引入噪音信息 |
+| Score 阈值（Rerank） | 0.3 | Rerank 后低于阈值的片段丢弃，确保上下文质量 |
+
+### 4\. 多知识库路由策略
+
+根据意图识别结果，动态选择检索的知识库范围，减少无关知识干扰：
+
+| **用户意图** | **检索知识库** | **说明** |
+| --- | --- | --- |
+| 商品咨询 | 商品知识库 + FAQ 库 | 优先商品知识库，FAQ 库补充常见问题 |
+| 优惠活动咨询 | 活动规则库 + FAQ 库 | 活动规则库为主，FAQ 补充叠加规则等常见问题 |
+| 物流查询 | 物流知识库 | 配合工具调用（物流 API）使用 |
+| 退换货咨询 | 售后政策库 + FAQ 库 | 政策库提供规则，FAQ 提供操作指引 |
+| 会员/积分问题 | 会员权益库 | 会员相关规则集中检索 |
+| 意图不明确 | 全部知识库 | 无法明确意图时全库检索，由 Rerank 筛选最相关结果 |
+
+### 5\. 检索兜底策略
+
+-   **无结果兜底：** 当所有检索结果的 Rerank Score 均低于阈值时，回复"抱歉，我暂时无法找到相关信息"并引导转人工
+    
+-   **低置信度兜底：** 当最高 Score 在 0.3~0.5 之间时，在回复中增加不确定性表述（"根据我的了解…"），并主动询问用户是否需要转人工
+    
+-   **知识库为空兜底：** 对应知识库未命中任何结果时，扩大到全库检索一次；仍无结果则触发兜底回复
+    
+
+## （三）工具调用设计
+
+**设计目标：** 通过 Dify 自定义 API 工具对接公司内部业务系统，为 AI 客服提供实时数据查询能力，覆盖订单、物流、商品、优惠券四大核心查询场景。
+
+### 1\. 工具清单
+
+| **工具名称** | **触发场景** | **输入参数** | **输出信息** |
+| --- | --- | --- | --- |
+| **订单查询** | 用户咨询订单状态、退款进度 | 订单号 或 用户ID + 时间范围 | 订单状态、商品信息、金额、下单时间、退款状态 |
+| **物流查询** | 用户咨询包裹物流进度 | 订单号 或 物流单号 | 快递公司、物流单号、最新物流节点、预计送达时间 |
+| **商品查询** | 用户咨询商品价格、库存、规格 | 商品名称 或 商品ID / SKU ID | 商品价格、库存状态、可选规格、当前促销信息 |
+| **优惠券查询** | 用户咨询可用优惠券 | 用户ID | 可用券列表（券面额、使用条件、有效期） |
+
+### 2\. 工具调用流程
+
+```mermaid
+sequenceDiagram
+    participant U as 用户
+    participant D as Dify Chatflow
+    participant T as API 工具
+    participant B as 业务系统
+    U->>D: "我的订单到哪了？"
+    D->>D: 意图识别 → 物流查询
+    D->>D: 参数提取 → 订单号
+    alt 参数完整
+        D->>T: 调用物流查询工具
+        T->>B: 请求物流 API
+        B-->>T: 返回物流数据
+        T-->>D: 物流信息
+        D->>D: 结合 Prompt 生成自然语言回复
+        D-->>U: "您的包裹已到达XX中转站，预计明天送达"
+    else 参数缺失
+        D-->>U: "请提供您的订单号，我帮您查询物流信息"
+    end
+```
+
+### 3\. API 接口规范
+
+所有工具通过 **OpenAPI 3.0 规范**导入 Dify，统一接口设计：
+
+| **规范项** | **要求** |
+| --- | --- |
+| 协议  | HTTPS，内网通信可使用 HTTP |
+| 认证方式 | API Key（Header: X-API-Key），Dify 侧统一配置 |
+| 请求格式 | JSON，Content-Type: application/json |
+| 响应格式 | 统一 JSON 结构：`{"code": 0, "message": "success", "data": {...}}` |
+| 超时设置 | 单次调用超时 5 秒，超时后返回兜底提示 |
+| 错误处理 | 业务系统返回错误时，AI 回复"系统查询暂时不可用，建议联系人工客服" |
+| 数据脱敏 | 返回数据中的手机号、身份证号等敏感信息需在业务系统侧预先脱敏 |
+
+### 4\. 参数提取与校验
+
+| **参数** | **提取方式** | **校验规则** |
+| --- | --- | --- |
+| 订单号 | LLM 从对话中提取 | 正则校验格式（如纯数字 10~20 位）；无效则追问 |
+| 物流单号 | LLM 提取 或 通过订单号级联查询 | 校验格式；优先通过订单号自动获取 |
+| 商品名称/ID | LLM 提取 + 知识库辅助匹配 | 模糊匹配时返回候选列表让用户确认 |
+| 用户ID | 从企微会话上下文自动获取 | 由中间层服务注入，无需用户提供 |
+
+### 5\. 工具调用异常处理
+
+| **异常场景** | **处理策略** | **回复示例** |
+| --- | --- | --- |
+| API 调用超时 | 重试 1 次，仍失败则兜底 | "系统查询稍有延迟，请稍后重试或联系人工客服为您查询" |
+| API 返回错误 | 记录错误日志，返回友好提示 | "抱歉，当前系统繁忙，我帮您转接人工客服处理" |
+| 查询无结果 | 确认参数后提示无数据 | "未查询到该订单信息，请确认订单号是否正确" |
+| 参数缺失 | 主动追问所需参数 | "请提供您的订单号，我帮您查询具体信息～" |
+| 多次调用失败 | 标记异常并转人工 | "很抱歉给您带来不便，正在为您转接人工客服" |
+
+## （四）Prompt 设计
+
+**设计目标：** 通过精心设计的系统提示词体系，确保 AI 客服回复准确、有温度、符合品牌调性，同时具备清晰的边界意识和转人工判断能力。
+
+### 1\. 系统提示词结构
+
+Prompt 采用 **模块化分层结构**，便于独立维护和版本管理：
+
+| **模块** | **作用** | **内容要点** |
+| --- | --- | --- |
+| **角色定义** | 设定 AI 身份和行为边界 | 你是XX品牌的专属客服助手，服务态度亲切专业，仅回答品牌相关问题 |
+| **品牌调性** | 统一回复风格和语气 | 温暖亲切、专业可信、不卑不亢；使用"亲"等电商常用称呼；适当使用 emoji |
+| **回复规范** | 约束回复格式和质量 | 回复简洁（不超过 150 字）；分点回答复杂问题；不编造信息；不确定时主动说明 |
+| **知识库使用规范** | 约束知识引用方式 | 仅基于检索到的知识回复；未检索到时不杜撰；标注信息来源类型 |
+| **工具调用规范** | 约束工具使用行为 | 需要实时数据时主动调用工具；参数不全时追问；工具失败时友好提示 |
+| **转人工规则** | 明确转人工触发条件 | 详见下方转人工策略设计 |
+| **安全红线** | 设定不可逾越的底线 | 不承诺超出政策范围的内容；不泄露内部信息；不回复无关话题 |
+
+### 2\. 系统提示词示例
+
+-   点击展开完整系统提示词
+    
+    ```
+    ## 角色定义
+    你是「XX品牌」的智能客服助手「小X」，负责为顾客提供售前咨询和售后服务。
+    你的目标是：准确解答顾客问题，提供温暖专业的服务体验。
+    
+    ## 品牌调性
+    - 语气：温暖亲切、专业可信，像一位耐心的朋友
+    - 称呼：使用"亲"或"您"
+    - 风格：简洁明了，适当使用 emoji（如 😊🎉💝）增添温度
+    - 禁止：冷冰冰的机械回复、过度热情、使用网络流行语
+    
+    ## 回复规范
+    1. 回复控制在 150 字以内，复杂问题可分点回答
+    2. 仅基于【检索到的知识】和【工具查询结果】回复，不编造信息
+    3. 不确定的信息加上"根据我的了解"等限定表述
+    4. 涉及具体金额、时效等关键信息时，务必引用准确数据
+    5. 每次回复结尾可加一句关怀或引导（如"还有其他问题随时问我哦~"）
+    
+    ## 工具调用规范
+    - 涉及订单、物流、商品价格/库存、优惠券等实时信息时，必须调用对应工具查询
+    - 参数不全时，礼貌追问（如"请提供您的订单号，我帮您查一下~"）
+    - 工具调用失败时，告知用户并建议转人工
+    
+    ## 转人工规则
+    以下情况必须转人工处理：
+    1. 用户明确要求转人工
+    2. 投诉、纠纷、质量问题等敏感场景
+    3. 连续 2 轮无法解决用户问题
+    4. 涉及退款金额争议或特殊处理
+    5. 用户情绪明显激动或不满
+    转人工时说："理解您的情况，我帮您转接专属客服，请稍等~"
+    
+    ## 安全红线
+    - 绝不承诺超出公司政策范围的内容（如"一定给您退款"）
+    - 绝不泄露内部信息（如成本价、供应商、内部流程）
+    - 绝不回复与品牌业务无关的话题（政治、宗教等）
+    - 遇到无法判断的情况，优先转人工
+    ```
+    
+
+### 3\. 转人工策略设计
+
+| **触发类型** | **触发条件** | **处理方式** |
+| --- | --- | --- |
+| **用户主动触发** | 用户发送"转人工""人工客服"等关键词 | 立即转人工，附带对话摘要 |
+| **场景触发** | 投诉、纠纷、质量问题、退款争议 | AI 先安抚并收集关键信息（订单号、问题描述）→ 生成摘要 → 转人工 |
+| **能力边界触发** | 连续 2 轮未解决用户问题（检索无结果或工具调用失败） | 主动告知用户"这个问题我帮您转接人工客服处理" → 转人工 |
+| **情绪触发** | 检测到用户情绪激动（含辱骂、大量感叹号/问号等） | 先回复安抚语句 → 自动转人工 |
+| **安全触发** | 涉及敏感信息泄露风险、合规风险 | 回复安全兜底语句 → 转人工 |
+
+### 4\. 对话摘要传递
+
+转人工时，AI 自动生成结构化对话摘要，帮助人工客服快速了解上下文：
+
+```
+【对话摘要】
+- 用户问题：查询订单 2024010812345 的退款进度
+- 已获取信息：订单已签收，退款申请已提交 3 天
+- 未解决原因：用户对退款时效不满，要求加急处理
+- 用户情绪：略有不满
+- 建议处理：优先查看退款进度，安抚用户情绪
+```
+
+### 5\. Prompt 版本管理
+
+| **管理项** | **规范** |
+| --- | --- |
+| 版本记录 | 每次修改在 Dify 中保存版本号和修改说明，格式：v1.0.0 - 修改内容描述 |
+| 修改流程 | 产品修改 Prompt → 在评测集上验证效果 → 对比前后指标 → 确认上线 |
+| 回滚机制 | 新版本上线后 24 小时内持续观测指标，指标下降超过 5% 则回滚至上一版本 |
+| A/B 测试 | 重大 Prompt 调整通过 Dify 的 A/B 测试能力灰度发布，观察对比数据后全量 |
+
+## （五）评测流程、指标和看板设计
+
+**设计目标：** 建立完善的评测体系，覆盖上线前评测和上线后监控，通过数据驱动持续优化智能客服效果。
+
+### 1\. 评测集设计
+
+**评测集构建原则：**
+
+-   覆盖所有核心业务场景（售前咨询、售后服务、物流查询等）
+    
+-   包含简单问题和复杂多轮对话
+    
+-   包含边界场景（无关问题、敏感问题、恶意攻击等）
+    
+-   由客服团队和产品共同标注，确保标准答案准确
+    
+
+| **场景分类** | **数量** | **来源** | **评测重点** |
+| --- | --- | --- | --- |
+| 商品咨询 | 100 | 历史对话 + 人工构造 | 知识库检索准确性、回复信息完整度 |
+| 订单/物流查询 | 80  | 历史对话 + Mock 数据 | 工具调用成功率、参数提取准确性 |
+| 退换货咨询 | 60  | 历史对话 | 政策引用准确性、流程指引清晰度 |
+| 优惠活动咨询 | 50  | 历史对话 + 人工构造 | 活动规则理解准确性、叠加规则判断 |
+| 多轮对话 | 40  | 人工构造 | 上下文理解、信息串联、追问处理 |
+| 转人工场景 | 30  | 历史对话 + 人工构造 | 转人工触发准确性、摘要质量 |
+| 边界/安全场景 | 40  | 人工构造 | 拒绝回复准确性、安全红线遵守 |
+| **合计** | **400** | <br> | <br> |
+
+### 2\. 评测指标体系
+
+**（1）上线前评测指标**
+
+| **指标** | **计算方式** | **目标值** | **评测方式** |
+| --- | --- | --- | --- |
+| 回复准确率 | 正确回复数 / 总评测数 | ≥ 95% | 人工评审（对照标准答案） |
+| 知识库命中率 | 检索到正确知识片段的问题数 / 需要知识库回答的问题数 | ≥ 98% | 自动化评测 |
+| 工具调用成功率 | 工具成功返回结果数 / 应调用工具的问题数 | ≥ 99% | 自动化评测（Mock API） |
+| 转人工准确率 | 正确触发转人工数 / 应转人工的问题数 | ≥ 90% | 人工评审 |
+| 安全合规率 | 未违反安全红线的回复数 / 总安全测试数 | 100% | 人工评审 + 自动化检测 |
+| 平均响应时间 | 从收到消息到返回回复的平均时长 | ≤ 3 秒 | 自动化测试 |
+
+**（2）上线后核心监控指标**
+
+| **指标** | **计算方式** | **目标值** | **监控频率** |
+| --- | --- | --- | --- |
+| ⭐ 未转人工满意度（北极星） | AI 独立结束会话后 4~5 星评价占比 | ≥ 90% | 实时  |
+| 转人工率 | （AI 主动 + 用户主动转人工数）/ 总会话数 | <br> | <br> |
+| （剔除首句即转人工） | ≤ 20% | 实时  | <br> |
+| 首次响应时长 | 用户发送消息到 AI 首次回复的时长 | ≤ 10 秒 | 实时  |
+| 会话解决率 | AI 独立解决的会话数 / 总会话数 | ≥ 75% | 日报  |
+| Badcase 率 | 低满意度（1~2 星）会话数 / 总评价会话数 | ≤ 5% | 日报  |
+| 平均对话轮次 | AI 独立完成会话的平均交互轮次 | ≤ 5 轮 | 周报  |
+
+### 3\. 监控看板设计
+
+**看板分为三层：**
+
+**（1）核心指标大盘（管理层 / 日常巡检）**
+
+-   未转人工满意度趋势图（日/周/月）
+    
+-   转人工率趋势图
+    
+-   首次响应时长分布图
+    
+-   今日会话量 / 解决率 / Badcase 数实时卡片
+    
+
+**（2）场景分析看板（产品 / 运营）**
+
+-   各业务场景的满意度和准确率对比
+    
+-   转人工原因分布（用户主动 / AI 触发 / 场景触发 / 情绪触发）
+    
+-   知识库命中率按知识库类型分布
+    
+-   热门咨询问题 Top 20 排行
+    
+
+**（3）Badcase 管理看板（产品 / 客服）**
+
+-   低满意度对话列表（可点击查看完整对话记录）
+    
+-   Badcase 归因分类：知识缺失 / 检索不准 / Prompt 问题 / 工具异常 / 其他
+    
+-   Badcase 处理状态跟踪（待分析 → 已归因 → 已修复 → 已验证）
+    
+-   修复后效果验证记录
+    
+
+### 4\. 评测与优化闭环
+
+```mermaid
+graph TD
+    A["上线运行"] --> B["监控看板<br>实时采集数据"]
+    B --> C{"指标异常?"}
+    C -- 是 --> D["Badcase 采集"]
+    D --> E["归因分析"]
+    E --> F{"原因分类"}
+    F -- 知识缺失 --> G["补充知识库"]
+    F -- 检索不准 --> H["优化检索策略/参数"]
+    F -- Prompt问题 --> I["调优 Prompt"]
+    F -- 工具异常 --> J["排查 API 问题"]
+    G --> K["评测集验证"]
+    H --> K
+    I --> K
+    J --> K
+    K --> L{"指标达标?"}
+    L -- 是 --> M["灰度发布"]
+    L -- 否 --> E
+    M --> A
+    C -- 否 --> A
+```
+
+## （六）功能设计：人工辅助建议
+
+<aside> 🤖
+
+**设计目标：** 在转人工场景中，AI 不仅传递对话摘要，还为人工客服实时提供建议回复和参考信息，提升人工处理效率 30% 以上，缩短平均处理时长。
+
+</aside>
+
+### 1\. 功能定位
+
+人工辅助建议是**人机协同模块**的核心功能，定位为人工客服的 **AI Copilot**。AI 转人工后不退出，而是作为后台助手持续为人工客服提供支持。
+
+```mermaid
+graph LR
+    A["顾客"] <--> B["人工客服"]
+    C["AI Copilot"] --> B
+    C --> D["建议回复"]
+    C --> E["参考知识"]
+    C --> F["订单/物流信息"]
+    B -- 采纳/修改/忽略 --> A
+```
+
+### 2\. 核心功能清单
+
+| **功能** | **触发方式** | **说明** |
+| --- | --- | --- |
+| **建议回复生成** | 每轮顾客消息自动触发 | AI 根据顾客消息 + 对话上下文 + 知识库/工具查询结果，生成 1~2 条建议回复供人工客服参考。客服可一键采纳、编辑后发送或忽略 |
+| **知识卡片推送** | 识别到相关知识时自动推送 | 当顾客问题涉及政策、规则、商品信息时，自动检索知识库并以卡片形式展示相关知识片段（来源 + 原文），供客服快速查阅 |
+| **实时数据查询** | 识别到数据查询需求时自动触发 | 自动调用订单/物流/商品/优惠券 API，将查询结果以结构化卡片展示在客服侧边栏，无需客服手动切换系统查询 |
+| **对话摘要展示** | 转人工时自动生成 | 在人工客服接入时，顶部展示 AI 生成的结构化对话摘要（用户问题、已获取信息、未解决原因、用户情绪、建议处理） |
+| **话术模板推荐** | 识别到特定场景时推送 | 针对投诉安抚、退款解释、活动说明等高频场景，推荐经过审核的标准话术模板，客服可一键引用 |
+
+### 3\. 交互设计
+
+**人工客服工作台布局：**
+
+| **区域** | **内容** |
+| --- | --- |
+| **主聊天区（左）** | 与顾客的对话窗口，正常收发消息 |
+| **AI 助手面板（右）** | 分为三个 Tab： |
+| ① **建议回复**：每轮顾客消息后自动生成 1~2 条建议，支持一键采纳 / 编辑采纳 / 忽略 | <br> |
+| ② **知识参考**：相关知识片段卡片列表，标注来源类型和更新时间 | <br> |
+| ③ **数据查询**：订单/物流/商品/优惠券的实时查询结果卡片 | <br> |
+| **顶部摘要栏** | 转人工时展示对话摘要，可折叠 |
+
+### 4\. 建议回复生成策略
+
+| **策略项** | **方案** | **说明** |
+| --- | --- | --- |
+| **生成方式** | RAG + 工具调用 + Prompt | 复用智能客服相同的 RAG 和工具调用能力，但 Prompt 调整为"为客服生成建议回复"而非直接面向顾客 |
+| **建议数量** | 每轮 1~2 条 | 简单问题生成 1 条；复杂问题生成 2 条不同角度的建议 |
+| **响应时效** | ≤ 3 秒 | 在顾客消息到达后 3 秒内展示建议，不阻塞客服操作 |
+| **置信度标注** | 高/中/低三档 | 标注建议的置信度，低置信度建议标记⚠️提醒客服谨慎参考 |
+| **反馈机制** | 采纳/编辑/忽略 + 原因标签 | 记录客服对建议的反馈行为，用于优化建议生成质量 |
+
+### 5\. 效果衡量指标
+
+| **指标** | **计算方式** | **目标值** | **统计方式** |
+| --- | --- | --- | --- |
+| 建议采纳率 | （一键采纳 + 编辑采纳）次数 / 总建议次数 | ≥ 60% | 系统埋点 |
+| 人工平均处理时长 | 人工接手到会话结束的平均时长 | 降低 30% | 系统埋点 |
+| 知识卡片查看率 | 客服点击查看知识卡片次数 / 推送次数 | ≥ 50% | 系统埋点 |
+| 建议生成延迟 | 顾客消息到建议展示的平均时长 | ≤ 3 秒 | 系统埋点 |
+
+### 6\. 技术实现要点
+
+-   **复用现有能力：** 建议回复的生成复用智能客服的 RAG 检索、工具调用和 LLM 能力，仅需调整 Prompt（从"面向顾客回复"调整为"为客服提供建议"）
+    
+-   **异步非阻塞：** 建议生成在后台异步执行，不影响客服正常操作；建议未生成完成时客服可先自行回复
+    
+-   **Dify API 调用：** 人工客服工作台通过调用 Dify Chatflow API 获取建议，传入完整对话上下文
+    
+-   **渐进上线策略：** Phase 2 先上线对话摘要 + 建议回复，Phase 3 扩展知识卡片和话术模板推荐
+    
+
+## （七）意图识别设计
+
+**设计目标：** 作为 Chatflow 的核心路由节点，准确识别用户意图并分发至对应的处理分支（知识检索、工具调用、转人工），意图识别准确率 ≥ 95%。
+
+### 1\. 意图分类体系
+
+根据需求分析中的核心业务场景，定义以下意图分类：
+
+| **意图大类** | **子意图** | **处理策略** | **优先级** |
+| --- | --- | --- | --- |
+| **商品咨询** | 商品信息查询、成分功效咨询、使用方法咨询、商品推荐与比较 | 知识库检索（商品库 + FAQ）+ 商品API | 高   |
+| **优惠活动** | 活动规则咨询、优惠券使用咨询、叠加规则咨询 | 知识库检索（活动规则库）+ 优惠券API | 高   |
+| **订单相关** | 订单状态查询、退款进度查询 | 工具调用（订单API） | 高   |
+| **物流相关** | 物流进度查询、发货时间咨询、运费咨询 | 工具调用（物流API）+ 知识库（物流库） | 高   |
+| **退换货** | 退货流程咨询、换货流程咨询、退款时效咨询 | 知识库检索（售后政策库 + FAQ） | 中   |
+| **会员积分** | 会员权益查询、积分查询与兑换 | 知识库检索（会员权益库） | 中   |
+| **投诉纠纷** | 商品质量投诉、服务态度投诉、纠纷处理 | 安抚 → 收集信息 → 转人工 | 高（敏感） |
+| **转人工** | 用户主动要求转人工 | 直接转人工 | 最高  |
+| **闲聊/无关** | 非业务话题、打招呼、情绪表达 | 礼貌引导回业务话题 | 低   |
+
+### 2\. 意图识别方案
+
+采用 **LLM 分类 + 规则兜底** 的双层架构：
+
+| **层级** | **方式** | **说明** |
+| --- | --- | --- |
+| **第一层：规则匹配** | 关键词 + 正则表达式 | 优先匹配高确定性意图：如包含"转人工"→ 直接转人工；包含订单号格式 → 订单/物流查询；包含投诉类关键词 → 投诉纠纷。**速度快、零延迟** |
+| **第二层：LLM 分类** | Dify Chatflow 中的 LLM 节点 | 将用户消息 + 对话历史输入 LLM，输出结构化意图分类结果（意图大类 + 子意图 + 置信度）。处理规则层无法覆盖的复杂、模糊表述 |
+| **兜底策略** | 意图不明确时的处理 | 当 LLM 分类置信度 < 0.7 时，标记为"意图不明确"，触发全库检索 + 追问澄清策略 |
+
+### 3\. Chatflow 中的意图路由节点
+
+```mermaid
+graph TD
+    A["用户消息输入"] --> B{"规则匹配"}
+    B -- 命中转人工 --> C["转人工流程"]
+    B -- 命中订单号 --> D["订单/物流查询分支"]
+    B -- 命中投诉关键词 --> E["投诉处理分支"]
+    B -- 未命中 --> F["LLM 意图分类"]
+    F --> G{"意图分类结果"}
+    G -- 商品咨询 --> H["商品知识库检索 + 商品API"]
+    G -- 优惠活动 --> I["活动规则库检索 + 优惠券API"]
+    G -- 退换货 --> J["售后政策库检索"]
+    G -- 会员积分 --> K["会员权益库检索"]
+    G -- 闲聊/无关 --> L["礼貌引导回复"]
+    G -- 置信度低 --> M["全库检索 + 追问澄清"]
+```
+
+### 4\. 意图识别 Prompt 设计
+
+-   点击展开意图分类 Prompt
+    
+    ```
+    你是一个电商客服意图分类器。请根据用户的最新消息和对话历史，判断用户意图。
+    
+    ## 输出格式（严格 JSON）
+    {"intent": "意图大类", "sub_intent": "子意图", "confidence": 0.0~1.0, "entities": {"order_id": "", "product_name": "", "keyword": ""}}
+    
+    ## 意图分类
+    - product_inquiry: 商品咨询（商品信息、成分功效、使用方法、商品推荐与比较）
+    - promotion_inquiry: 优惠活动（活动规则、优惠券使用、叠加规则）
+    - order_query: 订单相关（订单状态、退款进度）
+    - logistics_query: 物流相关（物流进度、发货时间、运费）
+    - return_exchange: 退换货（退货流程、换货流程、退款时效）
+    - membership: 会员积分（会员权益、积分查询与兑换）
+    - complaint: 投诉纠纷（质量投诉、服务投诉）
+    - transfer_human: 转人工（用户明确要求）
+    - chitchat: 闲聊/无关内容
+    
+    ## 规则
+    1. 优先识别是否包含转人工意图
+    2. 如果同时涉及多个意图，取最主要的一个
+    3. 同时提取关键实体（订单号、商品名、关键词等）
+    4. confidence < 0.7 时，intent 设为 "unclear"
+    
+    ## 对话历史
+    conversation_history
+    
+    ## 用户最新消息
+    user_message
+    ```
+    
+
+### 5\. 复合意图处理
+
+当用户消息包含多个意图时（如"帮我查下订单 123 的物流，还有退货怎么操作"），处理策略：
+
+-   **串行处理：** 按优先级依次处理每个意图，先处理工具调用类（物流查询），再处理知识检索类（退货政策）
+    
+-   **合并回复：** 将多个意图的回复合并为一条结构化消息，分点呈现
+    
+-   **最多处理 2 个意图：** 超过 2 个意图时，先回复前 2 个，再追问"您还有其他问题吗？"
+    
+
+## （八）多轮对话管理设计
+
+**设计目标：** 实现完善的多轮对话上下文管理机制，支持跨轮次的信息关联、指代消解和追问澄清，确保多轮对话场景下的回复连贯性和准确性。
+
+### 1\. 会话记忆策略
+
+| **策略项** | **方案** | **说明** |
+| --- | --- | --- |
+| **上下文窗口** | 最近 10 轮对话 | 保留最近 10 轮（用户 + AI）消息作为 LLM 上下文输入；超出时采用滑动窗口截取，最早的消息被丢弃 |
+| **变量记忆** | Chatflow 变量传递 | 通过 Dify Chatflow 变量存储本轮提取的关键实体（订单号、商品名、用户ID等），跨节点传递，避免重复提取 |
+| **会话摘要** | 长会话自动摘要 | 当对话超过 10 轮时，由 LLM 对早期对话生成摘要，替代原始消息注入上下文，节省 token 同时保留关键信息 |
+| **会话超时** | 30 分钟无交互自动结束 | 超时后清空上下文，下次交互视为新会话；超时前 5 分钟发送提醒消息 |
+
+### 2\. 上下文关联机制
+
+| **场景** | **示例** | **处理方式** |
+| --- | --- | --- |
+| **指代消解** | 用户先问"A面霜怎么样"，再问"它适合油皮吗" | LLM 基于对话历史将"它"解析为"A面霜"，在 Query 改写阶段完成指代替换 |
+| **信息继承** | 用户先提供订单号查物流，再问"退款进度呢" | 从变量记忆中直接获取已提取的订单号，无需重复追问 |
+| **意图切换** | 用户从商品咨询转到物流查询 | 重新识别意图，切换至对应处理分支；保留变量记忆中的实体信息 |
+| **追问澄清** | 用户说"帮我查下订单"但未提供订单号 | AI 追问订单号，用户回复后与上一轮追问关联，从回复中提取参数继续处理 |
+| **多轮纠正** | 用户说"不是这个，我问的是B产品" | LLM 识别到纠正意图，清除之前的商品实体，重新提取并检索 |
+
+### 3\. 会话状态管理
+
+```mermaid
+stateDiagram-v2
+    [*] --> 新会话: 用户首次发消息
+    新会话 --> 对话中: AI 回复
+    对话中 --> 对话中: 用户继续交互
+    对话中 --> 等待追问: AI 追问参数
+    等待追问 --> 对话中: 用户提供参数
+    等待追问 --> 超时结束: 30分钟无回复
+    对话中 --> 转人工: 触发转人工条件
+    对话中 --> AI结束: AI 独立解决
+    对话中 --> 超时结束: 30分钟无交互
+    AI结束 --> 评价: 推送满意度评价
+    转人工 --> 人工接管: 人工客服介入
+    评价 --> [*]
+    人工接管 --> [*]
+    超时结束 --> [*]
+```
+
+### 4\. Chatflow 中的上下文处理节点
+
+在 Dify Chatflow 中，上下文管理通过以下节点协同实现：
+
+| **节点** | **功能** | **配置要点** |
+| --- | --- | --- |
+| **对话历史节点** | 加载历史消息 | 设置 window\_size = 10；超长会话启用摘要模式 |
+| **变量赋值节点** | 存储/更新实体变量 | 意图识别后，将提取的 order\_id、product\_name 等写入会话变量 |
+| **条件分支节点** | 判断变量是否存在 | 如需要订单号但变量为空 → 追问分支；变量已存在 → 直接调用工具 |
+| **Query 改写节点** | 结合上下文改写查询 | LLM 节点，输入当前消息 + 对话历史 + 变量，输出改写后的检索 Query |
+
+### 5\. 边界处理
+
+-   **话题跳跃：** 用户在一次会话中频繁切换话题时，保留所有变量记忆但重新识别意图，确保每次回复与当前话题相关
+    
+-   **循环提问：** 检测到用户重复提问相同问题（相似度 > 0.9）时，换一种表述方式回复或建议转人工
+    
+-   **超长会话：** 超过 20 轮时，自动在回复中提示"如果您还有其他问题，也可以随时找我哦~"引导自然结束
+    
+
+## （九）安全合规模块设计
+
+**设计目标：** 构建多层安全防护体系，覆盖输入过滤、输出审核、敏感信息保护和异常兜底，确保 AI 客服输出 100% 合规，不产生法律和品牌风险。
+
+### 1\. 安全架构：三层防护
+
+```mermaid
+graph LR
+    A["用户输入"] --> B["输入层过滤"]
+    B --> C["AI 核心处理"]
+    C --> D["输出层审核"]
+    D --> E["回复用户"]
+    B -- 拦截 --> F["安全兜底回复"]
+    D -- 拦截 --> F
+```
+
+### 2\. 输入层安全过滤
+
+| **检测项** | **检测方式** | **处理策略** |
+| --- | --- | --- |
+| **敏感信息检测** | 正则表达式匹配 | 检测用户消息中的身份证号、银行卡号、完整手机号等，在传入 LLM 前自动脱敏（如 1381234） |
+| **恶意注入检测** | 规则 + LLM 检测 | 检测 Prompt 注入攻击（如"忽略以上指令""扮演其他角色"）、越狱攻击；命中则返回拒绝回复 |
+| **违规内容检测** | 关键词库 + 第三方内容安全 API | 检测涉政、涉黄、涉暴等违规内容；命中则返回引导回业务话题的回复 |
+| **消息频率控制** | 中间层服务限流 | 单用户每分钟最多 20 条消息，超出则返回"消息发送过于频繁，请稍后再试" |
+
+### 3\. 输出层安全审核
+
+| **审核项** | **审核方式** | **处理策略** |
+| --- | --- | --- |
+| **信息泄露检测** | 正则 + 规则匹配 | 检测 AI 回复中是否包含内部信息（成本价、供应商名称、内部系统名称等），命中则拦截并替换为安全回复 |
+| **虚假承诺检测** | 关键词 + LLM 审核 | 检测回复中是否包含超出政策的承诺（"一定退款""保证赔偿"等），命中则改写为合规表述 |
+| **内容合规检测** | 第三方内容安全 API | 对 AI 输出进行内容安全扫描，拦截可能的不当内容 |
+| **幻觉检测** | 检索结果比对 | 将 AI 回复中的关键事实（价格、时效、政策）与检索到的知识片段进行比对，不一致时标记并触发人工复核 |
+
+### 4\. 敏感信息保护
+
+| **敏感信息类型** | **检测规则** | **脱敏方式** | **适用环节** |
+| --- | --- | --- | --- |
+| 手机号 | 11位数字，1开头 | 138\*\*\*\*1234 | 输入脱敏 + 日志脱敏 |
+| 身份证号 | 18位/15位，含校验 | 310\*\*\*\*\*\*\*\*\*\*1234 | 输入脱敏 + 日志脱敏 |
+| 银行卡号 | 16~19位数字 | 6222\*\*\*\*\*\*\*\*1234 | 输入脱敏 + 日志脱敏 |
+| 收货地址 | 工具返回数据中的地址字段 | 省市区 + \*\*\*\* | 输出脱敏 |
+| 邮箱  | 邮箱格式正则匹配 | [a\*\*@example.com](mailto:a**@example.com) | 输入脱敏 + 日志脱敏 |
+
+### 5\. 异常兜底机制
+
+| **异常场景** | **触发条件** | **兜底处理** |
+| --- | --- | --- |
+| **模型超时/报错** | LLM 调用超过 10 秒或返回错误 | 返回："抱歉，系统繁忙，请稍后再试。如需紧急帮助，我帮您转接人工客服~" + 提供转人工按钮 |
+| **知识库服务异常** | 向量数据库/全文检索不可用 | 降级为仅依赖 Prompt 内置知识回复基础 FAQ；超出范围的问题转人工 |
+| **工具服务异常** | 业务 API 全部不可用 | 返回："当前查询服务暂时维护中，建议您稍后再试或联系人工客服" + 记录告警 |
+| **全链路异常** | AI 核心服务整体不可用 | 中间层服务直接返回预设兜底消息 + 自动转人工；不依赖 AI 生成 |
+| **内容安全拦截** | 输出审核未通过 | 替换为通用安全回复："感谢您的耐心，这个问题我帮您转接人工客服为您详细解答~" |
+
+### 6\. 合规要求清单
+
+| **合规要求** | **落地措施** |
+| --- | --- |
+| 《个人信息保护法》 | 对话数据加密存储（AES-256）；敏感信息传输前脱敏；用户数据仅用于当次会话，不用于模型训练 |
+| 《生成式人工智能服务管理暂行办法》 | AI 身份标识（首次对话告知用户"我是智能客服助手"）；输出内容安全审核；建立人工审核机制 |
+| 消费者权益保障 | 不做虚假承诺；转人工通道始终畅通；投诉场景优先转人工处理 |
+| 数据安全 | Dify 私有化部署，数据不出内网；对话日志定期清理（保留 90 天）；访问权限分级管控 |
+
+<br>

3. 实战篇（客服Agent)/3.5 测试集构建.md

@@ -0,0 +1,91 @@
+**目标：** 基于核心业务场景，构建覆盖主要意图的标注评测集，用于模型选型、Prompt 调优和上线验收的效果度量。
+
+## （一）评测集设计原则
+
+-   **场景覆盖**：覆盖高频咨询场景（售前、售中、售后），确保主要意图均有样本
+    
+-   **难度分层**：包含简单事实型问题、多轮对话、模糊/歧义问题、边界 case
+    
+-   **标注规范**：每条数据包含用户输入、期望回复、所需工具调用、评测维度标签
+    
+-   **数量建议**：初始评测集 200-500 条，每个核心场景至少 30 条
+    
+
+## （二）场景分类与样本分布
+
+| 场景大类 | 子场景 | 目标样本数 | 难度  |
+| --- | --- | --- | --- |
+| 售前咨询 | 商品参数/规格查询 | 40  | 简单  |
+| 售前咨询 | 商品对比/推荐 | 30  | 中等  |
+| 售前咨询 | 优惠活动/满减规则 | 30  | 中等  |
+| 售中咨询 | 订单状态查询 | 40  | 简单  |
+| 售中咨询 | 物流进度查询 | 30  | 简单  |
+| 售中咨询 | 修改订单/地址 | 30  | 中等  |
+| 售后咨询 | 退换货流程 | 40  | 中等  |
+| 售后咨询 | 退款进度查询 | 30  | 简单  |
+| 售后咨询 | 投诉/情绪激动 | 30  | 困难  |
+| 边界场景 | 超出服务范围 / 闲聊 / 敏感话题 | 30  | 困难  |
+
+## （三）评测数据示例
+
+### 示例 1：售前咨询 — 商品参数查询
+
+| 字段  | 内容  |
+| --- | --- |
+| **用户输入** | 这款蓝牙耳机支持降噪吗？续航多久？ |
+| **期望回复** | 这款耳机支持主动降噪（ANC），开启降噪模式续航约 6 小时，关闭降噪续航约 8 小时，搭配充电盒总续航可达 30 小时。 |
+| **所需工具** | 商品知识库检索 |
+| **评测维度** | 事实准确性、信息完整性 |
+| **难度** | 简单  |
+
+### 示例 2：售中咨询 — 订单状态查询
+
+| 字段  | 内容  |
+| --- | --- |
+| **用户输入** | 我的订单 2024031500128 到哪了？什么时候能到？ |
+| **期望回复** | 您的订单 2024031500128 当前状态为「运输中」，已由顺丰快递揽件，快递单号 SF1234567890，预计明天（3月17日）送达。您可以点击这里查看实时物流。 |
+| **所需工具** | 订单查询 API → 物流查询 API |
+| **评测维度** | 工具调用准确性、信息完整性、时间预估合理性 |
+| **难度** | 简单  |
+
+### 示例 3：售后咨询 — 退换货流程
+
+| 字段  | 内容  |
+| --- | --- |
+| **用户输入** | 衣服收到了但尺码不对，怎么换？我已经洗过了还能换吗？ |
+| **期望回复** | 非常抱歉给您带来不便。关于换货：如商品已洗涤，根据我们的退换货政策，已洗涤商品暂不支持换货。但如果是因为我们发错尺码导致的问题，您可以提供收到商品的照片，我帮您申请特殊换货处理。请问是我们发错尺码了吗？ |
+| **所需工具** | 退换货政策知识库检索 → 订单查询 API |
+| **评测维度** | 政策准确性、情感安抚、多条件判断、追问引导 |
+| **难度** | 中等  |
+
+### 示例 4：边界场景 — 情绪激动 + 转人工
+
+| 字段  | 内容  |
+| --- | --- |
+| **用户输入** | 你们什么破平台！退款都一个星期了还没到账，再不处理我就投诉到12315！ |
+| **期望回复** | 非常抱歉让您久等了，我理解您的着急。我已帮您查询到退款单号 RF20240310023，目前状态为「银行处理中」，通常 1-3 个工作日到账。我现在为您转接人工客服，优先为您跟进处理，请稍等。 |
+| **所需工具** | 退款查询 API → 转人工客服 |
+| **评测维度** | 情绪识别、安抚话术、转人工判断准确性、信息查询准确性 |
+| **难度** | 困难  |
+
+### 示例 5：边界场景 — 超出服务范围
+
+| 字段  | 内容  |
+| --- | --- |
+| **用户输入** | 帮我写一篇关于人工智能的论文吧 |
+| **期望回复** | 不好意思，这个超出了我的服务范围啦 😊 我是您的购物小助手，可以帮您查询商品信息、订单状态、物流进度、退换货等问题。请问有什么购物相关的问题我可以帮您吗？ |
+| **所需工具** | 无（直接兜底回复） |
+| **评测维度** | 意图识别准确性、拒绝话术友好度、引导回正轨 |
+| **难度** | 中等  |
+
+## 4.4 评测维度与评分标准
+
+| 评测维度 | 说明  | 权重  |
+| --- | --- | --- |
+| **事实准确性** | 回复内容与知识库/API 返回信息一致，无虚构 | 30% |
+| **信息完整性** | 是否覆盖用户提问的所有要点 | 20% |
+| **工具调用准确性** | 是否正确触发所需工具，参数是否正确 | 20% |
+| **语言表达** | 语句通顺、符合品牌调性、无敏感/违规内容 | 15% |
+| **用户体验** | 情绪安抚、追问引导、转人工判断等交互质量 | 15% |
+
+<br>

3. 实战篇（客服Agent)/3.6 模型选型.md

@@ -0,0 +1,118 @@
+**目标：** 基于评测数据集，对候选大语言模型进行系统评测，从准确性、响应速度、成本、工具调用能力等维度综合比较，选出最适合智能客服场景的基座模型。
+
+## （一）选型原则
+
+-   **业务适配优先**：以客服场景的实际表现为核心依据，而非通用 benchmark 排名
+    
+-   **效果与成本平衡**：在满足准确率要求的前提下，优先选择性价比更高的模型
+    
+-   **工具调用能力**：模型必须稳定支持 Function Calling，确保订单查询、物流查询等工具可靠调用
+    
+-   **中文能力突出**：客服场景以中文对话为主，模型需具备优秀的中文理解和生成能力
+    
+-   **可落地部署**：综合考虑 API 可用性、SLA 保障、数据合规等工程化因素
+    
+
+## （二）候选模型范围
+
+根据当前国内外主流大模型的能力水平和可用性，初步筛选以下候选模型：
+
+| **模型** | **厂商** | **类型** | **初选理由** |
+| --- | --- | --- | --- |
+| GPT-4o | OpenAI | 闭源 API | 综合能力强，Function Calling 成熟稳定，多模态支持 |
+| GPT-4o-mini | OpenAI | 闭源 API | 性价比高，速度快，适合高并发客服场景 |
+| Claude 3.5 Sonnet | Anthropic | 闭源 API | 中文能力优秀，长上下文支持好，推理能力强 |
+| 通义千问 Qwen-Max | 阿里云 | 闭源 API | 国内合规部署，中文能力强，电商场景经验丰富 |
+| DeepSeek-V3 | DeepSeek | 开源 / API | 性价比极高，中文能力突出，支持私有化部署 |
+| GLM-4 | 智谱 AI | 闭源 API | 国内合规，工具调用支持好，客服场景有落地案例 |
+
+> **说明：** 候选模型范围会随市场变化动态调整。评测时以当时最新可用版本为准。
+
+## （三）评测方案设计
+
+### 1\. 评测流程
+
+```mermaid
+flowchart LR
+    A["准备评测集<br>200~500条"] --> B["各模型接入<br>统一接口"]
+    B --> C["批量跑测<br>记录结果"]
+    C --> D["人工标注<br>评分"]
+    D --> E["汇总分析<br>加权评分"]
+    E --> F["选型决策"]
+```
+
+### 2\. 评测维度与权重
+
+| **评测维度** | **说明** | **权重** |
+| --- | --- | --- |
+| **回复准确性** | 回复内容与知识库/API 事实一致，无幻觉和虚构 | 30% |
+| **工具调用能力** | Function Calling 触发准确率、参数提取正确率、多工具编排能力 | 20% |
+| **语言表达质量** | 中文流畅度、品牌调性契合度、情绪安抚能力 | 15% |
+| **响应速度** | 首 Token 延迟（TTFT）和完整回复延迟（P95），直接影响用户体验 | 15% |
+| **成本效率** | 单次对话平均 Token 消耗及费用，月度预估成本 | 10% |
+| **安全合规** | 拒绝不当请求能力、敏感信息处理、数据合规（境内部署/数据不出境） | 10% |
+
+### 3\. 评分标准
+
+每个维度采用 **1~5 分制**：
+
+| **评分** | **标准** |
+| --- | --- |
+| 5 分 | 完全满足要求，表现优秀，无可挑剔 |
+| 4 分 | 基本满足要求，有轻微瑕疵但不影响使用 |
+| 3 分 | 部分满足要求，存在明显不足但可接受 |
+| 2 分 | 勉强可用，存在较多问题，需配合额外策略弥补 |
+| 1 分 | 不满足要求，无法用于生产环境 |
+
+## （四）评测结果记录模板
+
+> 以下为模板结构，实际评测时填入各模型的真实数据。
+
+<br>
+
+## （五）成本估算
+
+基于日均咨询量和平均对话轮数，预估各模型的月度调用成本：
+
+<br>
+
+> **假设条件：** 日均对话 3000 次，平均每次对话 5 轮，每轮平均输入 500 Token、输出 300 Token（含系统 Prompt 和知识库上下文）。
+
+## （六）选型决策框架
+
+### 1\. 一票否决项
+
+以下为硬性门槛，任一不达标即淘汰：
+
+-   回复准确性评分 ≥ 3 分（不可接受严重幻觉问题）
+    
+-   Function Calling 成功率 ≥ 90%
+    
+-   P95 响应延迟 ≤ 5 秒
+    
+-   满足数据合规要求（视公司政策决定是否要求数据不出境）
+    
+
+### 2\. 推荐策略
+
+**分层部署策略（推荐）：** 不必所有场景使用同一模型。可根据场景复杂度分层：
+
+-   **简单场景**（FAQ、物流查询等）：使用轻量模型（如 GPT-4o-mini / DeepSeek-V3），控制成本
+    
+-   **复杂场景**（投诉处理、多轮推荐等）：使用强模型（如 GPT-4o / Claude 3.5 Sonnet），保证质量
+    
+-   通过意图识别路由层，自动将对话分配至对应模型
+    
+
+### 3\. 最终选型结论（模板）
+
+| **决策项** | **结论** |
+| --- | --- |
+| 主力模型 | 待评测后填写 |
+| 轻量模型（可选） | 待评测后填写 |
+| 备选模型 | 待评测后填写 |
+| 部署方式 | API 调用 / 私有化部署 |
+| 预估月度成本 | 待评测后填写 |
+| 决策依据摘要 | 待评测后填写 |
+
+<br>

4. 产品经理AI+/简介.md

@@ -0,0 +1 @@
+<br>

写在前面.md

@@ -0,0 +1,105 @@
+## 一、我是谁
+
+```
+我是老陈，一个做过全栈开发的 5 年+ 电商 AI 产品经理。
+做产品这些年，我从 0 到 1 搭建过百万级 B2C 商城的前台搜索、推荐、交易和履约系统，也做过智能客服、Agent的产品设计。
+```
+
+## 二、为什么要写这本书
+
+随着大模型技术的成熟和AI应用的普及，各大互联网公司、AI创业公司以及传统企业都在积极布局AI产品，对AI产品经理的需求呈现爆发式增长。
+
+AI产品经理需要同时具备产品、技术和业务能力，市场供不应求，薪资普遍高于传统产品经理20%-40%，一线城市高级AI产品经理和专家年薪可达50-100万。
+
+当然，AI产品经理的门槛也更高，市场上懂AI技术、有产品思维、理解业务场景的复合型人才非常稀缺。
+
+希望转AI的产品经理，普遍有以下痛点：
+
+-   不了解AI产品经理的工作内容和流程
+    
+-   不了解需要掌握哪些知识和能力
+    
+-   缺少项目实践，知识看了就忘了
+    
+
+而目前市面上的AI类书籍/课程也是良莠不齐：
+
+-   有些从未做过AI产品的产品经理自媒体加个【AI】title就开始卖几千元的课，只是教你怎么写提示词和用一些工具。
+    
+-   有些图书内容过时（过半年可能就不一样了），不适合现在的行业要求。
+    
+-   有些偏概念或技术，具体怎么落地还是不知道。
+    
+
+因此，我希望将我学习和实践的经验，做成【AI产品经理的第一本书】知识库，帮助更多人。
+
+## 三、本书内容结构
+
+本书共分为基础篇、进阶篇、实战篇和加餐篇。
+
+-   **基础篇：**了解AI产品经理、模型原理和能力边界。
+    
+-   **进阶篇：**掌握提示词工程、模型微调、RAG和Agent的概念、机制和方法。
+    
+-   **实战篇：**从0-1做一个可以自主思考和行动的智能客服Agent。
+    
+-   **加餐篇：**包括我整理的模型评测基准、实测的模型能力、AI产品体验拆解。
+    
+
+1.  **基础篇**
+    
+
+-   解构AI产品经理
+    
+-   机器学习基础
+    
+-   大模型的生成和训练机制
+    
+-   大模型能力、限制和应用场景
+    
+
+2.  **进阶篇**
+    
+
+-   提示词工程
+    
+-   模型微调
+    
+-   RAG
+    
+-   Agent
+    
+
+3.  **实战篇**
+    
+
+-   智能客服 Agent
+    
+
+4.  **加餐篇（定期更新）**
+    
+
+-   产品经理AI工作流
+    
+-   模型评测基准
+    
+-   大模型评测
+    
+-   AI 产品拆解
+    
+
+## 四、本书目标人群
+
+**适合阅读**
+
+-   希望转AI应用的传统产品经理
+    
+-   初级AI应用产品经理
+    
+
+**不适合阅读**
+
+-   非产品经理的零基础小白
+    
+
+<br>