微调与RAG

微调与RAG解决不同问题

微调使用训练示例调整模型参数，而检索增强生成在回答时保持模型固定，并在提示上下文中提供相关的外部文档。微调主要是行为和任务适应机制；RAG主要是证据选择和基础机制。

两种方法都不能自动保证正确性。微调的质量取决于示例、训练过程和评估。RAG的质量取决于获取、解析、分块、索引、检索、排名、上下文构建和生成器对证据的使用。

微调与检索增强生成的有用边界是责任单位。一个选择可能定义数据格式、协议、模型或自动化库，而另一个选择则在微调与检索增强生成的背景下定义围绕它的工作流程。将不同层视为替代品会导致不良架构决策：团队比较标签，错过执行边界，并在微调与检索增强生成的背景中发现后两个组件都是必须的。一个合理的比较阐明每个选项接收的内容、改变的内容、返回的内容，以及在微调与检索增强生成的背景下谁操作周围的系统。

关于微调与检索增强生成的实现决策，从所需输出和允许的失败模式开始。在选择微调与检索增强生成背景下的技术之前，写下新鲜度、延迟、确定性、浏览器覆盖、数据所有权、可观察性和维护期望。选择应该是可测试的。一个熟悉的工具并不总是正确的工具，而当一个较小的确定性组件已经满足微调与检索增强生成背景下的合同时，一个新的抽象并不自动构成升级。

微调与RAG一瞥

决策取决于系统是否需要改变模型的行为或现在它可以看到什么证据。

比较矩阵使微调与检索增强生成变得具体，因为每一行描述的是操作后果而不是营销形容词。从工作负载向外阅读行：首先确定输入和预期结果，然后检查控制流、状态、可移植性和操作成本在微调与检索增强生成的背景下。只有当一行改变实际要求时它才重要。例如，广泛的语言支持对一个多语言组织很有价值，但对一个已经拥有自己浏览器运行时的小型TypeScript服务则无关紧要，后者在微调与检索增强生成的背景下。

常见的捷径——知识的微调和风格的RAG——颠覆了最强的默认设置。将变化的事实放在可更新的检索层中；当重复示例显示出稳定行为、仅通过提示无法可靠地传递时，使用微调。

两个管道如何工作

微调管道策划示例，训练支持的基础模型，评估生成的检查点，并部署该模型版本。训练集影响未来输出，而不被复制到每个请求中。

RAG管道获取文档，规范化和分块，构建可搜索的表示，检索查询的候选项，给它们排定顺序，并构建一个基础提示。新鲜度来自更新语料库和索引。引用质量需要保持规范的URL、标题、检索时间、分块边界以及从答案声明回到证据的映射。

针对微调与检索增强生成的生产设计应在日志和指标中暴露这些内部阶段。记录所选择的路径、提供给该路径的输入、返回的文物的身份和验证结果在微调与检索增强生成的背景中。没有阶段级证据，成功的网络请求可能隐藏空数据，流畅的模型响应可能隐藏缺失的工具调用，浏览器脚本可能隐藏导航到错误页面的情况，在微调与检索增强生成的背景中。可观察性属于那些意义发生变化的边界。

选择微调、RAG或两者

将变化最频繁的要求作为第一个决策信号。

上述案例是起点，而不是永久标签。当数据源、浏览器矩阵、模型行为、合规边界或团队所有权变化时，重新评估微调与检索增强生成。一个原型通常优化设置速度，而生产系统必须在微调与检索增强生成的背景下优化证据、访问控制、可预测的失败和可支持性。将选择记录在一个简短的决策记录中，以便下一次迁移基于原始约束，而不是微调与检索增强生成背景下的民间传说。

混合架构并不自动成熟。它创建了两个变化系统——训练数据和检索数据——每个系统都需要版本控制、测试、回滚和所有权。只有在单独评估显示独立价值时，才增加两者。

常见的微调和RAG错误

薄弱的项目通常在定义想要减少的错误之前就选择了一种技术。

