我正在为机密业务数据规划一个本地 AI 推理系统。主要工作负载将结合文档和音频：转录音频、总结内容、提取信息，并最终使原始材料更易于搜索和使用。

隐私要求使决策的一部分变得简单。数据需要留在经过批准的私有环境中。我更喜欢从运行在我们控制的硬件上的模型开始，但这并不是唯一可能的边界。托管模型服务，如 Azure OpenAI 或 Vertex AI 上的 Gemini，可以成为受控的备选方案。托管 GPU 平台，如 Modal，也可以帮助我在拥有硬件之前测试开源模型。

我的第一反应是问在硬件预算内我能运行多大的模型。我能运行一个 700 亿参数的模型吗？大型专家混合模型呢？如果一些作业可以隔夜运行，也许我可以接受较慢的推理速度来换取更强大的模型。

我现在认为这可能从不同的角度来看。适合内存的最大模型可能仍然不适合这项工作。处理长文档可能需要太长时间，为我需要的上下文留下的内存太少，或者一次只能支持一个请求。较小的模型可能已经满足质量要求，同时给我更好的延迟和更多长输入的空间。在另一个项目中，上下文长度可能比响应速度更重要。在另一个项目中，五秒钟的延迟可能使应用程序无法使用。

在购买硬件之前，我需要找出哪些权衡对这个用例很重要。这意味着首先要收集关于工作的证据，并将硬件购买视为模型评估的结果，而不是其起点。

1、隐私只回答一个问题

说模型必须在本地运行并不能告诉我需要哪个模型。它甚至不能告诉我是否需要一个模型。

音频工作负载使这一点变得明显。我可以使用直接接受音频的模型，或者我可以使用专用的语音识别模型，然后将转录文本传递给语言模型。第二种设计可能更容易在本地运行和评估，因为转录和语言任务有不同的失败模式。

文档创造了类似的选择。有些可能已经包含干净的文本。其他的可能需要在语言模型看到它们之前进行光学字符识别或视觉模型处理。长文档可以完整传递、分成几部分或通过检索处理。

所以第一个选择实际上是一个管道决策：

1. 需要发生哪些任务？
2. 哪些任务属于专门的模型？
3. 哪些任务需要通用语言模型？
4. 哪些步骤必须交互式发生，哪些可以批量运行？
5. 我可以预期每种任务有多少？

对于我的系统，我预计最初只有少数内部用户，一些文档和音频作业可以隔夜运行。这使得原始交互速度对这些作业不太重要。它不会使性能变得无关紧要。隔夜进程仍然需要足够的吞吐量才能在早晨之前完成，而交互式问题对相同文档的延迟要求则不同。

工作负载至少有两种操作模式。将它们视为一个平均请求将隐藏我需要选择硬件的信息。

2、云端不是唯一的备选方案

一旦我允许经过批准的云边界进入比较，我就需要精确地说明我在购买什么。可用的服务分为两个非常不同的类别。

托管模型服务通过其企业云让我访问提供商的模型。Azure OpenAI 和 Vertex AI 上的 Gemini 符合这一点。我不管理权重或推理运行时。我选择模型、区域、容量选项、网络、身份和数据控制，然后提供商操作模型。

托管 GPU 平台为我提供运行开源模型的计算。Modal 符合这一点。我仍然选择权重、精度、推理运行时、容器和扩展规则。平台接管大部分 GPU 配置和调度。

这种差异改变了每个选项如何适应这个项目。

3、Azure OpenAI 作为受控的质量备选方案

Azure 允许客户在 Microsoft Foundry 内部署 OpenAI 模型。根据微软的数据隐私文档，这些部署的提示、完成、嵌入和训练数据对 OpenAI 或其他客户不可用。微软在 Azure 中托管模型，该服务不会将请求发送到 OpenAI 运营的服务，如 ChatGPT 或 OpenAI API。

这与将机密数据发送到普通公共端点不同，但与在硬件上运行我控制的模型也不同。微软仍然在 Azure 内运营该服务并处理请求。一些有状态功能将数据存储在客户的 Foundry 资源中，部署类型决定推理可以在哪里发生，滥用监控可能影响标记内容的处理方式。

"专用"一词也需要谨慎。Azure 预配置吞吐量为部署保留模型处理能力。它比标准共享容量提供更可预测的吞吐量，但不应描述为拥有私有物理服务器。专用端点、托管标识、基于角色的访问和区域处理可以收紧边界。它们不会将其转变为本地推理。

如果最佳本地配置错过重要的质量阈值，或者使用量增长超过机器容量，我可以使用此选项。它既是备选模型，也是备选操作环境。

4、Vertex AI 的 Gemini 作为另一个托管模型选项

Google 通过 Vertex AI 上的 Gemini 提供类似的企业模式。我会比较该服务，而不是消费者 Gemini 应用程序，因为相关的边界是具有相关标识、网络、区域、计费和治理控制的 Google Cloud 项目。

Google 的云服务特定条款规定，未经客户许可或指示，Google 不会使用客户数据来训练或微调其 AI 模型。这些条款还描述了列出的 AI 服务的数据位置控制，以及限制在客户帐户之外存储提示和生成输出。Private Service Connect 和 VPC 服务控制可以限制访问路径并降低数据离开批准边界的风险。Google 还为需要预留、可预测容量的工作负载提供预配置吞吐量。

权衡与 Azure 类似。我获得了对强大托管模型、弹性和企业控制的访问权限。我放弃了对权重和运行时的控制，接受云提供商的处理，并承担该提供商的帐户结构、权限、配额、区域、模型生命周期和定价。

Azure 和 Vertex 是同一类别中的替代方案，而不是一个提供商普遍更安全的证明。正确的选择取决于组织已经批准的云边界、其数据和身份所在的位置、合同内容、哪个模型通过评估以及团队准备承担多少新的平台管理工作。

5、Modal 作为本地部署的桥梁

Modal 解决了不同的问题。它为代码和容器提供托管计算，包括 GPU 工作负载。我可以使用 vLLM 等推理引擎运行开源模型，选择 GPU 类型，并测量我可能稍后在本地使用的相同精度和上下文设置。其 LLM 推理指南将吞吐量、延迟、冷启动和长上下文提示处理视为独立的性能问题。其自动扩展控制可以将容器扩展到零，或者在延迟重要时保持容量 warm。

这使得 Modal 在硬件购买之前特别有用。我可以租用多个 GPU 配置，使用公共或合成评估数据，并收集测量结果，而不是估计特定开源模型是否适合并在昂贵的 GPU 上运行良好。因为我测试的是开源模型和运行时，而不是专有替代品，所以结果与计划的本地系统更相关。

Modal 不提供与 Azure OpenAI 或 Vertex AI 上的 Gemini 相同的抽象。我仍然负责模型许可证、权重、容器、运行时设置、API 和大部分推理行为。冷启动对于大型图像和模型权重可能很显著，而保持容器 warm 需要花钱。Modal 提供区域选择，并在其安全和数据处理承诺中记录通过其推理端点发送的请求和响应有效载荷的零数据保留。这些请求仍然通过 Modal 的基础设施，机密工作负载需要审查服务边界、合同、存储、日志、访问和适用的合规范围。它是托管云计算，不是拥有的硬件，默认情况下不是专用的物理租户。

对我来说，Modal 首先是一个实验性桥梁。它可以在购买硬件之前减少不确定性。如果组织批准，它稍后可以成为突发或批量选项，但这是一个单独的决定。

6、管理工作是决策的一部分

云消除了一些基础设施工作，但引入了不同的工作。这项工作应该与每秒令牌数或模型质量一样参与比较。

对于 Azure，我可能需要理解订阅、资源组、Foundry 资源、Microsoft Entra 标识、角色分配、配额、部署类型、专用端点、成本控制、日志以及它们之间的关系。Google Cloud 有自己的学习曲线版本：组织、项目、计费帐户、IAM 和服务帐户、区域、配额、VPC 服务控制、Private Service Connect、日志记录和模型版本。Modal 的初始表面较小，但我仍然需要管理工作空间、标识、密钥、映像、卷、区域、扩展设置、支出限制和审计要求。

这并不意味着超大规模者自动是错误的选择。现有的技能和基础设施可以使其中一个更容易。已经在 Azure 中运营的团队可能更喜欢 Azure OpenAI，因为其标识、网络、计费和审计实践是熟悉的。对于围绕 Google Cloud 构建的组织也是如此。

在我的情况下，我已经从事 Azure 管理，所以这本身可能有用，但我仍然需要诚实地记录它。它既是项目成本，也是我可能想要进一步发展的技能。如果我将这两个目标混合在一起，我可能会使 Azure 看起来比推理系统实际更简单或更便宜。

我可以使运营成本可衡量：

1. 创建第一个安全、可重现部署的时间。
2. 某人必须理解的资源、权限和服务数量。
3. 另一个操作员重现或恢复它所需的时间。
4. 访问审查、升级、配额请求、监控和成本控制的持续时间。
5. 对提供商特定 API、网络或身份配置的依赖。

对于这个项目，我会这样排列选项：

1. 使用公共、合成或去标识数据筛选开源模型。
2. 使用现有的、借用的或临时的 GPU 容量（如果批准，包括 Modal）来测试实际的开源模型和运行时。
3. 如果本地配置满足质量、上下文、吞吐量和操作阈值，则购买自有硬件。
4. 仅当本地配置错过真实需求或需求超过机器时，才将 Azure OpenAI 或 Vertex AI 上的 Gemini 作为受控备选方案。
5. 在每个合格选项中使用相同的评估案例和阈值，并单独记录管理工作量。

这是我目前的想法：目标仍然是在购买硬件之前选择一个开源模型。Modal 可以改善该购买的证据。Azure 和 Vertex 可以显示托管专有模型是否创造了有意义的能力增益，并在确实如此时提供逃生路线。它们都不应仅仅因为云服务更容易在演示中启动而进入设计。

7、模型只是配置的一部分

模型比较通常将模型名称放在行中，基准分数放在列中。这对于探索很有用，但它忽略了本地系统性能的许多决定因素。

我需要评估的单位是整个配置：

模型 + 精度 + 推理运行时 + 执行环境 + 操作负担 + 工作负载

执行环境可以是自有硬件或经过批准的托管部署。当我更改量化、服务运行时、上下文长度、批量大小或硬件后端时，相同的模型可能表现不同。在托管 GPU 上以全精度运行良好的模型在量化后可能损失足够的质量而无法完成我的提取任务。另一个可能保持其质量，但在我想要使用的运行时中运行不佳。

这也改变了"最佳模型"的含义。我寻找的不是最高的通用基准分数。我寻找的是一个满足所需质量阈值，然后为我提供上下文、速度、内存和操作复杂度之间可接受平衡的配置。

8、从描述工作开始

在创建模型候选名单之前，我想根据系统实际接收的输入编写一个小需求表。

其中一些是硬约束。阻止预期商业使用的许可证会淘汰模型。超出批准隐私边界或缺少所需输入模式的模型或托管部署也是如此。

其他要求是阈值。也许模型必须在至少定义百分比的评估案例中正确提取所有必填字段。也许一批录音必须在固定窗口内完成。一旦配置满足这些阈值，更多的模型容量可能没有实际价值。

阈值很重要，因为没有它们，每个比较都会偏向"更多"。更多参数。更多内存。更多 GPU。更多金钱。

9、任务质量优先于通用智能

公共排行榜通常将多种能力组合成一个分数。这是理解该领域的一种合理方式，但它不能告诉我模型是否能可靠地从我的文档中提取信息或在长转录中保留重要细节。

对于这个项目，我关心更窄的问题：

1. 摘要是否保留了源事实？
2. 模型是否遗漏了重要信息？
3. 它是否每次都能返回有效的结构化数据？
4. 它是否区分缺失信息和负面信息？
5. 它能否指回支持答案的段落？
6. 在重复运行中它有多一致？

最后一个问题很容易被忽视。一个产生一次优秀结果但在接下来的两次尝试中失败的模型在自动化管道中很难信任。跨重复的可靠性可能比稍高的平均分数更有用。

这也是较小模型可能获胜的地方。如果集中的提取任务有明确的指令和受约束的输出，较小模型可能已经跨过质量阈值。只有当其改进改变了应用程序的结果时，较大的模型才能赢得其额外的硬件。

10、宣传的上下文窗口不是可用的上下文窗口

上下文长度对于长文档和转录都很重要。根据模型卡中的上下文数字筛选候选者并称此要求已解决很容易。

该数字只是模型可以接受的最大输入。它很少说明模型如何很好地使用该输入中的信息。

RULER 长上下文研究在随着上下文增长而变得更难的任务上测试模型。许多模型在达到其宣传的最大值之前就损失了大量准确性。该论文是一个有用的警告：接受长提示并很好地推理它是分开的能力。

长上下文也改变了硬件计算。键值缓存随序列增长，并可能占用大部分可用内存。Hugging Face 的缓存文档描述了直接权衡：缓存卸载和量化可以节省内存，但可能以速度为代价。

对于这个项目，我需要测试文档和转录长度的分布，而不仅仅是最长可能的情况。我还需要将完整上下文处理与分段、检索或分层摘要等替代方案进行比较。

具有较小上下文窗口和良好检索管道的模型可能在质量、速度或两者上击败长上下文模型。我不会从模型卡中知道这一点。

11、延迟有多个时钟

"每秒令牌数"很有用，但它不能描述完整的用户体验或完整的批处理作业。

对于交互式工作，我关心第一个令牌的时间。对于长生成，令牌之间的时间很重要。对于文档分析，提示处理可能占主导地位，因为模型必须在生成任何内容之前读取数千个输入令牌。在并发使用下，排队会改变所有这些数字。

vLLM 等服务工具分别跟踪这些：第一个令牌的时间、每个输出令牌的时间、端到端请求延迟、请求数量以及提示和生成令牌分布。其指标文档是本地性能测试应该记录的内容的有用列表。

我计划系统中的两种模式需要不同的测量：

音频增加了另一个阶段。如果转录是瓶颈，快速语言模型帮助不大。我需要计时整个管道，而不仅仅是最终模型调用。但是，对于我的用例，我没有这个问题。我可以使用批处理或离线转录，所以这部分目前不是瓶颈。

12、量化属于评估

硬件决策可能取决于量化。较低的精度可以使模型适合更少的内存，并可能使以前不现实的候选者成为可能。

它还创建了需要自己质量和性能结果的新模型配置。

Hugging Face 的推理内存和速度指南指出，量化以准确性换取内存节省，在某些情况下还以推理时间为代价。这种权衡可能因方法和硬件而异。"模型在四位下工作"因此是经验声明，而不是规范。

我想比较至少可能改变购买决策的精度。如果激进量化的大型模型表现不如压缩较少的小型模型，则较小的模型是更容易拥有的系统。如果较大的模型保持有意义的质量优势，则额外的内存可能是合理的。

运行时支持属于同一测试。llama.cpp 等工具支持许多量化级别和硬件后端，包括 CUDA 和 Apple Metal。这种广度很有用，但每个目标配置仍然需要在接近计划机器的硬件上进行测量。

13、公共基准创建候选名单

我不想测试每个开源模型。公共基准站点可以将字段减少到可管理的集合。

Artificial Analysis 在这里很有用，因为它让我比较通用智能、特定能力评估、长上下文行为、输出速度和开放权重的可用性。它还区分权重可用但商业使用受限的模型。

我将使用这些结果创建一个包含大约三到五个模型系列的候选名单。我还将阅读每个模型卡和许可证，检查运行时支持，并寻找接近文档分析、指令遵循、忠实度和语音的评估。

速度数据有一个重要的限制。Artificial Analysis 报告第一方 API 性能或当第一方端点不存在时托管提供商的中位数。这些结果描述了托管推理。它们不能预测模型在我可能购买的工作站上的运行情况。

这就是我希望公共基准发挥的作用：决定测试什么的地图，而不是购买机器的证据。

14、从真实工作负载构建小型评估

本地评估一开始不需要数百个案例。我宁愿有一小组精心选择的具有已知预期结果的案例。

对于文档，我想要典型输入、长输入、困难格式、缺失信息、冲突段落以及需要精确提取和摘要的任务。对于音频，我想要反映系统将接收的条件的录音，包括影响转录的更困难的案例。我可以使用公共、合成或去标识材料进行早期测试，这样真实机密数据永远不会离开所需的边界。

每个案例都需要一个评分方法。有些输出可以自动比较，例如有效的 JSON、必填字段或转录错误。其他需要用于事实准确性、完整性、无支持主张和有用性的评分标准。高风险案例即使在部署后也可能需要人工审查，因此评估应衡量模型是否认识到它缺乏足够的证据。

我还想要重复运行。一次通过隐藏了不稳定性。

第一个评估矩阵可以记录：

这与我为跨本地和云模型路由任务而开发的能力图密切相关。区别在于生命周期中的点。路由器使用证据为每个请求选择部署。在这里，我需要在本地部署存在之前获得证据，因为它将指导硬件购买。

15、分阶段减少候选者

测试每个模型、精度、运行时和硬件组合将产生太多实验。我计划分阶段缩小选项。

阶段 1：质量筛选

