编者按：以下内容由 Dosu 首席执行官 Devin Stein 撰写。Dosu。在这篇博客中，我们将介绍 Dosu 如何使用 LangSmith 来提高其应用程序的性能 - 无需提示工程。相反，他们收集了用户的反馈，将其转化为少量示例，然后将其反馈到他们的应用程序中。
这是一种相对简单且通用的技术，可以带来自动的性能提升。我们编写了一份 LangSmith 食谱，让任何人都可以开始使用持续的上下文学习进行分类！如果视频学习更符合您的风格，请查看我们的 YouTube 演练 此处。
有很多技术可以“教导” LLM 提高其在特定任务上的性能。最常见的是
- 提示工程
- 微调
- 上下文学习
提示工程是帮助 LLM 学习的最简单和最常见的方法，但 Dosu 采取了不同的方法。我们的团队没有使用提示工程，而且我们看到了明显更好的结果。
Dosu 是一位可以学习的工程队友
Dosu 是一位工程队友，充当临时工程请求的第一道防线，保护工程师免受不必要的干扰，并为 GTM 团队解除阻塞。我们有意使用“队友”而不是副驾驶或助手，因为像队友一样，Dosu 应该学习特定于您组织的细微差别和工作流程。
如果您还没有听说过 Dosu，您可以查看我们之前的博客文章或查看这些示例。其核心是，Dosu 自动化了工程师不想做的工作。一个简单的例子是标签。很少有工程师愿意花时间管理工单和 PR 上的标签（如果您正在阅读本文并且您喜欢这样做……我们正在招聘 😉），但是，拥有一致、高质量的标签非常重要！标签允许工程团队搜索、理解和优化他们花费时间的地方。如果您对此持怀疑态度，请观看最近由传奇 Kubernetes 维护者 MyBobbyTables 在 KubeCon 演讲 中解释为什么标签对于工程生产力至关重要。
Dosu 自动为您标记工单，因此您可以在无需工作的情况下获得所有好处。听起来很棒，对吧？但要有用，Dosu 必须是正确的。不正确的标签可能会导致比没有标签更多的工作。从表面上看，标签似乎是一项简单的任务；然而，在实践中，标签通常是主观的，并且对于每个组织来说都是独一无二的。例如，LangChain 的增强标签是关于全新的库功能或集成，而 Dosu 的相同增强标签专门用于改进现有功能。为了完成其工作，Dosu 需要学习每个组织特定的标签含义和规则。那么我们如何教导 Dosu 做到这一点呢？
产品中的提示工程会导致糟糕的用户体验
尽管提示工程可以大大提高 LLM 的性能，但 Dosu 不仅仅是一个 LLM。它是一个产品。LLM 的魔力来自于那些“只需工作”的时刻。我们认为将提示工程的负担放在用户身上会降低这种魔力，并导致不可靠的产品体验。更具体地说
- 提示是挑剔的。如果产品依赖于用户提示工程的能力，我们就无法保证可靠的产品体验。
- 提示是模型相关的。我们希望 Dosu 为任何给定的任务使用最佳的 LLM。我们不希望内部 LLM 的更改破坏用户花费数小时制作的提示。
- 提示是静态的。组织不断变化。提示中的硬编码逻辑会很快变得陈旧和不正确。
微调模型管理复杂且容易受到数据漂移的影响
如果提示工程被排除在外，那么微调呢？Dosu 有足够的流量来收集微调数据集，这相对简单，但微调也有一些致命的缺点
- 微调模型管理复杂。如果我们需要为 N 个客户微调模型，我们需要服务、重新训练和监控 N 个不同的模型。这是可以解决的，但很耗时。
- 微调模型是静态的。与提示类似，微调模型在时间上是固定的。组织会发生变化，导致微调模型性能因数据漂移而以意想不到的方式下降。
重要的是要强调，这些权衡专门针对预期输出因每个组织而异的任务。对于所有组织预期输出相同的任务，例如输入分类，微调是优化性能的完美解决方案。
静态上下文学习也容易受到数据漂移的影响
这就剩下上下文学习，也称为少样本学习。回顾一下，上下文学习是一种技术，其中 LLM 提示包括给定任务的示例输入/输出对。上下文学习简单但有效。它可能非常有效，以至于像 DSPy 这样的库（它为您找到最佳的少样本示例）可以将性能提高多达 65%。
从产品的角度来看，上下文学习有很多值得喜欢的地方。当 Dosu 出错时，用户通常会纠正它。这自然会为上下文学习创建一个输入/输出示例，这意味着用户可以在不了解 LLM 的情况下教导 Dosu。
在操作上，上下文学习降低了提示的复杂性，并降低了更改 LLM 的切换成本。通过依靠示例来向 LLM 演示常见的故障模式和边缘情况，我们避免了制作针对特定 LLM 优化的脆弱、复杂的提示。
尽管从产品的角度来看，上下文学习可以满足我们的需求，但论文中大多数对上下文学习的引用都依赖于静态示例，并且仍然容易受到数据漂移的影响。正如所讨论的，组织是动态的，我们需要 Dosu 适应他们的变化。
持续上下文学习简单而有效
上下文学习的一个巧妙之处在于，只有一个变量需要调整：示例。
为了教导 Dosu 了解组织的特殊性，我们所需要做的就是为给定时间给定任务的组织选择最佳示例。
在我们选择最佳示例之前，我们需要收集它们。如前所述，当用户纠正 Dosu 时，我们会将他们的更正保存为该任务的示例，然后将其与用户的组织相关联。我们将所有这些示例存储在一个数据库中，我们将其称为示例存储（类似于传统的 ML 特征存储）。
现在，每当 Dosu 要完成一项任务时，我们都可以搜索我们的示例存储以找到最相关的示例。这会将我们的学习问题转化为检索问题，类似于我们在 RAG 中已经做的那样。
而且，就是这样。最终的持续上下文学习流程在概念上很简单
- 从用户那里收集更正并将其保存到示例存储中
- 在推理时，搜索示例存储并尝试为当前输入找到最佳示例
- 重复
最终结果为我们提供了我们正在寻找的东西：一种让 Dosu 了解组织并适应其随时间变化的自然方式。
使用 LangSmith 实施持续学习
在 Dosu，我们一直是 LangSmith 的长期用户。当我们决定将持续上下文学习作为教导 Dosu 了解组织的方向时，我们查看了是否可以使用现有工具来实施它。幸运的是，LangSmith 拥有所有构建块，可以轻松地实施持续学习。
对于收集更正，LangSmith 允许您将更正作为反馈附加到 运行。对于我们的示例存储，我们可以依赖 LangSmith 的数据集。要将示例插入 LangSmith，我们可以使用 规则 或通过 Datasets API 插入它们。
构建世界上最好的 GitHub 自动标签器
我们想测试一下我们新的持续上下文学习管道。管道中最难的部分是从用户那里收集更正。自动标签是理想的第一个候选者，因为有一个明确的正确答案，这使得收集更正变得简单。
每次用户添加 Dosu 遗漏的标签或删除 Dosu 添加的标签之一时，我们都会有一个 webhook 将其保存为 LangSmith 中运行的更正。这会触发一个规则，该规则会自动将更正作为示例插入到我们的 LangSmith 数据集中，其中包含所有相关的元数据，例如相关的组织 ID。
现在，下次 Dosu 标记 issue 或 PR 时，我们会针对当前输入和组织在所有最新示例中执行相似性搜索。我们获取排名靠前的示例，将其注入到自动标签提示中，然后运行推理。
我们一个月前发布了带有持续学习的自动标签功能，结果非常棒。Dosu 的自动标签准确率提高了 30% 以上。据我们所知，它是现有的最好的 GitHub 自动标签器。但更重要的是，我们的客户喜欢它。
持续学习是 Agent 的未来
持续学习创造了神奇的产品体验。它赋予最终用户根据自己的需求定制 Dosu 的能力，并将您在 Dosu 上投入的时间与您获得的价值相关联。
通过持续学习，Dosu 实际上可以感觉像一个队友。Dosu 可能会犯错误，但我们可以确保 Dosu 像队友一样，从这些错误中吸取教训，并且不再犯同样的错误。
自动标签只是我们正在整合持续学习的一个例子。我们正在积极探索将持续学习整合到检索、答案生成和 Dosu 的许多其他任务中的其他方法。
如果您有兴趣尝试 Dosu 以提高工程速度，或者想帮助我们构建自学习 Agent 系统，请联系 hi@dosu.dev