GitHub工程师分享开发Copilot所采用的提示词工程 作者 | Sergio De Simone译者 | 明知山策划 | 丁晓昀GitHub 工程师 Albert Ziegler 和 John Berryman 表示，不需要拥有机器学习或生成式 AI 博士学位就可以创建有效的基于 LLM 的应用程序，提示词工程是关键。他们还分享了他们在开发 GitHub Copilot 过程中所积累的经验。 LLM 的崛起为那些希望在应用程序中利用生成式 AI 的从业者创造了一个全新的领域。这个领域被称为提示词工程，专注于如何指导 LLM 产生不属于其预训练部分内容的输出。人们可以通过提示词工程定义包含足够多上下文信息的提示词，让 LLM 产生可能最佳的输出。 上下文信息存在于用户领域，并且应该与任务规范一起被包含在提示词中，而任务规范存在于不确定的文档领域，在那里，LLM 只是一种可以预测下一个标记的预测器。如果这两个领域之间没有被正确映射，例如，没有在提示词中告知响应应该被作为“一个有用的 IT 专家”生成的内容返回，那么返回的响应可能会很一般。 Ziegler 和 Berryman 表示，对于 Copilot 来说，有用的上下文信息可能包括语言、文件路径、光标上方的文本、光标下方的文本、其他文件中的文本，等等。 用户领域和文档领域之间的转换正是提示词工程所覆盖的领域——由于我们已经在 GitHub Copilot 项目上工作了两年多，所以在这个过程中发现了一些模式。总的来说，他们建议的方法是基于一系列步骤的。首先，你需要收集所有相关上下文（也就是上下文收集），可能包含所有的源文件。在大多数情况下，这些上下文信息的量将超出可用的 LLM 窗口，因此你需要通过将其分割成较小不重叠的块。接下来的两个阶段是找到一种自然的方式将上下文信息注入到 LLM 文档中，例如，对于 Copilot 来说就是使用代码注释，并根据其相关性确定要包含的片段的优先级。如果你有多个 LLM 模型可选择，那么另一个阶段是决定使用哪个模型进行推理。最后一步是定义一个停止标准，让 LLM 知道何时完成，例如，当输出换行符时。 实现提示词工程有很多种方法。最近，微软开源了 LMOps 工具包，其中包含了 Promptist（一种用于优化用户文本输入以生成图像的工具）和结构化提示词（一种用于在少量学习提示词中包含更多样本来生成文本的技术）。 尽管我们可以推测 LLM 将发展到不再需要提示词工程的地步，但 OpenAI 工程师 Sherwin Wu 在上一次纽约 QCon 大会的“生产环境中的 LLM”小组讨论会上指出，至少在未来五年内仍然可能需要它。 如果你对 GitHub 在提示词工程方面所采用的方法感兴趣，请不要错过这篇完整的文章，它涵盖了比本文更多的细节内容。 原文链接： https://www.infoq.com/news/2023/07/copilot-prompt-engineering/ 声明：本文为 InfoQ 翻译，未经许可禁止转载。 你也「在看」吗？ ??