在代表性评估集上运行候选名单。如果托管端点使用相同的开源模型且仅接收公共或合成数据，则可以帮助进行早期筛选。如果数据边界已获批准，Azure OpenAI 和 Vertex AI 上的 Gemini 也可以作为不同的托管候选者进行评估。此阶段会淘汰无论硬件如何都错过任务质量或上下文要求的模型。

阶段 2：配置筛选

使用我可以实际部署的量化和运行时测试剩余的本地模型。临时、借用或租用的硬件可以在永久购买之前填补空白。Modal 在这里很有用，因为它可以在多种 GPU 类型上测试开源堆栈。如果 Azure 或 Vertex 仍在比较中，请将其区域、部署或容量选项以及治理设置记录为配置的一部分。此阶段衡量质量损失、内存使用、单请求性能和操作工作量。

阶段 3：工作负载测试

使用预期的上下文分布和请求模式运行决赛选手。这是我测量并发交互请求、完整隔夜批处理、峰值内存和随时间推移故障的地方。

随着变得更加现实，该过程变得越来越昂贵，但每个阶段的候选者越来越少。

16、寻找决策前沿，而不是一个赢家

我不指望一个配置在每个指标上都领先。

有些选项仍然很容易淘汰。如果一个配置比另一个更慢、使用更多内存并产生更差的结果，它就没有理由保留。在消除这些被支配的选项后，剩下的配置之间的比较更有用。

一个可能提供最佳任务质量但需要更多硬件。另一个可能稍微不那么准确但足够快用于交互式使用。第三个可能适合隔夜批处理，因为它可以高效地处理许多文档。

然后决策变得可见。我可以选择满足每个硬性要求的最简单配置，或者为两种类型的工作保留两个模型。较大的模型可能仍然会获胜，但它会获胜是因为评估发现了有用的能力差异，而不是因为其参数数量感觉更安全。

17、使不确定的部分可逆

没有评估会消除所有不确定性。输入量可能会增长。用户可能会带来更长的文档。量化模型可能会在第一组测试集中缺失的案例类型上失败。更好的开源模型可能在我购买机器后六个月出现。

我仍然可以减少错误的成本。

硬件也可以保留选项。内存余量可能比购买当今可用的最大计算更有价值。标准接口可能比围绕一个模型架构调整整个应用程序更重要。模块化管道让我可以单独替换转录、检索或生成。

这就是妥协变得可管理的地方。我不需要知道每个未来的需求。我需要知道哪些假设是昂贵的可逆的，并首先保护它们。

18、最后，我想要批准购买之前的内容

在选择硬件之前，我想要一个简短的决策记录，包含：

1. 任务和批准的隐私边界，包括云推理仍然合格时的确切提供商、服务、区域、存储、网络和监控条件。
2. 工作负载分布，包括上下文长度和批量大小。
3. 最低质量和性能阈值。
4. 用于创建候选名单的公共证据。
5. 本地评估集和评分方法。
6. 每个模型、量化、运行时和测试机器的结果。
7. 每个合格环境所需的设置、学习和持续管理。
8. 所选配置中接受的妥协。
9. 如果质量、上下文或用法与假设不同，则备选方案。

此列表不是为了证明所选模型将保持最佳。模型变化太快，而硬件可能使用多年。相反，这是为了回答一个更有用的问题：根据我今天对工作的了解，此购买是否有证据支持，如果我的假设错误，改变方向有多困难？

这就是我对此项目（和我的客户）想要的标准。我的初始偏好仍然是运行在我们控制的硬件上的开源模型。Modal 可以帮助我在承诺机器之前测试该选择。Azure OpenAI 和 Vertex AI 上的 Gemini 使偏好不那么脆弱：如果本地推理不能满足真实需求，我有受控的托管路径可以评估，而不是悄悄降低质量标准。

我不需要在购买硬件之前获得确定性。我需要足够的证据表明决策是合理的，并且足够的可逆性，使妥协不会成为永久约束。

原文链接：How I'm Choosing an Open Model Before Buying the Hardware

汇智网翻译整理，转载请标明出处

当模型提供商首次宣布上下文窗口达到 100 万，然后是 200 万或 400 万令牌时，感觉就像魔法一样。我记得当时想我们可能永远不需要担心提示分块 [ 1 ] 或上下文截断 [ 2 ] 了。只需将整个代码库或整个书籍库转储到提示中，让 LLM 来处理，对吧？

不幸的是，生产现实很快给了我们一盆冷水。处理数百万令牌不仅极其昂贵；它还会将推理速度拖慢到爬行速度，并降低模型实际检索埋藏在大量上下文负载中间的关键细节的能力。

在这篇博客中，我们将探讨当 LLM 处理上下文时，底层真正发生了什么。我将带您了解主要的内存瓶颈、四种核心的基于论文支持的上下文管理类型，以及当今流行的模型和框架如何在生产中解决这些挑战。

1、为什么上下文如此昂贵

要理解为什么上下文管理如此关键，我们首先需要了解大型语言模型如何处理推理。推理发生在两个不同的阶段：

• 预填充阶段 [ 3 ]，模型摄取整个输入提示
• 解码阶段，模型自回归地逐个生成输出令牌。

在解码期间，为了避免在每个步骤重新计算过去的键和值向量，系统将其缓存在 GPU 内存中。这被称为键值（KV）缓存 [ 4 ]。虽然这加快了计算速度，但它创建了巨大的内存占用，随着序列长度和批处理大小线性增长。

图 2 描述了预填充和解码阶段。

例如，服务一个 1750 亿参数的模型，批处理大小为 128，序列长度为 2,048 个令牌，仅 KV 缓存就需要大约 950 GB 的显存。这比模型权重本身的静态内存占用还要多得多！

此外，标准 GPU 内存分配通常遭受严重的碎片化 [ 3 ]。当为最大序列长度连续预分配内存时，60% 到 80% 的 GPU 内存最终被浪费。

因此，内存带宽，而不是原始计算能力，成为生产 LLM 部署的主要瓶颈。

2、四种核心的上下文管理类型

根据我的经验，我发现现代上下文管理框架分为四种核心技术类型，以及专门的网络传输协议。在图 3 中，您可以查看四种类型。

让我们在接下来的部分中分解每种类型的工作原理。

类型 1：虚拟化和系统分页

从操作系统的虚拟内存中汲取灵感，这种方法将逻辑提示序列与物理 GPU 内存布局解耦。

这里的标准承载者是 PagedAttention [ 3 ]。它将 KV 缓存分成可以非连续存储的小物理块。查找表将逻辑令牌映射到物理页面，将内存浪费从 60% 以上减少到 4% 以下。

更进一步，SGLang 的 RadixAttention [ 5 ] 在分层基数树数据结构中管理缓存的提示块。当多个请求共享系统指令或少样本示例时，SGLang 立即重用现有的 KV 缓存块，将初始首个令牌时间（TTFT）降低到接近零。

类型 2：算法稀疏性和注意力汇聚

你知道吗，在长提示中，只有不到 3% 的注意力头在任何给定时刻是活跃的？稀疏性技术正是利用了这一现象。

• StreamingLLM [ 6 ] 发现了"注意力汇聚"的概念。通过永久保留最初的 4 个初始令牌以及最近令牌的滑动窗口，模型可以无限期地继续生成文本，而不会出现内存溢出或 Softmax 崩溃。
• DuoAttention [ 7 ] 将注意力头分为"检索头"（需要完整的长程注意力）和"流式头"（只需要局部上下文）。通过压缩流式头，它将 KV 内存减少高达 2.55 倍，同时在单个 80GB GPU 上容纳 330 万个令牌。
• MInference 1.0 [ 8 ] 专注于加速 100 万+令牌提示的预填充阶段。它使用自定义 Triton GPU 内核搜索特定的空间稀疏模式（A 形、垂直斜线和块稀疏），消除高达 95% 的注意力 FLOPs，并将预填充速度提高 10 倍。

类型 3：潜在和时间张量压缩

与其保持高维向量，张量压缩直接减少 KV 表示的数学占用。

一个主要例子是多头潜在注意力（MLA） [ 9 ]，用于 DeepSeek-V2/V3 模型。MLA 在推理期间将 key 和 value 矩阵投影到低秩潜在子空间中。与标准多头注意力（MHA） [ 10 ] 相比，这将 KV 缓存占用压缩了惊人的 93.3%。

作为架构低秩投影的补充，量化技术如 KIVI [ 11 ] 对每个通道的 keys 和每个令牌的 values 应用非对称 2 位量化，在不牺牲准确性的情况下大幅降低内存需求。

类型 4：上游提示蒸馏

如果我们能在上下文到达目标 LLM 之前就压缩它呢？这就是上游提示压缩的目标。

像 LLMLingua-2 [ 12 ] 这样的框架使用小型快速模型（如微调的 BERT 变体）来评估令牌信息熵。它将提示压缩视为令牌分类问题，在将负载发送到昂贵的黑盒 API（如 GPT-4o）之前丢弃低信息和重复的令牌。这可产生高达 20 倍的压缩，同时降低成本和延迟。

3、长上下文 vs. RAG

我从工程团队听到的一个常见问题是：

"既然模型现在支持 100 万个令牌，我们还需要 RAG 吗？"

简短的回答是是的。最近的学术基准（如 LaRA）表明，扩展上下文窗口会引入严重的噪声饱和。当关键信息位于大型上下文窗口的中间 30% 到 70% 时，模型准确性会急剧下降，这种现象被称为**"在中间丢失"**。

研究强调了 RAG vs. 长上下文辩论中的几个关键细微差别：

1. 128k 逆转阈值：在中等长度（低于 32k 令牌）下，原生长上下文模型通过捕获文档分块会破坏的多跳关系而优于 RAG。然而，超过 128k 令牌后，噪声饱和导致长上下文准确性下降，让干净的 RAG 管道以 +3.68% 重新获得领先。
2. 硬负样本脆弱性：虽然 RAG 过滤掉噪声，但它仍然容易受到"硬负样本"的影响，即检索到的段落在语义上看起来相关，但包含事实误导性信息。
3. 混合解决方案（自路由）：结合两种世界最有效的方法是自路由架构**。该框架使用轻量级自反思将简单的事实查询路由到廉价的 RAG 管道，同时将复杂的多文档推理任务委托给完整的长上下文 LLM。

4、框架

那么，您的应用程序应该选择哪种上下文管理策略？根据我的经验，下表建议针对特定用例使用哪种技术：

5、结束语

当我们退后一步审视整个领域时，一个清晰的教训浮现出来：

有效的上下文管理是一门软件工程和系统设计学科，而不仅仅是等待更大的硬件上下文窗口的问题

在不优化的情况下将上下文窗口从 32k 扩展到 100 万个令牌，就像在爆胎的汽车上安装更大的油箱一样。硬件收益很快被二次注意力成本、内存碎片化和检索退化所吞噬。

通过应用虚拟内存分页、动态注意力稀疏性、潜在压缩和混合 RAG 路由，我们可以构建不仅更快、更便宜，而且更善于从嘈杂数据中提取真正信号的 AI 架构。

原文链接：Beyond the 1-Million Token Illusion: The Real Engineering Behind LLM Context

汇智网翻译整理，转载请标明出处

在过去，探险家们周游世界，创造美丽的地图。

Abel Tasman 在 1642 年航行，这就是他绘制的澳大利亚和新西兰地图。

如果我高亮显示澳大利亚和新西兰，它与今天的形状相去甚远。

在这些旅行中，他们会观察物种并编目。他们会发现新事物。

这里的关键词是观察。库克船长地图的准确性令人惊叹，它们在首次绘制后近 100 年里一直被用作新西兰的基础地图。

让我们看看 observe 这个词的定义。

Observe。注意到或感知某事，并将其记录为重要。

我们的祖先拥有出色的观察和感知能力。他们分心更少，这给了他们更多专注的空间。

我最喜欢的例子是金字塔。吉萨大金字塔与真正的北、南、东、西对齐，误差约为 0.05 度。

这种精度与现代测量相媲美，尽管他们没有 GPS，这绝对令人惊叹。

他们是怎么做到的？通过观察。他们仰望星空。他们观察影子是如何形成的。他们随着时间的推移反复测量。

他们在 4,600 年前就做到了。

人类难道不简单地令人惊叹吗？

1、让我们观察商业是如何变化的

让我们回到 1900 年代早期，电脑出现之前，观察《纽约时报》的办公室。

我们观察到办公室什么？

• 没有电子邮件或电脑 — 取而代之的是大量的电报、信件和电话
• 看起来非常协作。实际上看起来很有趣，只是大家都在一起工作。
• 工作非常触感。看，桌子上堆满了纸张、笔记和备忘录。
• 只有白人男性，而且他们都穿着同样的服装。

我选择这张照片是因为它剥离了很多东西。特别是电脑、工具和技术。如果我们用一句话来总结这个企业，它看起来会是这样。

这就是我们将称之为的企业核心。关键是在过去，企业的核心主要是"触感/面对面/手工"的。

现在我们穿越时间到 1997 年。

关键的变化是他们现在使用软件，仍然有纸张，但没有智能手机。电脑显然是重大变化，它开启了技术时代。

我们将在下面的图表中添加一个蓝色圆圈。

这个蓝色层有趣的地方在于它是围绕核心的抽象。这反映了现实。企业的核心是人与人之间的联系，但工具允许这种联系变得合成。好处是我们获得了更大的规模。缺点是它可能感觉人造的。

另一个好处是这个蓝色层允许我们通过数字世界在物理世界中做事情。想想预订 Airbnb 或 Uber 或观看 Netflix。这些都是从蓝色层可能的。

但是拥有电子邮件不足以创建 Netflix。它需要一整个黄色层。黄色层基本上是编排蓝色层工具的一种方式。

这基本上是 AI 之前组织的映射。我可以毫不夸张地说，这是大多数人仍然拥有的思维模型，当他们想到企业时。

2、那么 AI 适合什么位置？

我认为 AI 添加了一个新的智能层，它只与企业核心相邻一步。

在 2016 年的模型中，组织智能主要存在于人员中。组织的核心由人类专业知识、他们的知识和关系定义，而软件系统主要存在于记录交易、存储信息和报告已经发生的事情。

CRM、ERP 和协作工具是必要的基础设施，但它们是被动的。洞察是手动创建的，决策是间歇性的，价值通过经验和机构记忆缓慢积累。

在 AI 原生组织中，智能是基本的，它是上图中的新黄色层。

组织开始表现得更不像工具和角色的集合，而更像一个具有记忆、感知和代理的系统。

3、你需要投资黄色层

我相信新层是你需要为战略优势构建的地方。

这有道理。如果你正确设置智能，其他一切都会水到渠成。如果你建立企业的数字大脑，它可以开始为你做人类曾经做的事情，但更快更便宜。

Anthropic 使用 AI 在不到 2 周内构建了他们的新产品 Claude Cowork。

这就是我想象那个过程中发生的事情。

他们的黄色智能层访问了构建新产品所需的工具。它打开程序和文件，基本上做了人类曾经做过的所有事情。

我认为这表明，现在你的优势实际上来自于你将公司的知识和"核心"转化为有形行动的能力。

这个建议的奇怪之处？这里真的没有现成的产品可以购买。这就像一种思维方式，每个企业都表现得非常不同。

对于我的客户来说，它表现为一个全新的中间件层，完全定制于企业。例如，对于我的一个客户，我们有一大堆董事的记录，保存着他们如何做决定，这为我们提供了基础，让 AI 然后去使用他们的工具，基本上像他们一样行事。对于非常复杂的任务不是 100% 完美，但对于简单指令效果很好。

它也不一定像旧的传统 SAAS 那样昂贵。我看到这些项目从 10,000 美元开始，随着黄色层慢慢吞噬企业的其他部分，它们不断扩展范围。

4、当你运作良好时，你会注意到什么迹象？

很明显，如果我们回到 120 年前的《纽约时报》，我们可以告诉他们事情会发生变化。

那么一个"AI 增强"的组织将如何改变？

我认为成功会感觉更平静，更少混乱，但与此同时它会消耗精力，因为它需要大量的智力专注。

扩展一下，我也认为成功会涉及更多午餐、更多散步、更多阳光下的时间、更多阅读和深度学习。我认为我们会更接近古希腊人，花很多时间思考什么是正确和正确的事情。

老实说，想到这一切有点奇怪。

正如我们深情地回顾上面的照片，因为工作如此手工，我认为我们会把我们当前的企业视为智力上手工的。

我们将嘲笑它是多么原始，我们必须自己打字，一切都手工完成，而且我们必须在没有辅助的情况下思考那么多事情。

原文链接：What Comes After Software?

汇智网翻译整理，转载请标明出处

一个单独得分为 30% 的模型在 Nvidia 的代理框架内得了 100%。同一个模型，没有重新训练，70 分来自周围的脚手架。

这是一个名为 ARC-AGI-3 的基准测试。

它将 AI 放入一个不熟悉的回合制世界中，没有说明。没有规则，没有目标，没有教程。它必须通过玩游戏来弄清楚游戏是什么，就像有人让你坐在一个棋盘前，棋子你从未见过一样。

当它推出时，人类清除了 100% 的环境。世界上最好的 AI 管理了 0.37%。

