Stripe VS Code AI 助手：RAG 架构与评估实践

Stripe 的 docs.stripe.com 原始文本内容超过 130 MB（作为对比，我大学的操作系统教科书只有 7 MB 的 PDF），并且每周更新数百次。虽然大语言模型在预训练中包含 Stripe 的知识，但它们几乎很快就会过时，并且偶尔会产生错误信息。支付集成非常复杂，Stripe 也提供了很多可定制性。

这就是为什么我们在 VS Code 扩展中内置了 Stripe AI 助手——它通过搜索相关的 Stripe 知识（如 API 参考条目、集成指南、代码示例和开发者 Discord 讨论线程）来回答你的问题。相比单独使用原始 LLM 工具，这提高了准确性，并允许根据你的 Stripe 账户提供个性化响应。

使用扩展

访问 https://ai.stripe.com/vscode 自动安装并打开 Stripe AI 助手。

该扩展也可在 VS Marketplace 获取。我们建议同时安装 Stripe CLI 以启用更多功能（流式 webhook 事件、个性化 AI 响应等）。

GitHub Copilot 用户可以直接在聊天中输入 @stripe。如果不使用 Copilot，扩展也提供自己的聊天 UI。

助手调用我们的后端获取最新的相关 Stripe 文档，这减少了幻觉——即 LLM 产生事实错误输出的情况。扩展还会自动插入你的 API 密钥，让你快速测试可以正常运行的代码片段。

我们可以运行助手生成的定制代码，得到一个可用的支付链接：

import stripe

stripe.api_key = "rk_test_..."

product = stripe.Product.create(
    name="Original Abstract Painting",
    description="24x36 inch acrylic on canvas",
    images=["https://example.com/artwork-image.jpg"],
)

price = stripe.Price.create(
    product=product.id, unit_amount=50000, currency="usd"  # $500.00
)

payment_link = stripe.PaymentLink.create(
    line_items=[{"price": price.id, "quantity": 1}]
)

print(f"Share this payment link: {payment_link.url}")

除了检索文档，助手还会搜索数千条 Stripe 开发者 Discord 讨论线程。这里有一个关于订阅的更复杂的问题示例：

这是一个用户在 Discord 上提出的真实问题。Stripe 工程师在 Discord 上实时帮助用户排查集成问题。我们构建了一个流水线，利用 LLM 总结问题和解决方案。然后通过人工评估，挑选最佳总结进入搜索索引。团队每周审核数百份总结，精心策划需要综合多份文档见解的高质量知识。通过索引这些线程，Stripe AI 助手能够回答更复杂的集成问题。

从文档引导的流程

我们还在文档中推出了”在 VS Code 中打开”按钮。我们从集成快速入门指南开始。这会深度链接到 VS Code 扩展，并直接在编辑器中引导你完成特定的集成。它拥有相同的 AI 辅助工具，因此你可以在集成过程中的任何时候提问，并获得针对你代码库的回答。

工作原理

为了帮助解决 LLM 幻觉问题，我们使用检索增强生成（RAG）来选择正确的 Stripe 知识片段，放入我们发送给 LLM 的提示中。

当提出问题时，流程如下：

分类器：我们将查询分类到各个类别（API 参考、文档、编码帮助等）。这也有助于防止任何对抗性或不相关的问题，并允许我们通过扩展查询来改进检索。

检索：我们不断调整索引和查询设置以改进搜索。大体上，我们结合使用基于 BM25 的关键词搜索和 k 近邻嵌入搜索来检索相关文档块。

重排序：考虑这个问题”Connect 集成的主要组件有哪些？“简单搜索可能会返回”Embedded Connect 组件入门指南”文档，但更好的文档应该是我们更通用的 Connect 概述指南。重排序就是在检索后重新排列搜索结果的过程；我们使用页面流量和其他因素来调整结果顺序。

提示：我们结合相关文档源、代码片段示例、用户代码和用户问题构建提示，将完整提示发送给 LLM（目前是 Claude Sonnet），并将响应流式传输回 VS Code 助手。

为确保助手保持更新，我们有一个每晚运行的 Temporal 工作流，对数千份集成指南、API 参考条目、代码片段和总结的开发者 Discord 线程进行分块和嵌入。由于文档过长，LLM 难以消化，我们”分块”处理——将文档拆分为更小的部分。然后我们将这些块的语义含义编码为嵌入向量，作为检索集的一部分进行搜索。

对于 VS Code 扩展聊天 UI，我们与微软合作，成为新聊天扩展框架的首批用户之一。通过该框架，任何 VS Code 扩展都可以贡献一个”@可提及的代理”，使 GitHub Copilot 更强大。

评估

在 AI 工作中衡量成功至关重要。由于 LLM 是非确定性的，我们需要谨慎客观地评估响应质量。每个用户的问题（去除个人身份信息）和生成的响应都会记录到我们的 LLM 评估工具中。然后我们可以比较不同批次的问题及其响应。

第一步：构建数据集

我们构建了一个”黄金”数据集，包含用户问题及我们确定的最佳来源文档配对。但为了全面测试我们的 RAG 系统，我们需要更多数据。我们用 LLM 生成用户可能提出的与每份 Stripe 文档相关的问题来扩充这个黄金数据集。我们手动检查了生成的问题并删除了不合理的问题。完成之后，我们现在有数千个问题以及预期的 URL。

第二步：测量

当用户问”Checkout 使用哪个客户地址来计算税费？“时，响应应该使用 https://docs.stripe.com/payments/checkout/taxes 文档。正确性的最简单衡量是：检索步骤是否选择了正确的文档？

然而，检索引擎返回的是多个文档的有序列表，因此我们可以更精细地衡量正确性。我们使用平均倒数排名（MRR）来测试相关性评分和重排序的有效性。如果我们检索到了文档但排在第二位，它的得分会比排在第十五位更高。MRR 计算为 1 / 位置，所以如果正确文档在第二位被检索到，MRR 为 0.5，第三位为 0.33，第四位为 0.25，依此类推。对数据集中所有问题的倒数排名取平均，得到整体正确性度量。

第三步：改进

有了评估系统，我们可以对检索系统的行为提出假设并相应调整。例如，我们发现仅靠语义嵌入搜索在选择 API 参考的相关部分时效果不佳。我们开始使用结合传统关键词搜索和语义嵌入搜索的”混合”搜索，看到准确性分数有所提升。另一个例子是，我们注意到像”如何构建支付应用”这类问题的 MRR 偏低，因为包含了 Stripe Apps 文档。我们改进了分类和重排序策略来修复这个问题，并看到了改善。

这个评估套件每晚运行，确保质量没有回退。目前，在我们的测试合成数据集上，我们约 91.11% 的时间包含最佳来源，MRR 约为 78%。我们还手动评估实时用户日志（包括生成响应的实际文本以及来源准确性）。为了帮助扩展这些手动评估，我们还构建了一个自动化的 LLM 评判系统。该系统阅读用户线程并对我们的 AI 响应进行评分（这个响应是否帮助回答了用户的问题？它是否有用？）。我们通过将其评分与我们自己的评分进行比较，不断改进 LLM 评判。随着使用量的增加，这有助于扩展我们的评估。

总结

通过 Stripe VS Code AI 助手，你可以快速集成 Stripe，只需提问而无需离开编辑器。阅读 Stripe VS Code 扩展文档了解更多信息。我们才刚刚开始——如果你对其他想看到的功能有想法或建议，请在 Stripe Insiders 上分享。

关于作者

Mathew Varughese，Stripe 软件工程师，探索 AI 与开发者体验的交叉领域。