是时候收集关于您如何构建软件的数据了

下一代开发者正在使用大语言模型（LLM）取代谷歌 + Stack Overflow

下一代开发者正在用大语言模型 (LLMs) 取代谷歌 + Stack Overflow，正如上一代人曾用谷歌 + Stack Overflow 取代参考手册一样。在这一转型过程中，能够留住并吸引开发者的组织将：

首先，了解其开发人员如何使用 LLM，并通过收集开发数据（即关于组织如何构建软件的数据）来展示其投资回报率 (ROI)
然后，以此为基础建立开发数据引擎——一个持续的反馈循环，确保 LLM 始终拥有最新的信息和符合其首选风格的代码

通过展示投资回报率来增加 LLM 预算的工程组织将留住最优秀的开发人员。当才华横溢的新开发者在不同组织间进行选择时，可用的 LLM 质量将成为一个重要因素。开发者会加入并留在那些通过不断改进的 LLM（能够理解其代码库、项目、风格、最佳实践和技术栈最新信息的模型）获得赋能的地方。

首批意识到需要更好数据的组织，是那些因隐私和安全问题而不使用 LLM API 的公司。他们正在自己的基础设施上部署开源 LLM，这些模型最初的效果远不如 GPT-4，需要进行大量的改进。但即使是使用 OpenAI 的组织，也面临着既要争取预算又要应对数据陈旧的问题（例如，GPT-4 不了解某个库的 v3 版本，因为它是 2021 年 11 月之后发布的）。

您的组织需要收集关于您如何构建软件的数据

为了理解并扩展团队对 LLM 的使用，您需要收集关于组织如何构建软件的数据。您已经收集了大量数据：源代码、Git 版本、议题/工单、PR/MR、讨论、日志等。这些数据对于训练第一批具备编码能力的 LLM 至关重要。然而，这些数据更多是关于“构建了什么”，而非“如何构建”。

要让 LLM 对您的开发人员更有帮助，您需要收集关于 Git 提交之间发生情况的更好数据。现有数据通常缺失三个关键方面：

开发人员完成任务所采取的逐步过程
开发人员在每一步决策时所使用的上下文信息
解释这些步骤背后逻辑的自然语言

好消息是，作为 LLM 辅助开发的一项副产品，此类数据已经在产生。假设您的团队中有一位开发人员叫 Hiro。为了获取建议，Hiro 需要收集上下文（如代码、文档等）并将其提供给 LLM。随着 Hiro 与 LLM 的交互，他们将通过代码和自然语言的结合，迭代地完成手头的任务。当这些数据与 Hiro 最终提交的代码相结合时，就构成了关于软件是如何构建的丰富描述。

坏消息是，几乎所有的开发者都在通过 Copilot 和 ChatGPT 使用 LLM，这意味着除了 GitHub 和 OpenAI 之外，基本上没有人能收集到这些数据。当 Hiro 在 Copilot 给出建议后点击（或未点击）Tab 键，或者当 Hiro 决定是否复制 ChatGPT 生成的代码时，这就在向这些产品发送信号，告知它们未来应该多做或少做些什么。即使 Hiro 稍后修改了代码，建议生成内容与最终状态之间的差异也可以作为一种信号。

关于如何最好地捕获、结构化和应用这些开发数据以创建更有帮助的 LLM，目前仍有许多未解之谜，但显而易见的是，从像 Hiro 这样的开发者那里收集隐式反馈以驱动开发数据引擎是关键。多亏了个人开发者的辛勤工作，他们的数据可以被用来改进 LLM，从而造福整个团队。

Continue 能够帮助您自动收集这些数据

在 Continue，我们的使命是加速伟大软件的创造。但对每个工程团队来说，“伟大”的含义各不相同。

这就是为什么我们正在构建一个开源的编码自动驾驶工具，让您可以自动收集开发数据。通过这些数据，您可以计算 LLM 的投资回报率。您可以更好地感知到是什么让您的开发人员感到沮丧，并且您可以改进模型来帮助他们克服这些挑战。

我们正在与具有前瞻性的组织合作，建立他们的开发数据引擎。我们首先帮助他们提取、加载和转换数据，以便他们能够洞察开发人员目前如何使用 LLM，并为日后改进 LLM 奠定必要的基础。如果您有兴趣与我们合作，请发送电子邮件至 data@continue.dev。

关于这一点，您可能有很多想法。目前，我们自己的疑问比答案还要多。如果您想与 Continue 社区进一步讨论，请加入我们的 Discord！

如果您喜欢这篇博文，并希望在未来阅读更多关于 DevAI（即在 LLM 帮助下构建软件的社区）的内容，请点击此处加入我们的月度通讯。