两年的进展之后，Claude Opus 5 将其提高到 30.2%。ARC Prize 称这是一个真正的推理飞跃，而不是基准黑客，这不是他们经常给予的赞美。

然后在 8 月 21 日，Nvidia 发布了 100.00 的分数。所有 183 个关卡，所有 25 个环境。

运行 Claude Opus 5。

而且它不仅仅是勉强通过。评分指标奖励在不浪费移动的情况下解决关卡，根据首次人类需要的操作数量来衡量。AVO 使用了 6,624 个环境操作，而之前的领导者使用了 7,542 个，因此它以少 12% 的慌乱完成了所有内容。

1、同一个模型。完全相同的模型。

这是值得深思的部分。

Nvidia 没有训练任何东西。它没有微调、蒸馏或以任何方式改进模型。它拿取得分为 30% 的模型，将其放入一个名为 AVO 的系统中，该系统得了 100%。

七十分，来自包装。

Nvidia 自己的框架对于公司博客来说异常简单：模型很重要，但模型不是整个代理。

2、框架实际做了什么

两件事，都不需要博士学位就能理解。

它记住。 AVO 保留它已经尝试过的内容以及发生的情况的持久记录。当代理回来时，它不会重新探索已经覆盖的领域，因为记录就在那里。

它监视。 一个单独的监督层位于主代理之上，跟踪整体轨迹是否在前进，并在进展停滞时推动。

就这样。记忆和监督者。

其余的是一个循环。检查、计划、实施、评估、重复，这大致是一个称职的工程师对尚未理解的问题所做的。

3、为什么我相信这一点，因为我已经测量了差距

过去几周我一直在进行实验，正是这两个组件解决的失败，数字以令人不安的方式吻合。

关于记忆。 我让两个相同模型的副本相互下棋，唯一的区别是每个模型看到的内容。一个得到了棋盘位置。另一个得到了移动列表，必须在脑海中重建棋盘。

得到棋盘的那个模型非法移动减少了 65%。同一个模型，同样的游戏。整个区别在于状态是提供的还是记住的。

然后我运行了第三个条件，其中模型必须在移动之前自己写出棋盘。这根本没有区别。被给予状态帮助很大。生成自己的副本没有任何作用。

第三个结果强化了这一区别。 另外，我在两个模型上运行了 360 次依赖算术链试验，长达 1,280 步。零错误。一个也没有，无论长度如何。

原因是在该任务中，状态就是答案。每一步的结果都被写入输出，下一步在那里读取。没有任何内容需要重建。

将这三个结果放在一起，规则就出现了。当自生成状态与输出相同时，它有效。当它必须从其他东西派生时，它就失败。 从移动列表派生的棋盘是派生的。运行总计不是。

AVO 的持久记忆是提供的状态。这就是它有效的原因。

关于监督者。 我让三个模型设计棋盘游戏，模拟了数千次，并将每个模型自己的失败报告交给它们。

它们正确诊断了自己的损坏游戏。一个写道，贪婪的玩法已经退化为一个循环，其中第一个玩家被迫向第二个玩家提供令牌，这完全正确。另一个追溯了为什么座位一赢得每场比赛的确切算术。

然后，五次中有五次，修复失败了。 其中五次中有三次在这个过程中破坏了其他东西。

正确的诊断。错误的修复。每次都是。

监督层是一个外部观察者注意到事情已经停止取得进展。这正是那些模型自己都无法做到的。

4、他们做的不是基准测试的东西

分数下面隐藏着一个我觉得比分数更有说服力的结果。

在 ARC-AGI-3 之前，AVO 是完全为其他事情构建的：在 Nvidia 自己的硬件上优化 CUDA 内核。在一个注意力内核任务上，它连续运行了七天，探索了 500 多个方向，提交了 40 个不同的内核版本，并产生了在 DGX B200 系统上比 FlashAttention-4 快高达 10.5% 的代码。

FlashAttention 不是一个软目标。它是该领域中优化程度最高的代码之一，由以此为生的人们精心打造。

在真实工程问题上进行七天的无人监督迭代，由硬件基础测试决定每次尝试是否更好，这比排行榜更难伪造。而且它是相同的架构。Nvidia 交换了任务接口，将谜题环境作为纯文本 64x64 网格提供，完全没有图像，并让循环保持不变。

一个为调整 GPU 内核而构建的代理解决了一个它从未设计过的交互式推理基准。这种转移是实际的主张，它比 100.00 更大。

5、诚实的范围

两个注意事项，Nvidia 首先提出了这两个，这值得说明。

这只是公开集。 ARC-AGI-3 保留半私有和私有保留集，两者都没有测试。Nvidia 更新了自己的措辞以使边界更清晰，称基准已解决会夸大发生的事情。

Nvidia 警告不要将 30 与 100 的比较视为受控消融。 两次运行不是作为干净的 A/B 设置的。差距足够大，方向没有疑问，但它不是实验室结果。

还有一件事对 Nvidia 有利。他们使用的模型是 Anthropic 的，不是他们自己的，也不是合作伙伴的。如果你设计这个来奉承自己，你不会选择竞争对手的模型作为大脑。

6、如果你正在构建某些东西，这意味着什么

当代理表现不佳时，本能是伸手去拿更好的模型。这种本能现在可以衡量地错误了，至少对于长任务来说。

七十分来自记忆和监督。无论下一个模型版本给你什么，它都不可能给你七十分。

三件事随之而来。

给你的代理状态。不要让它记住。 我的国际象棋数字说这值得 65% 的错误，而要求模型自己写摘要则毫无价值。

在循环外部放一些东西来监视循环。 无法注意到自己卡住的东西就是卡住的东西。

并对整个系统进行基准测试，而不是模型。 裸模型的排行榜几乎无法告诉你一个构建良好的代理会用它们做什么。一个 30% 的模型以 100% 完成了这个。

还有第四个，这是人们跳过的一个，因为它听起来像记账。

保留已经尝试过的内容的记录。 不是摘要，是记录。AVO 的记忆存在是为了让代理停止重新探索一小时前覆盖的领域，在我的游戏设计实验中，这正是出错的地方：三个模型不断提出修复他们已经正确诊断并且已经无法解决的问题的修复方案，没有任何东西将失败向前推进。

这四个都不需要新模型。它们需要有人构建无聊的部分。

7、我不断回顾的部分

两年来，故事一直是模型变得更好，一切下游都会改善。

在这里，模型完全保持原样。有人为它构建了记忆并给了它一个监督者，它从十次中有七次失败变成了零次失败。

有趣的前沿可能根本不在模型内部。它可能是围绕它的相当不起眼的工程。

这是好消息，不仅因为无聊的部分更便宜。当实验室决定发布时，新的前沿模型就会到来，你无法让它更快发生。当你编写它们时，记忆层和监督者就会到来。

Nvidia 的措辞是模型很重要，但模型不是整个代理。根据证据，模型是它的 30%。

原文链接：Your AI Agent Does Not Need a Better Model. Nvidia Proved It

汇智网翻译整理，转载请标明出处

你发布了一个 LLM 智能体。然后呢？

你熬夜把 GPT-4o、向量数据库和复杂的路由提示词组装在一起。你部署了新的 RAG 应用。用户真的在调用 API。然后……一片寂静。

你完全不知道它是否真的表现良好。你的标准错误日志显示 HTTP 状态码，但它们完全没有告诉你为什么你的智能体给了一个奇怪的、幻觉化的答案——用户刚刚截图并在 Twitter 上艾特了你的团队。

这就是超越简单聊天提示词的现实：生产环境是一个黑盒。

你无法用 console.log() 来调试一个 15 步的 RAG 管道。你无法为非确定性的模型行为编写标准单元测试。你肯定无法向你的 CTO 解释为什么你的客服智能体告诉用户他们的订单"可能存在于宇宙的某个地方"。

1、缺失的可观测性层

这就是 Langfuse 的用武之地。它提供了复杂的 RAG 系统和自主智能体真正需要的深度追踪和遥测。

你不再需要猜测用户会话期间发生了什么，而是获得：

• 完整追踪： 可视化智能体执行的整个生命周期——从初始查询重写和向量数据库检索步骤到最终的 LLM 综合。
• 结构化评估： 运行自动化评分管道来测试幻觉、相关性和毒性。
• 提示词管理： 独立于应用代码部署来对提示词进行版本控制。
• 回归测试： 从真实用户交互中构建"黄金数据集"，确保模型更新不会破坏现有行为。

所有这些都打包在一个开源平台中。

2、我们要构建什么

本指南是一个实用蓝图，用于将你的 RAG 和智能体工作流从脆弱的原型转变为生产级部署。我们将分解核心架构概念，为 AI 客服智能体提供一个动手实现的示例，并诚实地比较 Langfuse 与替代工具，以便你为团队选择正确的技术栈。

让我们打开这个黑盒。

3、什么是 Langfuse，为什么它存在？

在 Langfuse 之前，构建 LLM 应用的工程团队遇到了一个令人沮丧的事实：当你的核心应用逻辑由非确定性统计模型处理时，传统的调试工具就失效了。

你无法在神经网络中设置断点。你无法保证相同输入产生相同输出。当智能体失败时，bug 通常不是语法错误，而是格式不良的提示词、向量数据库中糟糕的文档分块策略，或者基础模型本身的意外行为。

Langfuse 由 Max Langkamp、Marc Klingen 和 Clemens Rawert 于 2023 年创立，当时他们在构建自己的 AI 应用时遇到了这些确切的障碍。他们在 Apache 2.0 许可证下开源了该平台，它很快成为 GitHub 上最突出的 LLM 工程工具库之一。

它解决什么问题？

当你从简单的 API 调用转向多步骤 RAG 管道和自主智能体时，操作挑战完全转变：

4、核心概念：追踪、跨度、生成和评分

在编写第一行代码之前，你需要理解 Langfuse 的四个基础原语。如果你曾经使用过 OpenTelemetry，这些概念会立即让你感到熟悉，但它们专门为 RAG 管道和自主智能体量身定制。

它们决定了数据在平台内部的结构：

1. 追踪（Trace）

追踪代表你的应用程序中一个完整的端到端操作——通常是一个单独的用户请求。它作为整个数据树的根，捕获关键的顶级元数据，如唯一 ID、可选名称、用户或会话 ID 以及总执行时间。把它想象成分布式系统追踪中的请求追踪，只是它包含了你整个 LLM 推理链。

2. 跨度（Span）

跨度是追踪中任何不是显式 LLM 调用的工作单元。跨度包装了围绕模型的工程逻辑。数据库查询、向量相似性搜索、文档重排序步骤或外部 API 调用都变成跨度。由于你可以任意深度嵌套跨度，它们允许你将复杂的多步骤智能体行为映射成清晰的可视化调用树。

3. 生成（Generation）

生成是专门为 LLM 调用保留的特殊类型的跨度。Langfuse 独立跟踪这些，因为它们需要独特的跟踪参数。生成会自动捕获确切的输入消息、模型输出、提示词名称和 token 计数。你永远不需要手动计算成本；Langfuse 引用自己的托管定价数据库来实时计算 token 支出。

4. 评分（Score）

评分是直接附加到追踪、跨度或生成的质量信号。评分是将 Langfuse 从被动日志工具转变为真正评估平台的机制。它们允许你基于三个来源附加量化指标：

• 人工审核员： 直接在 Langfuse UI 中注释生产输出。
• LLM 裁判： 大规模运行自动化评估以检查相关性或语气。
• 你自己的代码： 以编程方式执行基于规则的检查（例如，验证输出是否包含必需的免责声明或是否是有效的 JSON）。

5、五分钟完成设置

步骤 1：创建 Langfuse 帐户

访问 cloud.langfuse.com，创建一个项目，然后从 Settings → API Keys 获取 API 密钥。

步骤 2：安装 SDK

# Python
pip install langfuse openai anthropic

# Node.js
npm install langfuse openai

步骤 3：设置环境变量

# .env
LANGFUSE_PUBLIC_KEY=pk-lf-xxxxxxxxxxxxxxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxxxxxxxxxxxxxx
LANGFUSE_HOST=https://cloud.langfuse.com  # 或你的自托管 URL

步骤 4：你的第一个追踪（直接集成）

这就是 Langfuse 获得"零配置"声誉的地方。如果你使用 OpenAI 或 Anthropic，只需替换你的导入，然后就完成了：

import os, base64
from dotenv import load_dotenv
load_dotenv()

# 一次性 OTEL 设置 → 将追踪发送到 Langfuse
# (langfuse.anthropic 在 v4 中已移除；这是 v4 的等效版本)
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry import trace
from opentelemetry.instrumentation.anthropic import AnthropicInstrumentor

auth = base64.b64encode(
    f"{os.environ['LANGFUSE_PUBLIC_KEY']}:{os.environ['LANGFUSE_SECRET_KEY']}".encode()
).decode()
provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(
    OTLPSpanExporter(
        endpoint=f"{os.environ['LANGFUSE_BASE_URL']}/api/public/otel/v1/traces",
        headers={"Authorization": f"Basic {auth}"}
    )
))
trace.set_tracer_provider(provider)
AnthropicInstrumentor().instrument()

# 之前
# from anthropic import Anthropic

# 之后——没有其他变化
from anthropic import Anthropic

client = Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is LLM observability?"}]
)

print(message.content[0].text)
# ✅ 现在你的 Langfuse 仪表板中会出现一个追踪

就这样。没有配置、没有包装器、没有额外参数。每次调用都会自动追踪，包含完整的输入、输出、模型、token 和成本。

6、你将在仪表板中看到什么

运行该代码后几秒钟内，你的 Langfuse 仪表板将显示：

• 发送给模型的确切消息
• 模型的完整响应
• 延迟（首 token 时间 + 总时间）
• token 计数（提示词、补全、总计）
• 以美元计的成本（自动计算）
• 所有跨度的时间线视图

7、使用 @observe() 构建结构化追踪

直接集成对简单脚本很有用。对于真实应用——RAG 管道、智能体、多步骤链——你需要结构化追踪来准确显示每个步骤发生了什么。

Langfuse 的 @observe() 装饰器是为此的主要工具。它包装任何 Python 函数并在追踪树中创建一个跨度。

基本装饰器用法

from dotenv import load_dotenv
load_dotenv()

from langfuse.decorators import observe, langfuse_context
from anthropic import Anthropic

client = Anthropic()

@observe()
def retrieve_documents(query: str, top_k: int = 5):
    docs = vector_db.similarity_search(query, k=top_k)
    langfuse_context.update_current_observation(
        metadata={
            "num_docs_retrieved": len(docs),
            "top_score": docs[0].score if docs else None
        }
    )
    return [doc.page_content for doc in docs]

@observe()
def rerank_documents(query: str, docs: list):
    reranked = cross_encoder.rank(query, docs)
    return reranked[:3]

@observe()
def answer_question(user_query: str, user_id: str):
    langfuse_context.update_current_trace(
        user_id=user_id,
        tags=["rag", "production"],
        session_id=f"session_{user_id}"
    )
    docs = retrieve_documents(user_query)
    top_docs = rerank_documents(user_query, docs)
    context = "\n\n".join(top_docs)
    message = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        messages=[
            {
                "role": "user",
                "content": f"Answer based on this context:\n{context}\n\nQuestion: {user_query}"
            }
        ]
    )
    return message.content[0].text

answer = answer_question("What is our return policy?", user_id="user_42")
print(answer)
# ✅ 根追踪 + 子跨度出现在你的 Langfuse 仪表板中

这种可见性是在黑暗中调试和完全了解管道全貌之间的区别。

异步支持

Langfuse 的装饰器在异步应用程序（FastAPI 等）中无缝工作：

import asyncio
from langfuse.decorators import observe, langfuse_context
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

@observe()
async def async_retrieve(query: str, top_k: int = 5):
    await asyncio.sleep(0)  # 模拟异步数据库调用
    docs = DOCS[:top_k]
    langfuse_context.update_current_observation(
        metadata={"num_docs_retrieved": len(docs)}
    )
    return [doc.page_content for doc in docs]

@observe()
async def async_rag_pipeline(query: str, user_id: str):
    langfuse_context.update_current_trace(user_id=user_id)
    docs = await async_retrieve(query)
    response = await async_llm_call(query, docs)
    return response

8、评估和评分：了解你的应用是否真正良好

追踪告诉你发生了什么。评分告诉你发生得有多好。这是 Langfuse 将认真团队与只是在记录日志的团队区分开来的部分。

三种类型的评分：

8.1 基于规则的评分（从这里开始）

基于规则的评分是即时的、免费的，不需要 LLM 调用。将它们内联添加到你的管道中：

@observe()
def run_support_pipeline(query: str):
    langfuse_context.update_current_trace(tags=["rule-based-scores"])
    response = call_llm(query)
    
    # 评分：响应长度
    word_count = len(response.split())
    langfuse_context.score_current_trace(name="response_length", value=word_count)
    
    # 评分：模型是否拒绝？
    refused = any(phrase in response.lower() for phrase in
                  ["i cannot", "i'm unable", "i don't have access"])
    langfuse_context.score_current_trace(name="refusal", value=1 if refused else 0)
    
    # 评分：响应是否为有效 JSON？
    try:
        json.loads(response)
        langfuse_context.score_current_trace(name="valid_json", value=1)
    except Exception:
        langfuse_context.score_current_trace(name="valid_json", value=0)
    
    return response