• 对原始文档进行训练。 文档并不自动成为高质量输入输出示例以进行行为调优。
• 忽略检索召回。 生成器不能引用检索器从未显示的证据。
• 在没有文档结构的情况下分块。 任意窗口可以将标题、表格、限定词和定义与其上下文分开。
• 仅评估最终答案。 分别测量获取、检索、排名、引用支持和生成。
• 让过时的证据持续存在。 索引需要删除、替换、规范化和新鲜度规则，而不仅仅是增加。

每个微调与检索增强生成的陷阱应该映射到一个可观察的检查。验证最终页面或来源身份，检查所需字段而不是信任状态代码，保留生成结果的确切配置，并在微调与检索增强生成的背景下将获取与转化分开。这将工具争论转变为关于失败合同的诊断。它还防止广泛的变化掩盖第一个破界。

在微调与检索增强生成的设计中保持安全性和合规性。使用授权的公共来源，尊重适用的条款和爬虫偏好，最小化保留数据，并在微调与检索增强生成的背景下将凭证保留在日志和内容之外。一个技术能力强的浏览器、抓取程序、代理或API客户端并不授予权限。运营商仍然对目标范围、数据处理、工作负载限制和重要行动的人类批准负有责任。

在自定义模型之前构建基线

一个强有力的决策从一个跨提示、RAG、调优和混合候选者共享的评估集开始。

1. 定义目标问题、所需证据、可接受的答案行为和失败类别。
2. 使用所选基模型建立仅基于提示的基线。
3. 构建RAG基线并测量获取、检索召回、排名和引用支持。
4. 仅为由基线显示的持久行为错误创建调优示例。
5. 在持有的任务和对抗输入上评估调优后的模型。
6. 仅当联合系统足够改善所列的度量以证明附加操作的合理性时，才结合调优和RAG。

在承诺进行平台范围迁移之前，使用一个小的代表性语料库运行微调与检索增强生成的评估。包含一个正常案例、一个缺字段案例、一个动态或状态案例（如果相关的话）以及一个故意无效的控制案例。在微调与检索增强生成的背景下，无效的控制非常重要：如果它通过，接受测试测量的是传输而非正确性。将证据保留在决策记录旁边，以便可以在微调与检索增强生成的背景下评估未来版本的变更与相同工作负载的关系。

在每个结果记录中保留语料库版本、索引版本、检索器设置、提示版本、模型检查点和评估集。没有这样的血统，团队无法解释质量为何变化或重现早期答案。

公平的微调与RAG测试的度量

单一的答案分数掩盖了负责改进或退步的组件。

在用户获得价值的层面上衡量微调与检索增强生成的差异。框架启动时间、令牌计数或响应状态可能是有用的诊断，但没有证据证明输出在微调与检索增强生成的背景下是正确的。将操作性指标与语义接受度结合：预期记录数、支持的引用、所需的浏览器状态、架构有效文件或在微调与检索增强生成的背景下确认的操作。按类别存储失败，以便团队能够看到质量是否受到输入、控制流、执行或验证的限制，微调与检索增强生成的背景下。

主要参考文献 Anchor 比较： 原始 RAG 研究论文, OpenAI 微调指南，和 AWS 的 RAG 和微调比较。这些来源定义了技术本身；对于微调与检索增强生成的背景下，它们比在比较页面之间复制的功能表更强有力。特定版本的细节在实施升级时应再次检查。

在证据的获取中使用 RAG，在行为的微调中使用微调。

从提示开始，当系统需要新鲜或可检查的证据时添加 RAG，当稳定的示例显示持续的行为差距时添加微调。独立评估每一层，然后再组合它们。

微调与检索增强生成比较的实际结果是一个边界，而不是普遍的赢家。选择满足当前合同的最小系统，在意义发生变化的地方进行仪器化，并在微调与检索增强生成的背景中保留未出现的需求的升级路径。当工作负载需要管理的渲染或代理控制的浏览器会话时，Agent Browser 可以提供该执行层，同时应用程序在微调与检索增强生成的背景下保持目标、架构和接受检查的所有权。

参考文献

• Scrapeless Agent Browser 文档
• Scrapeless Agent Browser 产品概述
• 实时网页数据的代理 RAG 无痕指南
• GitHub 上的无痕开源项目