RAG提示工程（三）：迈向工程化​

4月8日修改
​
​
​
一、前言​
本篇文章最初发表于 LangGPT 社区，经过再版修订重新发表。文章中融入了 LangGPT 社区主理人云中江树（微信 1796060717）的宝贵见解。​
本系列文章专注于 RAG 提示工程，文章内容非常适合那些渴望了解 RAG 架构或已在该领域有深入研究的读者。请注意，由于每篇文章内容详实，阅读时间可能会比一般公众号文章长。我致力于确保读者在阅读文章后能有所收获，因此每篇文章都是花费大量时间精力研究和编写，期望能帮助到看文章的每一个人。​
二、为何工程化？何以工程化？​
2.1 大模型在实际应用中落地，永远是解决方案优先​
随着大型模型在多个领域的应用日益广泛，我们可以观察到一个共同点：在实际落地的架构中，大型模型通常位于基础层。这一现象表明，在大型模型的实际部署中，并非以模型本身为首要考量，而是更注重模型之上构建的应用。这些应用能够切实解决服务对象面临的实际问题，从而赋予模型真正的价值。​
因此，我们可以得出一个重要结论：在方案的具体实施过程中，我们应优先考虑解决方案，而非仅仅关注模型本身。​
​
2.2 产品形态变了​
根据当前市场状况和之前的分析，我们明白了在企业中真正实施的模型解决方案主要集中在应用层面。这些解决方案利用模型的强大功能，发展出多种“模型应用”。有趣的是，尽管大型模型本质上是一个综合体，人们还是习惯于从逻辑上对其进行分类和定义。我们常说寻找应用场景，实际上是在为大型模型的能力寻找适当的逻辑划分，即明确它们在特定领域或范围内的具体应用方向。因此，我们会针对特定需求设定模型的功能，并进行有目标的开发。​
​
📌
基于大模型的产品（确切来说是大型语言模型），都是“简约但不简单”。​
​
2.3 开发范式变了，开发人员也变了​
开发方式的变化，这种变化是由产品形态的改变所驱动的。我们现在更加集中于模型应用的设计，同时，设计和开发流程、标的也随之发生了变化（这些内容我们将会在下面进行详细介绍）。从管理的角度来看，项目组内的成员构成也相应地发生了变化。​
具体的变化表现在哪些方面呢？由于我们将不断实施这类项目或产品，从定制化的角度来看，提示词的定制化是最明显的。因为每个用户的实际企业环境和应用场景都有所不同，即使是相似的应用场景也可能存在细微的差别，这都需要我们对提示词进行调整。这也解释了为什么需要提示词工程师的职位，从长远来看（哪怕是从当下的工作量和工作时间来看），提示词工程师这一职位是有必要的。尽管编写提示词的门槛相对较低（可以用母语进行编写），但这也意味着对人员素质的要求实际上提高了，因为要求人对语义的理解进一步增强了，有时候还需有全局视角和高情商，这是一个目前非常突出的现象。​
​
2.4 不做工程化，后期难以为继​
从目前的经验来看，团队在实施大型模型项目后往往会发现，真正的挑战并不仅仅出现在项目的初期实施阶段，更多的难点其实在于之后的运营和持续优化阶段。​
这是因为业务环境、市场条件和用户需求都在不断变化（如果你的产品是 toC 方向的话，应该更有体会）。一旦产品进入应用阶段，为了适应这些变化，就需要根据新的业务需求进行调整和优化。此外，随着技术进步和新模型版本的推出，我们还必须考虑如何将新技术融入现有系统，并解决由此带来的各种挑战。​
具体来说，这包括如何将新版本模型与现有提示词系统整合、如何持续提升服务质量、准确性及用户体验等问题。因此，在一个项目真正上线或开始运营后，其实是进入了一个需要长期投入和维护的运营阶段。这个阶段要求我们持续关注并付出努力，以确保项目能够长期稳定地运行并满足用户需求。​
​
在运营阶段，我们需要关注的关键任务和能力主要包括以下几点：​
1.
快速反应能力：能够迅速对模型更新、业务需求变化或市场反馈做出响应。​