8.2 LLM 作为裁判（用于细微质量评估）

对于有用性、语气、事实准确性或幻觉检测等，你需要一个 LLM 来评估：

def evaluate_hallucination(trace_id: str, output: str, context: str):
    """LLM 裁判：输出是否包含超出所提供上下文的幻觉？"""
    eval_prompt = f"""你是一个事实准确性评估器。
    
给定上下文和 AI 的输出，确定输出是否包含任何
上下文中不支持的事实声明（幻觉）。

上下文：{context}
AI 输出：{output}

仅以有效的 JSON 格式回复：
{{"score": 0.95, "reasoning": "...", "hallucination_detected": false}}

其中 score 1.0 = 完全基于事实，0.0 = 完全幻觉。"""

    result = eval_client.messages.create(
        model="claude-haiku-4-5-20251001",  # 用于评估的廉价模型
        max_tokens=512,
        messages=[{"role": "user", "content": eval_prompt}]
    )
    
    # 解析结果并附加评分
    lf.score(trace_id=trace_id, name="groundedness", value=data["score"])

8.3 人工标注（你的基本事实）

在 Langfuse UI 中配置标注队列（Settings → Scores → Score Configs）来定义自定义评分标准：

• 有用性 — 1 到 5 的等级
• 语气 — 分类：专业 / 中立 / 不当
• 包含 PII — 布尔值
• 客户是否满意 — 布尔值

然后创建一个标注队列，自动将随机样本（例如 5% 的生产流量、100% 质量评分 < 0.6 的追踪）路由给你的质量团队进行审核。

人工标签有两个关键目的：

1. 它们是测量其他一切的基本事实
2. 它们让你校准 LLM 裁判 — 将裁判评分与相同追踪上的人工评分进行比较以验证你的评估管道

9、提示词管理：无需部署代码即可发布提示词更改

这是 Langfuse 最被低估的功能之一。在大多数团队中，更改提示词意味着编辑代码中的字符串、打开拉取请求、等待审查——这个周期可能需要数小时或数天。Langfuse 完全打破了这种耦合。

9.1 工作原理

from langfuse import Langfuse

lf = Langfuse()

# 1. 在 Langfuse 中创建提示词（只需一次）
lf.create_prompt(
    name="customer-support-agent",
    type="text",
    prompt=(
        "你是 AcmeCorp 的有用客服智能体。\n\n"
        "客户姓名：{{customer_name}}\n"
        "订阅计划：{{subscription_plan}}\n"
        "当前日期：{{current_date}}\n\n"
        "帮助客户解决问题。要有礼貌、简洁和准确。"
    ),
    labels=["production"]
)

# 2. 在运行时获取并编译
prompt = lf.get_prompt("customer-support-agent")  # 获取生产版本
system_message = prompt.compile(                    # 填充变量
    customer_name=customer_name,
    subscription_plan=plan,
    current_date=...
)

# 3. 将生成链接到提示词版本
langfuse_context.update_current_observation(prompt=prompt)

Langfuse 缓存提示词并在后台刷新——因此每个请求都没有延迟。

9.2 在生产中对提示词进行 A/B 测试

def get_prompt_for_user(user_id: str):
    """基于 user_id 的确定性 50/50 分割。"""
    use_variant_b = hash(user_id) % 100 < 50
    if use_variant_b:
        return lf.get_prompt("support-agent-v2")   # 挑战者
    else:
        return lf.get_prompt("support-agent")       # 控制组

@observe()
def handle_query(query: str, user_id: str):
    prompt = get_prompt_for_user(user_id)
    langfuse_context.update_current_trace(
        user_id=user_id,
        metadata={"prompt_variant": prompt.name}
    )
    # ... 使用提示词 ...

在 Langfuse 中按 metadata.prompt_variant 过滤追踪以比较平均质量评分、延迟和成本。不需要统计学博士学位。

10、数据集和实验运行：在用户发现之前捕获回归

数据集是你将"我觉得它变差了"转变为"它在问答上变差了 12%，在摘要上变好了 3%"的方式。

# 1. 构建黄金数据集
lf.create_dataset(name="customer-support-golden-set", description="用于回归测试的手工策划的 QA 对")

# 2. 添加测试用例
test_cases = [
    {"input": {"question": "60 天后我能退款吗？"}, "expected": {"must_contain": "30"}},
    {"input": {"question": "如何导出我的数据？"}, "expected": {"must_contain": "Settings"}},
]
for case in test_cases:
    lf.create_dataset_item(dataset_name="customer-support-golden-set", input=case["input"])

# 3. 运行实验
for item in dataset.items:
    with item.observe(run_name="sonnet-4-6-baseline") as trace_id:
        output = support_pipeline(query=item.input["question"], model="claude-sonnet-4-6")
        score = evaluate_against_expected(output, item.expected_output)
        lf.score(trace_id=trace_id, name="meets_criteria", value=score)

在 Langfuse 中转到 Datasets > customer-support-golden-set 查看并排运行比较。

11、实战用例：构建生产客服智能体（提供代码）

让我们用一个完整、真实的示例将所有内容整合在一起。我们将为 SaaS 产品构建一个客服助手，它：

1. 检索相关的知识库文章
2. 生成有帮助的响应
3. 自动评估质量
4. 按客户计划跟踪成本

11.1 项目结构

real_project/
├── config.py          ← 客户端 + 提示词引导
├── retrieval.py       ← 步骤 1：查找相关 KB 文章
├── generation.py      ← 步骤 2：构建提示词 + 调用 Claude
├── pipeline.py        ← 编排器：连接步骤 1+2，添加评分
├── api.py             ← FastAPI 服务器：/support/ask + /support/feedback
├── requirements.txt
├── tests/
│   ├── build_dataset.py  ← 在 Langfuse 中创建黄金测试数据集（运行一次）
│   └── ci_eval.py        ← 回归门：如果质量低于阈值则失败
└── .github/
    └── workflows/
        └── eval.yml      ← GitHub Actions：在每个 PR 上运行 ci_eval.py

11.2 config.py：客户端和提示词引导

from langfuse import Langfuse
from anthropic import Anthropic

lf = Langfuse()
prod_client = Anthropic()   # 被追踪——所有生产调用都通过 @observe 装饰器
eval_client = Anthropic()   # 未被追踪——评估调用不会污染你的生产追踪

两个单独的 Anthropic() 实例，即使它们是相同的对象。这是一个约定：prod_client 调用被捕获在 Langfuse 追踪中，因为它们在 @observe 装饰的函数内调用。eval_client 调用发生在任何追踪上下文之外，因此它们永远不会出现为跨度——你的评估运行不会污染你的生产仪表板。

11.3 pipeline.py — 编排器

这是连接所有内容并拥有根追踪的主函数。

@observe(name="support_pipeline")
def handle_support_query(query, customer_id, customer_plan, session_id):
    # 1. 将客户上下文附加到根追踪
    langfuse_context.update_current_trace(
        user_id=customer_id,
        tags=[f"plan:{customer_plan}", "channel:support-widget"]
    )
    
    # 2. 检索 + 生成
    docs = retrieve_knowledge_base(query)
    response = generate_support_response(query, docs, customer_plan)
    
    # 3. 基于规则的评分（同步，零成本）
    langfuse_context.score_current_trace(name="response_length", value=len(response.split()))
    
    # 4. 异步 LLM 裁判（非阻塞）
    trace_id = langfuse_context.get_current_trace_id()
    threading.Thread(target=_run_async_eval, args=(trace_id, ...), daemon=True).start()
    
    return response

11.4 api.py — FastAPI 服务器

两个端点：

• POST /support/ask — 调用 handle_support_query 并返回响应和 trace_id
• POST /support/feedback — 接收 trace_id 和点赞/点踩

trace_id 被返回给前端——这样 UI 可以将用户反馈附加到产生此响应的确切追踪。

11.5 tests/ci_eval.py 回归门

这是在用户发现之前捕获回归的关键。它将黄金数据集中的每个项目运行通过实时管道，等待 LLM 裁判评分，并检查它们是否低于阈值：

THRESHOLD = 0.75   # 如果任何指标平均值低于此值则失败
for item in dataset.items:
    with item.observe(run_name=RUN_NAME) as trace_id:
        result = handle_support_query(query=item.input["query"], ...)

如果任何指标失败，脚本以代码 1 退出——这会使 GitHub Actions 作业失败并阻止 PR 合并。

12、运行

启动服务器：

uvicorn api:app --reload --port 8000

发送测试查询：

curl -X POST http://localhost:8000/support/ask \
  -H "Content-Type: application/json" \
  -d '{"query": "如何导出我的数据？", "customer_id": "user_42", "customer_plan": "pro"}'

运行回归套件：

python tests/ci_eval.py

原文链接: Production-Grade agentic observability: a complete Langfuse Deep Dive

汇智网翻译整理，转载请标明出处

大多数技术不会在光芒万丈中死去。它们只是不再出现在幻灯片里。

1、没人记得的那个文件夹

两年前，我帮一位客户在迁移前清理共享驱动器。在某个四层深的地方，穿过 old、old_2 和 DO_NOT_DELETE 这些常见沉积物之后，我找到了一个名为 blockchain-pilot-FINAL-v3 的目录。

里面有什么：一份 47 页的可行性研究、一份信心十足的路线图幻灯片、一张带着十一个方框的架构图，以及一份签署过的工作说明书。这个试点项目运行了大约七个月。预算在五十万美元上下。最后一个文件的修改时间是 2019 年初。

我问了一圈。现在团队里没人听说过它。一个人都没有。当初最卖力推动这个项目的两位架构师已经离开，随之带走的是关于这件事的全部集体记忆。没有事后复盘，没有经验教训总结，没有愤怒的回顾。它算不上失败，只是不再被提起，然后就不存在了。

大多数炒作实际上就是这样结束的。不是轰然崩塌，而是归于沉寂。

2、这个故事可能有四种结局

在看了近三十多年技术带着号角登場之后，我认为结局只有四种。

• 有些留下来并成长：它们以炒作起家，在与现实接触后幸存下来，最终变成普通得没人再称之为趋势的基础设施。
• 有些留下来并聚焦：宏大的承诺没有存活，但一个更窄的版本活了下来。技术不再试图成为解决一切问题的答案，而是安顿在两三个真正能体现其价值的地方。从外面看这像是失败，但实际上它是这份清单上最健康的结局。
• 有些死去：要么悄无声息，像我那个共享驱动器里的朋友；要么轰轰烈烈，伴随诉讼、截图和一个标题为"崩溃"的维基百科条目。
• 还有一些是浪潮：不是单一的生命周期，而是一系列生命周期，以大约二十年的节奏起落，每次换一个略有不同的名字。

把过去十年的流行词归入这四个桶，比争论哪些是"真的"更有用。那么，让我们走进坟场，好好读一读这些墓碑。

3、留下并成长：云计算

云计算是一个平淡的成功故事，我这么说是在高度赞美它。

还记得那些反对意见吗？数据主权、延迟、锁定效应、"我们绝不会把核心银行业务放在别人的电脑上"。其中一些担忧是合理的，少数至今仍然成立。但这个东西持续兑现着一个任何人都能用一句话理解的简单承诺：你不再购买暂时用不上的服务器。

云计算胜出，是因为价值在第一个季度就显现了，而不是等到第三年。没有人需要改变他们对软件的思考方式才能从中获益。你可以直接迁移、切换，然后看到数字变化。这是一个非常低的门槛，而这个清单上几乎没有任何其他东西跨过了它。

如今没有人再把"云"当作战略写进幻灯片。它只是计算机所在的地方。从流行词毕业成为基础设施，这就是赢的样子。

4、留下并聚焦：微服务与低代码

微服务被现实抢劫了，这对它们来说是好事。

大约在 2016 年，我坐在一个房间里，一个九人团队正计划把一个运行良好的单体应用拆成二十个服务。他们最慢的端点耗时 180 毫秒。他们的部署用时十一分钟。没有什么东西是坏的。他们真正想要的是成为那种运行微服务的团队，这跟需要微服务是两码事。

我们现在知道了诚实的版本：微服务是一种带有技术代价的组织工具。如果你有四十名工程师总是互相踩脚，它解决的是一个真实而痛苦的问题。如果你只有九个人，那你只是用分布式事务、网络分区和一笔链路追踪账单，换来一张更漂亮的架构图。炒作死了。技术留了下来，留在那些交易值得做的特定地方。

低代码和无代码经历了同样的收窄过程。当初的承诺是编程的终结、业务用户自己构建应用、积压需求的消失。实际发生的是一个扎实且真正有用的细分领域：内部工具、审批流程、表单，以及 IT 本来就不会去做的那条小型应用长尾。这不是微不足道。只是它并非 2019 年主题演讲幻灯片上的东西。

只有当你认真对待最初的营销宣传时，这两者才看起来像失望。

5、悄然死去：CORBA、CASE 工具与企业区块链

对大约四十五岁以下的人来说：CASE 工具是 1990 年代的承诺——你在建模工具里画出你的系统，工具就会生成软件。图形进，可用应用出。Upper CASE、Lower CASE、往返工程，全套都有。

它没有成功，主要是因为生成的代码难以维护，而且在实际开发大约一周后，图表就与现实脱节了。但请注意它是怎么死的。没有丑闻。供应商悄悄重新定位，这个词从招聘广告中消失，然后某一天大家又开始直接写代码了。好的想法存活在 UML 中，后来体现在从模式生成代码中，这是同一种本能的更谦逊版本。

CORBA 走了同样的路。它解决了一个真实的问题——跨语言、跨机器的远程对象——并用一个如此沉重的规范来解决它，以至于你需要专家才能让任何东西跑起来。连专家们有时也会碰壁。我永远忘不了那一刻：我们在 ORBIX 2000 文档（一个实现 CORBA 的产品）中找到了回答我们某个配置难题的章节。我们翻开那一页，却发现它是空的（除了标题）。然后有人带来了 HTTP 和 JSON，任何一个初级开发人员都能在一个周二的下午用起来，而不必阅读 300 页的规范。仪式感输给便利性，每一次都是如此。

这让我回到那个文件夹。企业区块链——非加密货币的那种——以同样安静的方式死去，而且原因在这份清单上是最好诊断的。我在 2017 年到 2020 年间看到的每一个严肃的企业区块链试点，都涉及一群互不充分信任的公司组成的联盟，同意共享一个它们都必须共同维护的数据结构。技术本身运行得很好。前提是竞争对手要在治理、激励、数据质量和预算周期方面合作。

当然。既然如此，不如顺便把它们的财年也统一了吧。

在几乎每一个案例中，一个由中立运营方维护的共享数据库都能以十分之一的成本交付同样的业务成果。最终有人在指导委员会上把这句话说了出来，试点项目就不再续约了。没有人把它写下来。这就是为什么那个文件夹还在那里。

6、轰轰烈烈地死去：元宇宙与 NFT

有些炒作得不到安静的礼遇。

NFT 做到了一件罕见的事——在交易量还在上升的时候就变成了笑柄。底层技术，即可验证的数字物品所有权记录，并不愚蠢。只是应用层最终几乎完全是穿着技术外衣的投机，当投机停止时，底下没有任何东西支撑它。

元宇宙撞上了另一块礁石：用户行为。它要求人们从根本上改变见面、工作和社交的方式，换取的大多是假设性的好处，同时还要戴上一个四十分钟就会让人恶心的设备。我恰好参加过一次虚拟研讨会。一半的参与者没有腿。我们下周就回到了视频通话，再也没有提起过它。

任何采用故事以"一旦人们习惯了"开头的技术，都背负着巨大的、通常未被定价的风险。

7、作为标签死去，借壳存活：SOA

SOA 值得拥有自己的分类，因为说它死了不公平，说它活着又有点勉强。

这个词现在带有放射性。在一屋子三十岁的人面前说"面向服务架构"，看他们脑海里浮现的是 ESB、治理委员会和 WSDL。但那些真正的想法——带契约的服务、松散耦合、组合能力而非重新构建——根本没有死。它们被重新包装成微服务和 API 优先，甩掉了笨重的中间件，继续前行。

这是最被低估的结局。有时炒作的内核存活了下来，只有它的名字入了土。当有人告诉你某个概念死了，问问他指的是哪一部分，因为往往只是词汇而已。

8、浪潮：AI

然后是 AI，它拒绝被归入任何一个单一的桶，因为它不是一次炒作。它是一股至少进退过三次的潮汐。

1980 年代的专家系统：巨大的承诺，一个真实的产业，然后是一个寒冷到研究人员不得不改换领域名称来获取资助的冬天。2000 年代的统计机器学习：更安静的登场，没有主题演讲，留下来并成长，直到成为搜索、反欺诈和推荐背后看不见的引擎。然后是深度学习，然后是 Transformer，然后是当下。

现在，我们正实时看着这场归类发生。今天构建的一些东西将毕业成为基础设施，就像拼写检查和翻译那样，彻底到十年后没人会再叫它 AI。有些会收窄成一个聚焦的、真正有价值的细分领域。还有很大一部分——那些没人要求、硬贴在产品上的"AI 赋能"功能——最终会进入一个叫 ai-pilot-FINAL-v3 的文件夹，并在 2029 年前被遗忘。

三者哪个是哪个？我有自己的看法，但任何在此声称确定的人都是在兜售什么。我能有把握说的是，这场归类将遵循它一贯遵循的五条规则。

9、炒作为什么会死

把墓碑看得够久，规律会明显到让人难堪。当以下一个或多个为真时，技术就会死去：

1. 问题不清晰。没有人能用一句话说出今天疼在哪儿。你拥有的不是一个解决方案，而是一个四处寻找问题的解决方案，从一个部门晃到另一个部门，问有没有用例可以借它一用。万物皆区块链在这栋地址住了大约四年，到处敲门。
2. 回报难以证明。好处是真的，但要到第三年才出现，分散且无法归因，而成本在第一个月就落在某个人的具体预算科目上。
3. 采用成本太高。不仅仅是许可证，还有专家、再培训、治理体系。CORBA 和经典的 ESB 就是死于这一点。
4. 技术实在太复杂。如果一个普通开发人员不能在一个下午用它构建出有用的东西，它的日子就屈指可数了，无论它有多正确。BPEL、WSDL 和语义网都走上了这条路。
5. 用户行为必须从根本上改变。这是清单上最可靠的杀手。元宇宙要求了它。CASE 工具要求开发人员停止开发。
6. 现有技术已经足够好。共享数据库已经足够好。基于 HTTP 的 REST 已经足够好。"足够好"对阵"优雅"的战绩是未尝败绩。

注意这个清单上缺少的东西：技术价值。这些技术几乎没有一样是因为不工作而死去的。CORBA 能用。CASE 工具勉强能用。企业区块链完全按规格运行。它们死去是因为周围的经济、政治和人类习惯不配合——这是架构评审极不擅长捕捉的一类失败。

10、五个问题，在你签任何东西之前

所以，这是我在允许自己相信任何东西之前现在要过的流程。五个问题，按这个顺序，一个普通人用平常的话就能回答。如果一个提案过不了这些关，它就是一个最终会进文件夹的试点。

1. 这到底是关于什么的？你能向一个不会碰它的人用两句话解释清楚吗？如果不能，它就拿不到赞助。
2. 我们实际上在解决什么问题？说出痛点。说出谁感受得到。如果答案以"未来，公司将需要……"开头，你拥有的不是问题，而是趋势。
3. 如果我们不做会怎样？技术领域最有用的一个问题。如果诚实的答案是"暂时没什么大不了"，那没问题——但你现在知道你买的是什么了。
4. 对必须使用它的人来说有什么好处？不是 CIO。是维护它的开发人员，点击它的职员，必须加入联盟的合作伙伴。如果好处落在付出代价的人以外的人身上，它就会死。
5. 这项技术可用且负担得起吗？今天，用你实际能招到的人，以能撑过下一个预算周期的价格。

这些都不会让你成为远见者。它让你成为房间里问那个无聊问题的人——一个光彩少得多、却有用得多的角色。我坐过那张桌子的两边，我也曾比应该的更卖力地推动过这清单上的某样东西。那个区块链文件夹不是我的，但我有自己版本的东西，而它们同样也是归于沉寂，而不是轰然爆发。

这才是值得好好体会的部分。你极少有机会享受被证明是错的满足感。试点不会爆炸，供应商不会道歉，不会有邮件宣布战略取消。它只是逐渐从议程上消失，拥护者转去新的岗位，整个事情沉淀到某处的一个目录里，带着一个满怀希望的文件名和一个永远不再变化的修改日期。

六年后，会有某个人在迁移前清理时发现它，然后问一圈，没人会记得。

现在就问那五个问题吧。这比成为那个文件夹便宜。

原文链接: The Hype Graveyard Nobody Visits

汇智网翻译整理，转载请标明出处

每一位我尊敬的资深后端工程师，最终都会用平静的、带着如释重负的语气说出同一句话：放进 Postgres 就行了。

这句话过去听起来像是偷懒。现在它听起来像是用惨痛代价换来的智慧——通过那些没人想解释的故障，和没人想说明的账单。

1、我们无意间建起的动物园

我曾共事过的一个团队，搭建了一套在白板上看起来很酷、运维起来却苦不堪言的技术栈。

Postgres 存核心数据。MongoDB 存那些没人愿意好好建模的灵活文档。Redis 负责缓存。Elasticsearch 负责搜索。

AI 功能上线后，又引入了一个独立的向量数据库处理嵌入。

五个系统，五套凭据，五种不同的故障模式，还有一个精疲力竭的值班工程师，努力回忆哪个仪表盘对应哪次故障。

我们把这称为"为工作选择合适的工具"。回过头来看，那是五把穿着可信伪装、其实用错了的工具。

压垮骆驼的最后一根稻草，是一次例行部署中向量数据库与主数据库发生数据漂移，直到有客户发现才有人注意到。

这就是那种足以改变整个团队对架构思考方式的错误。

2、真正改变的是什么

Postgres 并没有变得更响亮或更时髦。它变得更可扩展了，开源社区开始把这些扩展当作真正的基础设施来对待，而不是附属项目。

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id serial PRIMARY KEY,
  content text,
  embedding vector(1536)
);
SELECT content
FROM docs
ORDER BY embedding <-> '[0.12, 0.98, 0.44]'
LIMIT 5;

就这一条查询，替最近与我合作的一个团队省掉了一整个供应商的合作关系。

全文搜索是内置的。通过 PostGIS，地理空间查询已经稳定生产十多年。

时序数据可以通过一个扩展自然地适配，它平时表现得像普通表，直到你需要它不再是普通表。

3、那张没人再画的架构图

旧的技术栈，大多数人大都这样在白板上画了好多年。

[ App Server ]
     |
     |---> [ Postgres ]      core data
     |---> [ MongoDB  ]      flexible docs
     |---> [ Redis    ]      cache
     |---> [ Elastic  ]      search
     |---> [ Vector DB ]     embeddings

现在大多数团队实际交付的技术栈是这个。

[ App Server ]
     |
     |---> [ Postgres ]------ core data
                |------------ full text search
                |------------ vector search
                |------------ time series
                |------------ geospatial
                |------------ cache

一个盒子。一套备份策略。一个人就能把整个数据层装进脑子里。

4、真实的成本差异

在我自己于一台普通云实例上做的测试中，pgvector 用一点点原始速度，换来了运维成本和复杂度的显著下降。

专用的向量服务在重负载下响应稍快一些。

而 Postgres 的响应速度，对一个普通团队交付的几乎所有产品来说都已经足够快了——而且跑在本来就要付费的硬件上。

几毫秒的差异，对低头刷手机的人类来说是看不见的。而一笔单独的供应商账单，年复一年每月都要付，任何一个不得不去捍卫预算的人都看得见。

5、Postgres 仍然输在哪里

在这里，诚实比炒作更重要。如果一家公司在数十亿向量的规模上运行真正的 Web 级搜索，并且有严格的亚毫秒级保证，那么专门为此目的构建的专用引擎很可能仍然会胜出。

如果写入吞吐量需要跨多个区域且几乎没有协调延迟，那么 Cassandra 或 DynamoDB 之类的东西有其存在的价值。

Postgres 不是魔法，任何告诉你它能在没有权衡的情况下取代所有专用系统的人，很可能从未在真实压力下运维过这些系统。

它取代的，是大多数团队在真正需要之前很久就添加进来的那些不必要的复杂性。

6、为什么 Linux 是对比的正确对象

Linux 从来不是因为它是现有选项中最快或最漂亮而获胜。它获胜是因为它无处不在、不把任何人锁定，还因为成千上万陌生人在我们睡觉时悄悄修复着它的 bug。

Postgres 正走在同一条路上。它不再是令人兴奋的新选择。它是默认选择——你首先伸手去够的那个，只有当你有一个具体的、可衡量的、痛苦的理由时才会替换它。

7、这对你意味着什么

深入学习 Postgres——它的索引行为、查询规划器、扩展生态——开始让人感觉就像多年前深入学习 Linux 一样。

它从来不是花哨的技能。它悄然变成了你周围每个人都希望你掌握的技能。

原文链接: PostgreSQL Is Becoming The Linux Of Modern Backend Engineering

汇智网翻译整理，转载请标明出处

出卖时间很难，但随处可见。几乎人人都在做。构建资产也很难，却很稀缺。十多年前，我选择了自己的那条更难的路。我从未回头。我一直在做建设。用时间换钱需要你一辈子都亲力亲为。"如果你找不到一种在睡觉时也能赚钱的方法，你就会一直工作到死，"沃伦·巴菲特说。我读到这句话，并且认真对待了它。我们从小被灌输一种危险的逻辑。我们被教导时间等于金钱。这听起来合理。但如果我工作八小时，我就得到八小时的报酬。这似乎很公平。然而，它有一个生理极限。你无法扩展你的时间。你无法把一天拉长超过二十四小时。没有人能做到。出卖时间换钱，字面意思是你能留下果实的一部分，但你是在拿整棵树做交易。

在任何知识经济中，几乎人人都在这样做。你在出租自己的人生。在这个体系里，你的收入是有上限的。除非你工作更多，否则你无法增长，而工作更多恰恰摧毁了你正努力构建的生活。这是一场为生存而做的交易。焦虑在于，你正在用有限的资源换取有限的回报。

这是一场必输的游戏。

你可以更努力、更长时间地工作，甚至更聪明地工作，但仍然会撞上同一堵墙。一天只有一个长度，你卖出的每一个小时都是回不来的一个小时。你的一生可能只有八万个工作小时。大多数人会把它们每一个都卖掉。大多数人相信他们可以通过努力工作走向财富。加班。升职。爬上阶梯。然后一切都会好起来。只要你不拥有那棵树，你就会被困在摘果子的循环里。**只要你的投入与产出紧密挂钩，你就会一直出卖时间换取收入。**在几乎任何一份拿薪水的职业里，即使是律师或医生这样高薪的工作，你仍然是在投入时间。每工作一小时你就得到一小时的钱。这意味着，当你睡觉时，你不在赚钱。当你退休时，你不在赚钱。当你在度假时，你不在赚钱。更重要的是，你无法非线性地赚钱。一小时的工作等于一小时的报酬。

这是 1:1 的比率。

没有乘法，没有放大，没有杠杆。

当然，除非你拥有那棵树。麻烦还不止这些。**事情更糟了。你是可替代的。**连续创业者和投资人 Naval 说过，如果你在出租你的时间，"你基本上是可有可无的，因为你在承担一个固定的角色。大多数固定角色都是可以被教授的。如果它们能像在学校里那样被教授，那么最终你将要和一个拥有更新知识、受过训练、正准备进来取代你的人竞争。"如果这个系统能训练你做你的工作，它就能训练别人来取代你。而且这还不止于其他人。"你更有可能从事一份最终会被机器人取代的工作。"你的工作保障取决于取代你的难度。而如果你在拿时间换钱，你就在做可以被教授的工作。

这意味着你是可替代的。

前 10% 的人不靠这种逻辑生活。

他们拥有系统。看看那些数字。最顶尖的赚钱者不是靠工作更多小时到达那里的。他们知道这对他们的一生都不会奏效。他们找到了一条路——通过拥有那些在他们睡觉时也在运转的东西。Naval 说，"财富是拥有在你睡觉时也在赚钱的资产。""财富是工厂，是机器人，在源源不断地生产东西。"而金钱，只是"我们转移时间和财富的方式。"金钱是社会对你已完成工作打下的欠条。

当所有人都在拿时间换金钱时，富人正在投资那些能构建财富的系统。这个区别就是一切。金钱是线性的。你通过交易时间得到它。财富是指数级的。你什么都不做，它也在增长。工作已经在前端完成了。系统未来可能不再需要你的亲身在场。托马斯·皮凯蒂的研究证明了这一点。他说明了这为什么重要。当资本回报率（r）超过经济增长率（g）时，财富的集中速度会快于收入的增长。这一动态自 1980 年以来愈发明显。

差距每年都在扩大。

出路是构建那些在你休息时也能运转的东西。或者投资那些不需要你亲身在场的系统。

有两种劳动。

出租的和拥有的。第一种是按小时计费的律师、按项目收费的自由职业者，或者用固定时间块换取固定工资的员工。拥有的劳动，是一次写代码、卖掉一百万次的软件工程师。是作品完成后仍在持续赚钱的作家。是睡觉时课程仍在售卖的教师。Naval 称之为"代码和媒体"杠杆，它们的扩展不需要你的许可。他谈到的其他用来逃离时间陷阱的杠杆形式是劳动力和资本。劳动力是最古老的。但它需要许可；必须有人同意为你工作。另一种，资本，是钱在为你工作，它同样需要许可——必须有人把钱给你。这意味着你最好的选择是代码和媒体。它们是新的"无许可杠杆"，Naval 说。

代码和媒体的复制边际成本为零。你构建一次，它想运行多久就运行多久。你出版一本书、一篇解决某个问题的长文；你以多种方式收获回报，这些回报以对你有利的方式复利。**你的投入保持不变。你的产出无限扩展。**Naval 论证道："产品杠杆是数字时代创造财富的方式。"他说："没有人会比你自己更看重你。"将你的专业能力产品化，来停止出租你的全部时间。斯多葛哲学家塞内加警告说，大多数人对真金白银很节俭，却对那个吝啬才是美德的东西——时间——挥霍无度。直接出卖时间，一小时换一小时，是你一生能做出的最糟糕交易。

但拥有不等于辞职。

那不是切实可行的建议。

你不必成为系统的创始人才能从中受益。所有权是一个光谱,它从人们想象中小得多的起点开始。它可以意味着一位顾问或专家把自己的流程打包成一门课程，让一百个人不用开一百次会议就能学会。它也可以意味着一位协商获得股权的员工。大多数人只追求更高的薪水。当然，你可以用那张大支票去别处投资。你也可以把自己的上升空间与公司的增长挂钩，而不是与自己的工时挂钩。一位作家，就像任何在某个平台上建立受众的人一样，可以现在投入无报酬的时间写文章，让信任、邮件列表或粉丝群在未来复利。这些都不需要你明天辞职。它只是把你的一部分时间从"小时换美元"的交易中抽出来，投入那些在你不再碰它之后仍在持续回报的事物。

那些会复利的事物。

你开始以十年为单位思考。投资你的长期声誉。你的知识变成一项资产。你的人际关系也是。这些东西会复利。它们通过乘法增长。本杰明·格雷厄姆写道："投资者首要的问题——甚至是他最大的敌人——很可能就是他自己。"这同样适用于时间。我们之所以是自己最大的敌人，是因为我们没有耐心。我们为了一片面包卖掉种子。我们为了今天的舒适交易掉未来。如果你停止出售你的一部分时间，你就停止了对眼前压力的条件反射。

你开始构建。

你构建一整套作品。你构建具体而稀有的技能。你构建一个信任你的人际网络。这些都不是以时间为界限的。它们以关系为界限、以知识为界限。

它们成为你专属的资产。

Naval 对此的术语是"特定知识"。那些你在学校里学不到的技能，因为如果它能被教授，它就能被取代。而构建财富的那些东西，是无法教授的。特定知识是通过好奇心和真正的兴趣构建起来的。你的资历与它毫无关系。它在你眼里像玩耍，在别人眼里像工作。这就是为什么摆脱出卖时间的转变起初很慢。你不仅在构建一个产品或一项资产；你在构建只有你才拥有的、技能与知识的独特组合。而这需要年复一年地做那些吸引你的事。

在职业生涯的任何阶段，你都有两个选择。

你可以继续拿时间换金钱。并指望下一次晋升会让生活更好。它很可能不会。你总是有上限。你的收入总是与你的工作时间挂钩。你总是可替代的。然后某一天你醒来，发现生活一片空虚。或者，你可以开始构建那些在你睡觉时也能赚钱的资产。开始拥有某样东西的股权。一门生意、一项知识产权、一份会继续为你交付价值的数字资产。即使你必须做一份普通的工作，也要找时间开始投资自己。把你的知识包装成可以反复销售的产品。写作。录制。构建。"学会销售。学会构建。如果你两者都能做到，你将势不可挡，"Naval 这样建议。你不可能仅靠出租或出售时间，在退休时就变得富有。数学说不通。你的小时数是有限的。包括你的生命。

前 10% 的人不靠一辈子交易时间的职业逻辑生活。他们通过投资玩长期游戏。他们拥有股权。他们使用杠杆。你也可以。你的时间是你拥有的一切。

帮自己一个忙。把其中一部分用来打造你自己的产品。大多数人都在等待一个允许他们停止拿时间换钱的特定时刻。一次晋升，一个信号。但那永远不会来。你总有另一个借口。你需要的只是每天或每周抽出一个小时，重新定向。然后再一个小时。选择你自己的节奏。你做出的这笔交易，起初看起来像是更少的睡眠、更少的安全感、更少的即时成果。但它是唯一会复利的交易。在你特定的道路上的成长，将是你与自己的时间的一种不同关系。在这种关系里，有些小时不再被出售，而是开始被投资。

原文链接: This Logic Is a Career Trap. The Top 10% Don't Live by It

汇智网翻译整理，转载请标明出处

在日新月异的技术世界里，某些技能始终主导着高薪职位的讨论：人工智能、机器学习、云计算和网络安全。虽然这些领域无疑提供丰厚的机遇，但深入市场后会发现一个迷人的事实：一些最高薪的技术技能往往被忽视，它们存在于需要专业技能并提供可观经济回报的小众领域。本文探讨这些低调的技能，它们可能在 2026 年及以后显著提升你的职业和收入潜力。

1. Rust：系统编程的现代黄金标准

Rust 迅速赢得高性能且内存安全语言的美誉，成为系统编程、基础设施开发乃至区块链技术的宠儿。是什么让 Rust 开发者能够拿到如此高的薪水——美国高级职位年薪通常在 18.5 万到 23 万美元之间？答案在于它陡峭的学习曲线，尤其是其独特的所有权和借用检查器系统。这种复杂性造成了经验丰富的 Rust 开发者的稀缺，推高了需求和薪酬。公司愿意为能够编写健壮、高效、安全代码的工程师支付溢价，尤其是在高频交易（HFT）和内存安全至关重要的关键基础设施等高风险环境中。NSA 和 CISA 等政府机构倡导内存安全语言的强制要求，进一步巩固了 Rust 作为关键技能的地位。

2. Zig：性能关键型应用中的新兴颠覆者

在 Rust 确立地位的同时，Zig 是一个更年轻、正在悄然掀起波澜的竞争者。它常被描述为 C++ 的更简单替代品，采用手动内存管理，正逐渐在性能关键型应用中流行。由于其采用尚处于初期阶段，具体的薪资数据仍在涌现，但早期迹象表明薪酬可能非常高，在 HFT 或高级系统开发等高度专业化的领域，年薪可能在 20 万到 60 万美元以上。它专注于显式控制和极低开销，吸引着构建高性能运行时和操作系统的开发者，使其成为一项目前鲜有人讨论、却具有重大未来价值的技能。

3. Agentic AI 与 AI 编排：超越提示工程

AI 领域正迅速从基础的提示工程转向自主 AI 智能体和复杂编排系统的开发。这涉及设计、构建和管理能够独立推理、规划并执行复杂任务的 AI 系统。Agentic AI 工程和 AI 自动化相关岗位的薪资通常在 14 万到 19 万美元以上，有些岗位远高于此。这些专业人士精通 N8N 和 LangGraph 等框架，能够创建自动化复杂流程的智能化工作流。随着企业寻求利用 AI 进行更复杂的运营，对这些专业 AI 编排技能的需求将持续飙升。

4. Elixir 与 Erlang：并发之王

Elixir 及其基础语言 Erlang 常常被更主流的语言所掩盖，但它们却是构建高并发、容错和分布式系统的强大工具。Discord、WhatsApp 和 PagerDuty 等公司依赖这些语言来处理海量用户负载并确保服务不中断。精通 Elixir 和 Erlang 的开发者的薪资预计在 11 万到 18 万美元以上。它们的小众吸引力源于 Erlang 虚拟机（BEAM），它为处理并发进程提供了无与伦比的能力，使其成为需要极致可靠性和可扩展性应用的宝贵资产。

5. COBOL 与遗留系统：金融领域的无名英雄

这似乎有违直觉，但对 COBOL 等遗留编程语言的专业知识可以带来异常高薪的机会。全球很大一部分金融基础设施，包括银行系统和政府机构，仍然运行在基于 COBOL 的大型机上。随着许多经验丰富的 COBOL 开发者临近退休，一个关键的人才缺口已经出现。这种稀缺意味着 COBOL 专家和顾问的年薪可以达到 15 万美元以上，一些顾问的时薪超过 100 美元。虽然不够光鲜，但维护和现代化改造这些关键系统至关重要，使得 COBOL 成为一项出人意料地赚钱且常被忽视的技能。

6. Mojo：AI 性能的未来

Mojo 是一种新编程语言，旨在为 AI 开发结合 Python 的易用性与 C++ 的性能。它仍处于早期阶段，旨在解决基于 Python 的 AI 应用中常见的性能瓶颈。随着 Mojo 走向成熟，由于其开发者能够优化 AI 模型和基础设施，预计他们将获得高薪。它在快速原型开发与高性能部署之间架起桥梁的潜力，使其成为值得关注的重要未来价值技能。

7. 形式化验证 / TLA+：确保绝对正确性

形式化验证涉及使用数学方法证明软件和硬件系统的正确性。TLA+（动作时序逻辑）是用于此目的的一种规约语言。这是一项极度专业且稀有的技能，主要用于错误可能造成灾难性后果的行业，如航空航天、医疗器械和高可靠性云基础设施（例如 AWS 等公司）。由于工作性质的关键性和技能的稀缺性，具备形式化验证和 TLA+ 专业知识的专家可以获得非常高的薪水。

8. WebAssembly专家：将原生性能带到 Web

WebAssembly（Wasm）允许开发者直接在 Web 浏览器中运行用 C、C++ 和 Rust 等语言编写的高性能代码。这项技术正在彻底改变 Web 开发，为复杂的 Web 应用带来桌面级性能。随着 Wasm 采用率的增长，能够利用其能力构建快速、高效、安全的 Web 体验的专家正变得炙手可热。随着更多公司寻求以原生级性能增强其 Web 应用，Wasm 专家的薪资预计在 15 万到 20 万美元之间。

结论：把目光投向炒作之外

虽然主流技术技能总会提供机会，但真正最大化你的收入潜力往往意味着把目光投向显而易见的事物之外。上述技能虽然小众，但代表着需求旺盛、供应有限的领域，因此报酬显著更高。投入这些专业领域需要专注和迎战复杂挑战的意愿，但财务和职业回报可能是可观的。随着科技版图持续多元化，这些小众技能提供了一条通往职业成长和财务成功的清晰路径。通过保持领先并掌握这些"隐藏宝石"，你可以在竞争激烈的市场中把自己定位为高价值专家。

原文链接: The Highest Paying Tech Skills Nobody Is Talking About

汇智网翻译整理，转载请标明出处

曾经有一段时间，构建一个RAG系统感觉简单得令人怀疑。

分块文档。 生成嵌入。 把它们放进向量数据库。 设置 top_k = 5。 调用LLM。

这种方式似乎在一段时间内有效。然后你将系统投入真实环境。

查询变得混乱。文档不一致。有些问题需要来自多个来源的信息。用户会问原始评估集里没有的问题。突然，一个在基准测试中表现优秀的配置开始产生感觉奇怪不可靠的答案。

我在为企业级RAG工作流进行检索调优时，就遇到了这类问题。

我们增加了检索深度，因为系统遗漏了相关信息。检索指标提高了。召回率上升。纸面上看，检索器看起来更好了。

但答案变得更差了。

更多的上下文并没有产生更好的答案。在某些情况下，效果恰恰相反。模型接收到了与冗余段落、松散相关内容以及偶尔相互冲突的证据混合在一起的相关信息。

就在那一刻，我不再把RAG评估简单地看作：

"我们是否检索到了正确的文档？"

而是开始这样思考：

"我能证明RAG管道的每个阶段都在完成它的任务吗？"

这种转变听起来微妙。其实不是。

因为一旦你开始调试生产级RAG系统，你很快就会发现检索质量、排序质量、答案质量、真实性、延迟和成本都是同一个工程问题的不同维度。

这就引出了我经常听到的一个问题：

如何系统地调整chunk size和top-k？

我今天的答案与几年前完全不同。

我不再从以下方面开始：

"使用512个token的chunk和top-k 5。"

我从以下方面开始：

将其视为离线优化问题，定义真实标签，衡量正确的指标，理解权衡，在未见数据上验证，然后验证改进在生产中是否有效。

在这篇文章中，我将介绍我在评估RAG系统时发现最有用的六个指标：

Recall@K、nDCG、MRR、真实性、延迟和成本。

但更重要的是，我将解释为什么每个指标存在，它能暴露什么类型的故障，以及当你试图将RAG原型转化为生产系统时，这些指标如何协同工作。

1、我首先检查的是检索

当答案开始变差时，我的第一反应是回到RAG管道的起点。

在质疑提示之前。在更改LLM之前。在添加另一个代理之前。

我想回答一个非常基本的问题：

系统是否真的找到了它需要的信息？

因为在任何RAG系统中都有一个基本限制：模型无法使用从未被检索到的证据。

这让我看到了调试检索时查看的第一个指标：

1.1 Recall@K — 我们是否检索到了所需的证据？

Recall@K回答了一个看似简单的问题：

在所有与查询实际相关的信息中，我们的检索器设法将多少带入了前K个结果中？

这就是调查开始变得有趣的地方。例如，想象一个ITSM助手收到这个问题：

"支付服务在数据库故障转移后失败了。我应该遵循什么恢复程序？"

假设我们的真实标签显示有五个信息片段与回答该问题相关。检索器返回了其前五个结果，但只有这五个相关证据中的四个出现在检索集合中。

那么：

Recall@5 = 4/5 = 0.80

所以我们的检索系统有80%的Recall@5。这个数字立即告诉我一些重要的信息。

系统不一定是因LLM不好而失败，而是可能因为它所需的五分之一的证据从未到达生成阶段，这给了我们第一条调试规则：

在尝试让LLM回答得更好之前，确保你给了它正确的证据来回答。

这也是我不将 top_k = 5 视为通用最佳实践的原因。

如果将K从5增加到10，Recall@K从0.80提高到0.94，我就学到了一些有用的东西：检索器可能有相关证据，但我当前的检索深度太浅了。

但这带来了第二个问题。

当那些额外的六个结果大多是噪声时会发生什么？

这正是我接下来陷入的兔子洞，也是nDCG和排序质量变得重要的地方。

1.2 nDCG：我们是否将最有用的证据排在了前面？

找到相关信息只是问题的一部分。我们还需要知道这些信息在排序中的位置。

考虑同一查询的两个检索结果。

在第一个系统中，高度相关的运行手册出现在位置一，然后是另一个相关程序，接着是几个不太有用的块。

在第二个系统中，相同的运行手册出现在位置八，之前是一系列松散相关的文档。

两个系统可能都有可接受的召回率。但它们并不等价。

这就是归一化折损累计增益（nDCG）变得有用的地方。与简单的二元相关性指标不同，nDCG可以考虑分级相关性，并奖励将高度相关的结果放在排序顶部附近的系统。Järvelin和Kekäläinen的原始折损增益工作正是围绕这一思想设计的：相关性很重要，但位置也很重要。

对于RAG，一旦我们引入重排序，这变得尤为重要。

如果我检索了20个候选者，只将最好的五个传递给LLM，那么这20个候选者的排序突然变得非常重要。

一个具有出色召回率但排序较差的系统可能在候选池中的某个地方包含正确的证据，但仍然无法将其传递到最终上下文中。

这给了我一个有用的区别：

Recall告诉我证据是否被找到。nDCG告诉我证据是否被智能地排序。

1.3 MRR：我们多快找到了第一个有用的结果？

还有一些情况，我不需要每个相关文档。我需要快速获得一个强有力的结果。

考虑查询：

"什么命令可以重启服务X？"

如果正确的运行手册排名第一，那与在位置十找到同一运行手册有很大不同。

平均倒数排名（MRR通过关注第一个相关结果的位置来捕捉这一点。

对于单个查询：

RR = 1 / 第一个相关结果的排名

位置一的相关结果给出RR为1.0。在位置二，它变为0.5。在位置五，它变为0.2。

MRR在评估集上对此行为取平均值。

我不将MRR作为检索质量的唯一定义。但当我关心检索器多快浮现有用答案时，它非常有用。

所以我现在有三个不同的问题：

Recall@K：我们是否检索到了证据？

nDCG：我们是否很好地排序了证据？

MRR：我们多快浮现出第一个有用的结果？

然后出现了使整个问题更有趣的生产问题。

更多的检索上下文正在使答案变差

我们对RAG的直觉通常是假设更多上下文更安全。

如果五个块不够，检索十个。如果十个不够，检索二十个。但语言模型的行为不一定如此。有一个点，额外的上下文停止有用并开始变成噪声。

你可以检索一个高度相关的运行手册，但然后用十四个松散相关的文档、一个过时的程序和两个相互冲突的指令来包围它。

检索器可能得分更好。答案可能仍然变得更差。

这也是候选K和最终K之间的区别变得重要的地方。

生产架构可能如下所示：

第一阶段故意广泛检索，因为我想要高召回率。重排序器然后缩小候选集，LLM只接收最高价值的上下文。

这与简单地检索五个块并直接传递给模型有着根本不同的架构。它引出了另一个不可忽视的指标。

1.4 真实性：模型是否保持在检索证据的基础上？

假设检索器完美执行，正确的运行手册被检索到。重排序器将其放在顶部，上下文相关，LLM仍然添加了一个在检索材料中不存在的声明。

例如，也许运行手册说：

"在验证数据库连接后重启服务。"

生成的答案说：

"在验证数据库连接并清除Redis缓存后重启服务。"

如果在检索上下文中没有关于Redis的证据，那么额外的声明就是不受支持的。检索系统完成了它的工作，而生成系统引入了一个不受支持的声明。

这就是真实性变得重要的地方。我将真实性视为一个简单的问题：

答案中的声明是否得到了提供给模型的证据的支持？

诸如RAGAS和ARES之类的框架明确分离了检索/上下文质量、真实性和答案相关性等维度，而不是将RAG响应视为一个不可区分的分数。这很重要，因为一个系统可以检索到正确的信息，但仍然生成一个没有正确基于证据的答案。

这里还有另一个在企业系统中很重要的微妙区别。

真实性与正确性不同。

假设知识库包含一个过时的密码策略，说密码每60天过期。

模型检索该文档并回答：

"密码每60天过期。"

答案可能完全忠实于检索到的来源，但它仍然可能是错误的。

所以我通常区分：

真实性：答案是否得到了检索上下文的支持？

正确性：答案是否根据预期的真实来源实际正确？

在评估具有不断变化的知识库的生产系统时，这种区别变得极为重要。

1.5 延迟：用户实际能负担得起多少质量？

一旦检索系统开始在离线状态下良好运行，另一个问题就出现了。质量只有在系统能够在产品约束内交付时才有用。

想象两种配置：

1. 配置 答案准确率 检索延迟A 91% 120ms B 93% 650ms

如果我只关心答案准确率，配置B看起来更好。

但B是否实际更好取决于应用程序。

对于具有严格响应时间期望的交互式助手，额外的延迟可能是不可接受的，而且检索延迟只是总响应时间的一部分。

生产请求可能涉及：

所以当我评估延迟时，我想了解各个阶段和端到端响应，我还关心分布而不仅仅是平均值。

平均延迟为400ms的系统仍然可能有P95为1.8秒。

这与P50、P95和P99保持一致较低的系统有着非常不同的用户体验。

这就是为什么延迟从一开始就属于RAG评估框架，而不是在架构已经最终确定后才被视为运营指标。

1.6 成本：当我们将其扩展到数百万查询时会发生什么？

最后一个指标是原型转变为产品时不可避免的那个。

成本。

增加top-k不仅影响检索。

它可以增加：

• 重排序器处理的候选数量；
• 最终上下文的大小；
• LLM输入token；
• 延迟；
• 基础设施消耗。

假设平均块包含600个token。

当：

最终K = 5

我们注入大约：

5 × 600 = 3,000

个检索到的token到提示中。

增加到：

最终K = 15

我们大约有：

15 × 600 = 9,000

个检索到的内容token。

这是三倍的检索上下文，在小规模时，这可能不可见，但在数百万请求时，它变成了一个产品决策。这就是为什么我不再认为 top_k 只是一个检索参数。

Top-k同时影响质量、延迟和经济性。

2、真正的优化问题

到这时，原始的面试问题开始看起来非常不同。

"如何调整chunk size和top-k？"实际上不是在问两个数字。

它是在问你如何设计实验。

我可能会从一个包含200个代表性查询的评估数据集开始，涵盖多个类别：

• 故障排除；
• 程序性查询；
• 事件和RCA问题；
• 策略问题；
• 模糊问题；
• 多跳问题；
• 边缘情况。
• 领域专家将建立相关性判断。

然后我可能会测试：

Chunk sizes: 256, 512, 1024, 2048
Overlap: 64, 128, 256
候选K: 5, 10, 20

这给出：

4 × 3 × 3 = 36

种配置。

对于每种配置，我不会只衡量一个分数。

我会收集：

Recall@K
nDCG@K
MRR
答案正确性
真实性
延迟
成本

然后我会寻找质量/延迟/成本权衡，而不是自动选择具有最高召回率或F1的配置。

3、RAG实验可能产生非常违反直觉的结果

想象我们得到以下结果：

如果我只看召回率，我会选择C。但C产生了最差的答案。

为什么？

因为额外的检索信息显然没有帮助生成层。事实上，它可能在伤害它。

配置B有趣得多，因为它没有最高的召回率。

但它有最高的nDCG、最高的答案准确率、最高的真实性，以及相对较小的延迟和成本惩罚。

这正是我会进一步研究的那种配置，这也是为什么我不喜欢这句话：

"最佳RAG配置是具有最高检索分数的那个。"

没有这样的通用规则。最佳配置是为目标应用程序优化正确目标的那个。

4、RAG系统失败时我寻找什么

这是我目前使用的调试框架。

如果：

Recall@K较差

我调查分块、嵌入、索引、元数据过滤器、查询构建和检索策略。

如果：

Recall好但nDCG差

我调查排序和重排序。

如果：

检索指标好但答案准确率差

我调查上下文构建、上下文排序、提示设计和生成。

如果：

答案看起来正确但不受支持

我调查真实性和基础性。

如果：

质量好但延迟不可接受

我分析管道的每个阶段。

如果：

质量好但成本太高

我调查候选K、最终K、chunk size、上下文压缩、缓存、模型选择和提示/token效率。

这将RAG调试转变为更系统化的东西。

5、我在生产中实际想要的评估循环

最终状态不是运行一次的基准。我想要一个持续的评估循环：

这特别重要，因为生产查询很少表现得完全像精心策划的基准查询。用户表达方式不同，文档变化，策略变化，新服务被引入，边缘情况出现，因此评估集必须随产品一起演变。

生产成为新评估案例的来源。

6、在成熟的RAG系统中我会衡量什么

到这时，我的RAG记分卡通常看起来像这样：

没有单一指标能讲述整个故事。这是我从那次生产调试中学到的教训。

7、我现在在调整任何RAG系统之前会问的问题

当有人问：

"我们应该使用什么chunk size和top-k？"

我的第一个回答不是一个数字。而是一个问题：

"我们在优化什么，我们的评估数据集是什么样的，检索错误的成本是什么？"

一旦这些问题有了答案，配置就变成了实验结果。

也许是：

512 tokens
128 overlap
候选K = 20
最终K = 5

也许是：

1024 tokens
64 overlap
候选K = 10
最终K = 4

也许语义分块优于两者，或者重排序器使最终K的选择比初始候选K重要得多。

没有我不经测量就信任的通用值，对我来说，这是构建和调试RAG系统的更大教训：

RAG系统不是因为检索更多而好。不是因为检索更快而好。也不是因为LLM产生令人信服的答案而好。

当它始终检索正确的证据，适当地排序它，给模型适量的上下文，生成正确且基于证据的答案，并且在真实产品的延迟和成本约束内完成所有这些时，它才是好的。

这就是构建RAG管道和工程化生产RAG系统之间的区别。

8、结束语：停止凭猜测调整RAG

我与RAG系统合作得越多，我就越确信没有神奇的chunk size，没有通用的top-k，也没有单一指标能告诉你RAG系统是否生产就绪。

一个提高Recall@K的配置仍然可能损害答案质量。一个具有出色检索的系统仍然可能生成不受支持的声明。一个高度准确的系统如果在规模上延迟或成本不可接受，仍然可能失败。

真正的工程挑战是在检索覆盖范围、排序质量、基于证据的生成、延迟和成本之间找到与你实际服务的工作负载的正确平衡。

这就是为什么我更喜欢这样的评估循环：

构建有代表性的真实标签 → 基准检索 → 评估排序 → 衡量端到端答案质量 → 验证延迟和成本 → 在未见数据上测试 → 监控生产 → 将故障反馈回评估集。

到那时，chunk_size=512 或 top_k=5 就不再是一个猜测。

它是有证据支持的结果。

对我来说，这就是构建RAG管道和工程化生产RAG系统之间的区别。

原文链接：6 RAG Evaluation Metrics I Learned to Respect After Debugging a Production RAG System

汇智网翻译整理，转载请标明出处

我们最近通过两条200Gb/s以太网链路，使用专有的NVMe-over-Ethernet（NVMe-oE）技术，实现了1170万次4KiB随机读取IOPS。AI应用能否真正有效地利用如此多的小I/O性能？

近似最近邻（ANN）向量搜索是许多RAG管道、语义搜索服务和推荐系统背后的检索层，是一个自然的测试场景。大型图索引可以驻留在存储上，并在搜索遍历图时生成高度随机、依赖于数据的读取。我们没有运行另一个合成基准测试，而是使用BigANN/SIFT数据集和Recall@10验证，用真实的ANN引擎测试了NVMe-oE。

对于单个服务器，本地NVMe仍然是最简单的选项。然而，在更大的AI部署中，将每个向量索引保留在执行搜索的同一服务器上会产生扩展问题。添加、替换或重新分配GPU服务器可能还需要复制大型索引，而一台服务器上未使用的存储无法轻松为另一台服务器上的工作负载提供服务。NVMe-oF和我们精简的NVMe-oE方法将计算与存储分离：多个租户、RAG服务和ANN工作者可以访问共享的向量索引池，同时计算和存储容量独立扩展。这实现了集中的数据放置、更高的存储利用率和更快的检索工作负载重新分配，而无需放弃熟悉的块设备模型。

1、从CPU搜索到GPU辅助搜索

我们在相同的双链路NVMe-oE平台上进行了一系列Recall验证的ANN基准测试，使用BigANN/SIFT查询和top-10搜索。每个引擎都独立调整以最大化Recall验证的存储吞吐量，因此结果展示了每个CPU或GPU辅助架构可以生成多少有用的I/O，而不是严格的算法到算法的加速比较。

QPS和IOPS不会按相同比例上升，因为IOPS ≈ QPS × 每次查询的读取次数。这些测试选择了通过Recall要求的最高IOPS配置；它们没有对每次查询施加固定的存储预算。DiskANN选择的高负载配置每次查询执行约353次读取，而GustANN需要约101次。因此，9.7倍的QPS增长结合了2.77倍更高的IOPS和约3.49倍更少的每次查询读取次数。这是一个调整后的系统比较，而不是孤立的GPU加速。

通过将我们的NVMe-oE存储路径与GPU辅助向量搜索相结合，我们从7,463 QPS提升到72,212 QPS，增加了9.7倍，Recall@10约为99.8%。与CPU PipeANN配置相比，双GPU结果提供了6.1倍更高的QPS。双GPU运行产生了729.9万次4KiB读取/秒，对应约239 Gb/s的有效存储负载。

2、测试环境

我们使用了通过两条独立的200Gb/s以太网链路连接的两台主机。发起端主机是一台双路Supermicro SYS740GP-TNRT，具有32个物理CPU核心（每个插槽16个核心），禁用SMT，256 GiB DRAM，两块48 GiB RTX A6000 GPU和两条200Gb/s ConnectX-6 Dx以太网链路。24核Supermicro AS5014ATT目标主机导出了两个64 GiB易失性稀疏RAM命名空间，每个命名空间使用24个队列，队列深度512。RAM后端故意移除了物理介质和持久性限制，因此此阶段测量的是ANN应用程序、主机路径和传输。

基准测试使用BigANN-10M、L2距离和top-10搜索，以及针对特定引擎的索引和执行调优。选择的GustANN配置是R128/L200/PQ32，L100/B1536/T13/C1；这些参数控制图构建、压缩、搜索宽度、批处理和并发性。详细的定义和调优指南可在DiskANN论文、PipeANN论文和演示以及GustANN项目指南中找到。

3、仍有余量

有趣的是，NVMe-oE尚未饱和。我们验证的图页面服务上限是1178万IOPS，而双GPU ANN工作负载达到了730万IOPS，约为该上限的62%。

运行时遥测有助于解释剩余的余量。在双GPU运行期间，分配给GustANN搜索工作者的CPU核心平均忙碌98.4%，而两个GPU平均只有52.3%的计算利用率。因此，当前客户端在GPU或NVMe-oE链路饱和之前，就耗尽了CPU容量来准备和提交搜索工作。更多或更快的CPU核心，加上改进的批处理和调度，可以使GPU更忙碌并驱动更高的IOPS和QPS。

纯CPU引擎在饱和NVMe-oE之前就达到了计算限制。DiskANN和PipeANN分别产生了263.4万和370.5万IOPS，而它们的ANN搜索工作者已经高度利用；在选定的PipeANN候选中，搜索核心平均忙碌95.8%。GPU辅助的GustANN将更多的并行向量搜索工作从CPU上移走，使应用程序能够产生729.9万IOPS。

应用程序通过普通的Linux块设备使用O_DIRECT和io_uring访问NVMe-oE；不需要GPUDirect Storage或SPDK发起端。

NVIDIA GPUDirect Storage（GDS）不一定是此工作负载的最佳下一步。当GPU直接消费存储数据时，GDS最有效，但GustANN的小型、依赖数据的读取仍由CPU工作者调度。由于CPU请求处理（而非数据复制）是明显的瓶颈，仅GDS不太可能显著增加IOPS。因此，我们下一个优化重点是CPU调度和I/O批处理，而GDS仍是未来评估的一个选项。

4、下一步是什么？

下一步是与标准NVMe-oF进行受控比较：通过NVMe/RDMA（RoCE）和NVMe/TCP的Linux nvmet和SPDK目标。

目标很明确：确定当AI向量搜索每秒需要数百万次小型随机读取时，精简的NVMe-oE存储路径可以提供多少优势。这与多租户、共享存储环境特别相关，因为许多ANN工作者和GPU主机同时访问池化的向量索引。更高的小I/O效率可以提高租户密度、存储利用率和性能可预测性，同时允许计算和存储容量独立扩展。我们的初步存储测试表明，在我们的测试环境中，潜在的IOPS和吞吐量优势接近传统nvmet/SPDK路径的2倍。下一阶段将确定该原始存储优势是否能延续到Recall验证的ANN和更广泛的AI工作负载。敬请期待。

原文链接：From 7K to 72K QPS: Scaling Vector Search for RAG and AI Workloads with NVMe-oE

汇智网翻译整理，转载请标明出处

Gemini 3.1不是一个带有四个营销名称的单一模型。它是一个路由图：为困难工作提供深度推理，为大批量任务提供低成本吞吐量。

1、Gemini 3.1 Pro是图表的深度工作端

Google DeepMind的模型卡将Gemini 3.1 Pro描述为一个原生多模态推理模型，适用于复杂任务。其输入包括文本、图像、视频、音频和PDF，模型可以处理大型代码库和工具调用。

模型页面列出了100万token的输入限制和64,000 token的输出限制。它还列出了函数调用、结构化输出、搜索作为工具和代码执行。这些功能使Pro适合需要模型持有大型证据集、跨模态推理并返回其他系统可以使用的内容的任务。

这并不意味着每个请求都应该使用Pro。百万token窗口提高了上限；它不会使小型分类更有价值。它也可能使错误来源更难被发现，因为来源以更详细的形式可用。

正确的Pro问题是：任务是否需要长上下文、深度推理、多模态综合或代理工具使用？如果不是，更轻量的路由可能是更专业的选择。

2、基准测试表是操作点的地图

Google的模型卡将Gemini 3.1 Pro Thinking的高设置与其他系统在命名的测试环境和条件下进行比较。一些主要值包括：

• Humanity's Last Exam — Gemini 3.1 Pro结果： 44.4% — 条件： 无工具
• Humanity's Last Exam with search and code — Gemini 3.1 Pro结果： 51.4% — 条件： 搜索黑名单加代码
• ARC-AGI-2 — Gemini 3.1 Pro结果： 77.1% — 条件： ARC Prize Verified
• Terminal-Bench 2.0 — Gemini 3.1 Pro结果： 68.5% — 条件： Terminus-2 harness
• SWE-Bench Verified — Gemini 3.1 Pro结果： 80.6% — 条件： 单次尝试
• BrowseComp — Gemini 3.1 Pro结果： 85.9% — 条件： 搜索、Python和浏览
• τ2-bench Retail — Gemini 3.1 Pro结果： 90.8% — 条件： 代理工具使用设置
• MRCR v2, 1M pointwise — Gemini 3.1 Pro结果： 26.3% — 条件： 长上下文检索设置

这些数字很有用，因为它们展示了广度，但它们不是通用排行榜。模型卡本身记录了不同的工具访问、测试环境、尝试次数和思考设置。有搜索的分数回答的问题与没有工具的分数不同。

不常见的细节是MRCR v2。模型可以宣传百万token输入限制，同时长上下文检索仍然是一个独立的问题。"可以接受百万token"和"可以可靠地在百万token内找到正确的事实"不是同义词。

对于实际系统，在答案改变的地方测量检索精度。如果模型选择了错误的发票、仓库文件或策略段落，漂亮的最终解释也无法挽救工作流。

3、Flash-Lite是队列管理器

Google的开发文档将Gemini 3.1 Flash-Lite描述为一个低成本、高效率的多模态模型，适用于高频、轻量级任务。文档中显示的稳定模型ID是gemini-3.1-flash-lite。

输入限制为1,048,576 token，输出限制为65,536 token。这在纸面上听起来几乎像Pro，但产品意图不同。Flash-Lite针对翻译、转录、提取、分类、文档分类和延迟及成本是主要约束的轻量级代理工作进行了优化。

它接受文本、图像、视频、音频和PDF输入。文档列出了结构化输出、函数调用、搜索基础、文件搜索、代码执行和URL上下文。它没有列出此路由的图像生成或Live API支持。

最后一个区别在操作上很重要。大上下文窗口不会使Flash-Lite成为Pro的通用替代品。它是一个宽入口漏斗，而不是最深的推理台。

Google的文档甚至将路由用作模型模式：低成本分类器可以决定请求是留在Flash-Lite上还是移动到更强大的模型。这对构建者来说是一个实用的线索。让廉价模型在花费高级计算之前回答简单问题"这是什么类型的任务？"

4、Live改变了交互的形状

Gemini API变更日志记录了gemini-3.1-flash-live-preview作为一个音频到音频模型，用于实时对话和语音优先应用程序，于3月26日发布。

Live不仅仅是延迟更短的TTS。对话有轮流发言、中断、部分音频、沉默、插入行为、工具调用以及用户在完整响应完成之前改变方向的可能性。

因此测试应该包括事件，而不仅仅是最终转录：

• 系统多快开始响应；
• 当用户中断时是否停止；
• 工具调用是否被宣布和确认；
• 是否保留句子的未解决部分；
• 最终答案是否与实际发出的音频一致。

罕见的工作流洞察是将对话存储为事件日志。保留用户音频、部分转录、模型轮次、工具请求、工具结果和由时间戳链接的最终音频。如果系统出错，"声音听起来不对"不足以调试它。你需要知道错误是始于识别、轮次检测、推理、工具使用还是合成。

5、TTS是一个独立的交付表面

Google的语音生成文档公开了gemini-3.1-flash-tts-preview。它支持单人和多人语音、对语气、口音和节奏的自然语言控制、一组语音选项和流式音频输出。

API示例展示了转录和交付指令之间的有用区别。提示可以指定一个说话者听起来疲倦，另一个兴奋，然后为每个说话者分配语音。TTS路由输出音频；另一个模型可以先创建或修改转录。

这种分离比要求一个对话模型在没有检查点的情况下即兴创作脚本和表演更健康。当发音、法律语言或时间安排很重要时，在语音传递之前冻结文字。

TTS应该在行级别进行测试：

1. 提供包含姓名、数字和标点的简短脚本。
2. 添加交付指令而不改变文字。
3. 以第二种情感方向生成相同的行。
4. 比较发音、时间安排、呼吸放置和说话者连续性。
5. 将确切的模型ID、语音和提示与音频一起保存。

自然语言风格控制很有用，但它们也可能隐藏回归。听起来更有表现力的声音可能变得不够精确。生产指标不是"足够人性化"，而是"有表现力而不破坏指令"。

6、一个家族，四种失败模式

Gemini 3.1的分支失败方式不同：

• Pro — 最适合： 深度推理、长上下文、多模态代理 — 需注意的失败： 从大上下文检索到看似合理但错误的来源
• Flash-Lite — 最适合： 高容量提取、路由和分类 — 需注意的失败： 快速处理任务但错过需要升级的模糊性
• Live — 最适合： 实时音频到音频对话 — 需注意的失败： 丢失轮次边界或在工具结果确认之前采取行动
• Flash TTS — 最适合： 受控叙述和多人交付 — 需注意的失败： 听起来自然但错误发音姓名、数字或技术术语

这张表比单一家族排名更有用。同一个应用程序可能需要所有四个路由。语音助手可以使用Flash-Lite对传入请求进行分类，Pro推理复杂账户问题，Live管理音频循环，TTS生成受控公告。

7、构建者的实用路由器

从窄输入模式开始：

• 模态：文本、图像、视频、音频或文档；
• 延迟预算：批处理、交互式或实时；
• 输出类型：文本、JSON、工具调用或音频；
• 风险级别：可逆答案或外部操作；
• 上下文大小：短、长或仓库规模。

然后路由：

1. 使用Flash-Lite进行分类、提取和首次转录。
2. 将模糊或高影响请求升级到Pro。
3. 仅当用户体验依赖于中断和流式传输时使用Live。
4. 在转录和交付约束批准后使用TTS。
5. 在代理语音循环更改数据或联系其他人之前要求确认。

小技巧是记录每次升级的原因。"发送到Pro因为PDF包含两个冲突的总数"比安静地学习将所有内容发送到昂贵模型的路由器更有用。

8、安全是路由的一部分

多模态输入可能包含图像、文档、语音指令或网页结果中的提示注入。实时音频增加了另一个风险：快速、自然的响应可以使未确认的操作听起来已被批准。

保持读写工具分离。使用结构化输出进行路由决策。在购买、消息、帐户更改或破坏性操作之前添加回读步骤。将音频和转录保留规则与模型配置一起存储。

预览端点和模型别名也需要纪律。Google的变更日志显示模型ID随时间推出、重定向和弃用。在可重复性很重要的地方固定快照，并在实验记录中保留别名加日期。

9、底线

Gemini 3.1在最实际的意义上是一个家族发布。

Pro是具有多模态上下文、工具和大型推理预算的深度工作台。Flash-Lite是高容量队列管理器。Live是实时音频循环。Flash TTS是受控交付层。

这个家族的优势不是某个模型赢得每个基准测试。而是应用程序可以根据必须处理的事件选择模型。这使得系统更快、更容易审计——如果路由边界是明确的。

按循环选择，而不是按标志：

在歧义昂贵时深入推理，在重复量大时轻量路由，仅在时间安排重要时流式传输，在文字批准后合成语音。

这是隐藏在Gemini 3.1发布中的模型家族洞察。

原文链接：Gemini 3.1: Google Splits Pro, Flash-Lite, Live and TTS

汇智网翻译整理，转载请标明出处

我们当时正在为企业客户构建一个财务文档助手。分析师上传财报、10-K表格、投资者演示文稿，然后提问："Q3营收是多少？""毛利率同比增长多少？""管理层对员工规模有何评论？"

在受监管的环境中，这个问题很简单——但一个错误的数字不仅仅是尴尬，而是合规问题。

该系统运行在Azure上：文档存储在Azure Blob Storage中，分块并索引到Azure AI Search，检索命中向量索引，通过Azure OpenAI GPT-4o生成答案。标准的企业RAG技术栈，没什么特别的。

然而，该系统在数字查询上的幻觉率高达15%——不是模糊问题，而是那些答案应该是特定文档中特定表格里特定数字的问题。

我确信这是检索问题。于是我做了所有人都会做的事：调整分块大小、调整重叠度、切换嵌入模型、添加更多上下文、将top_k从5增加到8。花了两周时间，幻觉率几乎没有变化。

然后我实际记录了LLM接收的内容与返回的内容。正确的分块就在上下文中，正确的数字就在那里，而模型却给出了不同的数字。

检索没问题。我花了两周时间调试错误的东西。

这正是我希望在浪费时间之前能读到的文章。

我使用的技术栈：

• Azure Blob Storage — 文档存储
• Azure AI Search — 混合检索（向量 + BM25）
• Azure OpenAI GPT-4o — 生成
• LangChain — 编排
• Langfuse（在Azure Container Apps上自托管）— 追踪
• Python — 其他所有

0、改变一切的思维模式

我把管道当作一个整体：查询进去，答案出来，答案错了就修复检索。

但它不是一个整体，而是一个链条：

查询 → 检索 → 上下文组装 → 生成 → 验证 → 答案

每个步骤都可能独立失败。由于我只衡量最终答案，完全不知道哪个步骤出了问题。一旦我单独衡量每个环节，问题在一天内就变得显而易见了。

1、在修改任何东西之前，先证明哪个层坏了

我构建了一个标注的评估集：50个查询，我知道预期答案、哪个分块包含证据以及涉及的确切数字。然后我单独衡量检索效果：

def evaluate_retrieval(eval_set, retriever, k=5):
    hits = 0
    for item in eval_set:
        retrieved = retriever.get_relevant_documents(item["query"])[:k]
        chunk_ids = [doc.metadata["chunk_id"] for doc in retrieved]
        if item["required_chunk_id"] in chunk_ids:
            hits += 1
    print(f"Recall@{k}: {hits / len(eval_set):.1%}")

# 结果：Recall@5: 91%
# 正确的分块每10次有9次被返回

91%的召回率。检索器在做它该做的事。每小时调节它都是浪费时间。问题在下游。

我现在的规则： 如果召回率高于85%，就不要再动检索器，看看它之后发生了什么。

2、看看LLM实际收到了什么

我一直在记录查询和最终答案，没有记录介于两者之间的组装上下文——问题就出在那里。

def generate_with_logging(query, retrieved_docs, llm):
    context = assemble_context(retrieved_docs)
    
    # 记录分块位置——这就是我发现问题的地方
    for i, doc in enumerate(retrieved_docs):
        score = doc.metadata.get("score", "?")
        print(f"[位置 {i+1}] 评分={score} | {doc.page_content[:150]}")
    
    return llm.invoke(f"""
仅使用以下上下文回答。
如果上下文不包含答案，请说明。

上下文：{context}
问题：{query}
    """)

我的发现：最高评分的分块每次都落在8个位置中的第4或第5位。最相关的证据被埋在了中间。

有一个关于这个的研究叫做"迷失在中间"——当关键证据在长上下文的中间时，模型的表现会显著下降。我听说过这个研究，以为不适用于我，但事实证明非常适用。

修复方法：

def assemble_context(retrieved_docs, scores):
    # 按评分排序——最佳证据放在前面，而不是检索顺序
    pairs = sorted(zip(retrieved_docs, scores),
                   key=lambda x: x[1], reverse=True)
    chunks = [f"[评分: {s:.2f}]\n{d.page_content}" for d, s in pairs]
    return "\n\n---\n\n".join(chunks)

幻觉率：15% → 9%。仅靠上下文排序，无需其他修改。

3、在生成前添加检索质量检查

即使有91%的召回率，仍有9%的查询带着薄弱证据进入生成阶段。我需要系统在生成可能编造的内容之前捕获这种情况。

def check_retrieval_quality(query, retrieved_docs, llm) -> float:
    sample = "\n".join([d.page_content[:300] for d in retrieved_docs[:3]])
    score = llm.invoke(f"""
查询：{query}
检索到的上下文（示例）：{sample}

此上下文是否包含回答查询所需的内容？
仅回复数字：0.0（无用）到 1.0（直接回答）。
    """).content.strip()
    return float(score)

def rag_with_quality_check(query, retriever, llm):
    docs = retriever.get_relevant_documents(query)
    
    if check_retrieval_quality(query, docs, llm) < 0.5:
        # 检索薄弱——尝试重新表述查询
        better_query = llm.invoke(
            f"更具体地重新表述：{query}"
        ).content
        docs = retriever.get_relevant_documents(better_query)
    
    return docs

那些漏网的查询都存在检索薄弱问题，重新查询可以解决。这让我达到5%。

4、停止评估整个答案。评估每个声明。

"营收从7.2亿美元增长到8.426亿美元，增长17%"不是一个评估对象，而是四个声明：

• 营收为7.2亿美元
• 营收为8.426亿美元
• 增长率为17%
• 这发生在全年

我之前评估整个答案的通过/失败。一个正确句子中的错误数字会被计为通过。难怪我的评估指标看起来比生产环境好。

def verify_claims(answer, retrieved_docs, llm):
    context = "\n\n".join([d.page_content for d in retrieved_docs])
    
    # 将答案分解为单独的声明
    claims_text = llm.invoke(f"""
将此分解为单独的事实声明。每行一个，无项目符号。
答案：{answer}
    """).content
    claims = [c.strip() for c in claims_text.strip().split("\n") if c.strip()]
    
    # 独立验证每个声明
    results = []
    for claim in claims:
        verdict = llm.invoke(f"""
上下文：{context}
声明：{claim}

是否被支持？回复：
SUPPORTED - 原因
CONTRADICTED - 原因
NOT_IN_CONTEXT - 原因
        """).content.strip()
        results.append({"claim": claim, "verdict": verdict})
    
    return results

# 我的发现：
# "营收为7.2亿美元"      → SUPPORTED
# "营收为8.426亿美元"    → SUPPORTED
# "增长率为17%"          → CONTRADICTED - 上下文显示为14.2%
# "全年增长"             → NOT_IN_CONTEXT

几乎所有剩余的幻觉都在一个类别：计算出的数字。模型在心算时出错了。

5、不要让LLM做数学计算

这是修复数字幻觉的实际方法。

模型擅长语言，但不是计算器。当我要求它在同一步骤中检索数字并计算百分比时，有时会检索正确但计算错误。或者更糟，部分幻觉出起始数字并基于此计算。

修复：用LLM提取，用Python计算，用LLM解释。

import json
def answer_with_deterministic_numbers(query, retrieved_docs, llm):
    context = assemble_context(retrieved_docs,
              [d.metadata["score"] for d in retrieved_docs])
    
    # 步骤1：仅提取原始值——不计算
    raw = json.loads(llm.invoke(f"""
提取与此查询相关的原始数值。不要计算。
返回JSON：{{"values": [{{"label": "名称", "value": 123.4, "unit": "USD_millions"}}]}}
上下文：{context}
查询：{query}
    """).content)
    values = {v["label"]: v["value"] for v in raw["values"]}
    
    # 步骤2：用Python计算——确定性的，不可能产生幻觉
    computed = {}
    if "revenue_prior" in values and "revenue_current" in values:
        growth = ((values["revenue_current"] - values["revenue_prior"])
                  / values["revenue_prior"]) * 100
        computed["growth_pct"] = round(growth, 2)
    
    # 步骤3：LLM解释——使用经过验证的数字，不重新计算
    return llm.invoke(f"""
使用这些经过验证的事实回答。精确使用给定的数字。不要重新计算。
事实：{json.dumps({**values, **computed})}
问题：{query}
    """).content

# 之前："营收增长21%"（LLM猜错了）
# 之后："营收增长14.2%"（Python计算，LLM解释）

数字幻觉率：5% → 2%。

6、构建决策层。停止总是生成答案。

最后一块拼图：系统现在有三种明确的结果，而不是总是返回某些内容。

def production_rag(query, retriever, llm):
    docs   = rag_with_quality_check(query, retriever, llm)
    answer = answer_with_deterministic_numbers(query, docs, llm)
    claims = verify_claims(answer, docs, llm)
    
    supported    = [c for c in claims if "SUPPORTED"      in c["verdict"]]
    contradicted = [c for c in claims if "CONTRADICTED"   in c["verdict"]]
    unsupported  = [c for c in claims if "NOT_IN_CONTEXT" in c["verdict"]]
    
    if contradicted:
        # 某些内容与源矛盾——带修正重新生成
        corrections = "\n".join([c["verdict"] for c in contradicted])
        answer = llm.invoke(f"""
以下声明被源矛盾：
{corrections}

源：{[d.page_content for d in docs]}
问题：{query}

仅使用源支持的内容编写修正后的答案。
        """).content
        return {"answer": answer, "status": "corrected"}
    
    elif len(unsupported) > len(supported):
        # 不支持的比支持的多——不猜测
        return {
            "answer": "我没有足够的信息来可靠地回答这个问题。",
            "status": "abstained"
        }
    
    return {
        "answer": answer,
        "status": "answered",
        "confidence": f"{len(supported) / len(claims):.0%}"
    }

系统现在会在应该说"我不知道"的时候说"我不知道"。这消除了自信错误答案的长尾。

最终幻觉率：约1%。

7、实际改变数字的因素

我纠结的检索器调节？基本上没有影响，因为检索根本不是问题。

8、我会对六周前的自己说什么

停止将RAG视为检索然后生成。它是一个链条：在调节任何环节之前先衡量每个环节。问题几乎从不出现在你预期的地方。

对于涉及受监管领域数字的任何内容——金融、医疗、法律、运营——不要让LLM计算。提取数值，用Python计算，用LLM解释。仅这一项改变就能解决大多数数字幻觉。

9、要点

在受监管环境中，15%的幻觉率不是模型问题，也不是嵌入问题，而是管道问题——而管道有六个环节，任何一个都可能独立失败。

我在检索器上度过的两周通过失败教会了我比修复它的六个步骤更多的东西，因为我现在确切知道首先该看哪里。

调节之前先衡量。计算之前先提取。回答之前先验证。当证据不存在时——说出来。

这就是将RAG演示与真正可信的合规系统区分开来的地方。

原文链接：6 Steps That Fixed My RAG Hallucination Rate From 15% to 1%

汇智网翻译整理，转载请标明出处

随着开发工作变得越来越复杂，终端仍然是构建、管理和测试应用程序的重要组成部分。一个设计良好的终端工作流可以让开发更高效、更易于管理。

即使有强大的IDE和图形化工具可用，许多开发者仍然偏爱命令行的灵活性和控制力。合适的工具可以扩展你现有的命令，帮助你构建适合工作方式的工作流。以下是一些能让你的开发更强大、更高效的CLI工具。

1. psmux 🪟

如果你喜欢tmux但大部分时间在Windows上工作，psmux为Windows Terminal带来了类似的终端多路复用体验。它是专为Windows设计的原生高性能替代方案。

psmux

和tmux一样，psmux允许你将终端分割成多个窗格、创建会话，并在不打开单独窗口的情况下切换shell。它还支持psmux、pmux和[tmux](https://github.com/tmux/tmux)命令，让体验更加熟悉。.

2. rustnet 🌐

Rustnet是一个终端网络监控工具，可以实时查看系统上的网络活动。它是netstat等工具的现代替代品，让活动连接更易于理解。

你可以直接在终端中查看活动连接、监听端口、远程地址、协议和网络活动。交互式界面让你轻松识别哪些应用程序正在与网络通信，无需翻阅冗长的命令输出。

3. ast-grep 🔍

ast-grep是一个代码搜索和重写工具，它基于语法和结构而不是文本匹配来搜索代码。ast-grep类似于grep，但它匹配的是代码模式而不是文本。

ast-grep -p 'console.$METHOD($$$)' src/

你可以跨不同编程语言搜索模式，同时忽略格式和变量名的差异。它还可以重写找到的代码，这在大型重构任务中非常有用，手动修改数百个文件会花费很长时间。

4. hunk 🧩

Hunk是一个帮助你交互式审查和编辑Git差异的工具。与其一次性接受所有更改，你可以逐个查看每个代码块，精确决定应该包含哪些内容。

hunk diff

你可以审查每个更改、拆分代码块、暂存特定部分，并直接在终端中进行小的编辑。使用hunk，你比运行git add .有更多控制权，特别是当一个文件同时包含有用的更改和不相关的编辑时。

5. ccstatusline 📊

ccstatusline是一个可定制的状态栏，用于Claude Code，可以在终端中显示有用的会话信息。你可以在代理运行时快速查看使用情况和会话详细信息。

你可以自定义状态栏显示模型详细信息、token使用量、上下文窗口和其他会话数据等信息。它直接与Claude Code配合工作，因此信息保持可见，不会中断你的工作流。

6. Atomic Agent ⚛️

Atomic Agent是一个AI代理，设计为在本地机器上运行，同时支持本地和云模型。它不仅仅是生成代码，还可以浏览网页、编辑文件、运行批准的shell命令，并在会话间保持上下文。

你获得一个交互式终端界面，让代理可以与你的文件、浏览器、Git仓库、文档和其他工具一起工作。如果你想在自己的硬件上运行小型量化模型，同时仍然可以访问shell、文件系统、浏览器和MCP等工具，这会很有用。..

7. AutoCLI 🌐

AutoCLI是一个CLI工具，无需打开浏览器或编写自定义爬虫即可从网站获取信息。它支持各种网站，包括Reddit、YouTube、Hacker News等。你还可以控制桌面应用程序并连接GitHub CLI、Docker和kubectl等工具。

autocli hackernews top --limit 12

你可以直接在终端中获取表格、JSON、YAML、CSV和Markdown等格式的结构化结果。它还可以重用经过身份验证的浏览器会话，使用AI发现网站API，并自动创建适配器。

8. Agent browser 🌐

Agent-browser是一个CLI工具，帮助你的代理直接从终端与网站交互。代理无需控制网络浏览器，即可打开页面、检查元素、填写表单并使用简单命令提取信息。

它使用可访问性快照提供网页的更清晰视图，帮助代理找到并交互正确的元素。你可以用它来自动化重复的网页工作流、网站测试，或给编码代理提供直接从终端与Web应用程序交互的方式。

9. Glow ✨

Glow是一个Markdown阅读器，你可以直接在终端中读取.md文件。它很好地格式化标题、代码块、列表和链接，使得无需打开浏览器或编辑器即可轻松阅读文档。

glow github.com/vercel-labs/agent-browser

你可以交互式浏览Markdown文件、搜索文档，甚至从本地文件读取内容。当你已经在终端中并想快速读取Markdown文件而不切换到另一个应用程序时，Glow是一个非常方便的工具。

10. Hyperfine ⚡

Hyperfine是一个基准测试工具，帮助你测量命令运行所需的时间。与其手动使用time运行相同命令多次，它会多次运行命令并提供更准确的计时结果。

当你优化脚本、构建命令或CLI工具时，如果小的性能差异很重要，可以使用hyperfine。它提供了一种快速基准测试更改的方法，而不是依赖单次执行时间。

原文链接：10 Modern CLI Tools for a Better Developer Workflow

汇智网翻译整理，转载请标明出处