输入“/”快速插入内容

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

4月8日修改

一、前言

本篇文章最初发表于 LangGPT 社区，经过再版修订重新发表。文章中融入了 LangGPT 社区主理人云中江树（微信 1796060717）的宝贵见解。​
本系列文章专注于 RAG 提示工程，文章内容非常适合那些渴望了解 RAG 架构或已在该领域有深入研究的读者。请注意，由于每篇文章内容详实，阅读时间可能会比一般公众号文章长。我致力于确保读者在阅读文章后能有所收获，因此每篇文章都是花费大量时间精力研究和编写，期望能帮助到看文章的每一个人。​

二、为何工程化？何以工程化？

2.1 大模型在实际应用中落地，永远是解决方案优先

随着大型模型在多个领域的应用日益广泛，我们可以观察到一个共同点：在实际落地的架构中，大型模型通常位于基础层。这一现象表明，在大型模型的实际部署中，并非以模型本身为首要考量，而是更注重模型之上构建的应用。这些应用能够切实解决服务对象面临的实际问题，从而赋予模型真正的价值。​

因此，我们可以得出一个重要结论：在方案的具体实施过程中，我们应优先考虑解决方案，而非仅仅关注模型本身。​

2.2 产品形态变了

根据当前市场状况和之前的分析，我们明白了在企业中真正实施的模型解决方案主要集中在应用层面。这些解决方案利用模型的强大功能，发展出多种“模型应用”。有趣的是，尽管大型模型本质上是一个综合体，人们还是习惯于从逻辑上对其进行分类和定义。我们常说寻找应用场景，实际上是在为大型模型的能力寻找适当的逻辑划分，即明确它们在特定领域或范围内的具体应用方向。因此，我们会针对特定需求设定模型的功能，并进行有目标的开发。​

📌

基于大模型的产品（确切来说是大型语言模型），都是“简约但不简单”。​

2.3 开发范式变了，开发人员也变了

开发方式的变化，这种变化是由产品形态的改变所驱动的。我们现在更加集中于模型应用的设计，同时，设计和开发流程、标的也随之发生了变化（这些内容我们将会在下面进行详细介绍）。从管理的角度来看，项目组内的成员构成也相应地发生了变化。​

具体的变化表现在哪些方面呢？由于我们将不断实施这类项目或产品，从定制化的角度来看，提示词的定制化是最明显的。因为每个用户的实际企业环境和应用场景都有所不同，即使是相似的应用场景也可能存在细微的差别，这都需要我们对提示词进行调整。这也解释了为什么需要提示词工程师的职位，从长远来看（哪怕是从当下的工作量和工作时间来看），提示词工程师这一职位是有必要的。尽管编写提示词的门槛相对较低（可以用母语进行编写），但这也意味着对人员素质的要求实际上提高了，因为要求人对语义的理解进一步增强了，有时候还需有全局视角和高情商，这是一个目前非常突出的现象。​

2.4 不做工程化，后期难以为继

从目前的经验来看，团队在实施大型模型项目后往往会发现，真正的挑战并不仅仅出现在项目的初期实施阶段，更多的难点其实在于之后的运营和持续优化阶段。​

这是因为业务环境、市场条件和用户需求都在不断变化（如果你的产品是 toC 方向的话，应该更有体会）。一旦产品进入应用阶段，为了适应这些变化，就需要根据新的业务需求进行调整和优化。此外，随着技术进步和新模型版本的推出，我们还必须考虑如何将新技术融入现有系统，并解决由此带来的各种挑战。​

具体来说，这包括如何将新版本模型与现有提示词系统整合、如何持续提升服务质量、准确性及用户体验等问题。因此，在一个项目真正上线或开始运营后，其实是进入了一个需要长期投入和维护的运营阶段。这个阶段要求我们持续关注并付出努力，以确保项目能够长期稳定地运行并满足用户需求。​

在运营阶段，我们需要关注的关键任务和能力主要包括以下几点：​

1.
 快速反应能力：能够迅速对模型更新、业务需求变化或市场反馈做出响应。​

2.
 生命周期管理：确保对智能应用的开发、迭代到退役的整个生命周期进行有效管理。​

3.
 持续扩展与集成：随着业务发展和企业转型，不断扩展应用功能，并能够与其他系统进行集成和对接。​

面对这些要求，在缺乏工程化方法和流程支撑下很难满足上述需求。因此，在大模型项目中尤其重要的是建立一套完善的开发、运维流程和响应机制，以便有效地管理大模型产品的生命周期，并适应快速变化的市场环境。​

❓

因此，我们需要反思：如果不实施工程化管理，我们的项目还能算是成功的吗？​

三、迈向工程化的第一步——RAG 框架的选择

到目前为止，我们一直利用 Prompt Layer 平台对提示词进行验证和迭代工作。然而，在实际的工作场景中，我们并不会局限于仅使用像 Prompt Layer 这样专门针对提示词优化的平台。相反，我们会采用更广泛的工具和框架进行大模型项目的开发。在实际项目中，我们会使用工程化框架，为开发提供必要的支持。​

随着我们向工程化的第一步迈进，我们将逐步转变思路，不再仅仅局限于提示词角度的建设和优化，而是更加从实际项目角度入手去考虑工程化建设。这意味着我们将转变我们要采用更全面的工具和方法，以确保能够满足实际业务需求，提供真正的价值。​

下面，我们就介绍几种常用的 RAG 框架，供大家参考。

3.1 LangChain

LangChain 是一个为简化大模型应用开发而设计的开源框架。它通过提供一套模块化的工具和库，允许开发者轻松地集成和操作多种大模型，从而将更多的精力投入到创造应用的核心价值上。LangChain 的设计注重简化开发流程，支持广泛的模型，并且具备良好的可扩展性，以适应不断变化的业务需求。作为一个得到社区广泛支持的开源项目，LangChain 拥有活跃的贡献者和持续的更新，同时提供了全面的文档和示例代码帮助新用户快速掌握。此外，LangChain 在设计时也充分考虑了应用的安全性和用户数据的隐私保护，是一个多语言支持的灵活框架，适用于各种规模的项目和不同背景的开发者。​

LangChain 官方手册：https://python.langchain.com/docs/get_started/introduction/

3.2 LlamaIndex

LlamaIndex 是一个为构建大型语言模型（LLM）应用而设计的开发框架，它为开发人员提供了一套强大而灵活的工具，以便更有效地理解和处理文本数据。对于已经熟悉 LangChain 的开发者来说，LlamaIndex 将不会是一个陌生的存在。​

LlamaIndex 的核心优势在于其对大型语言模型的深度支持，它允许开发者利用如 GPT-3.5 Turbo 这样的模型来执行多种文本处理任务，包括但不限于文档问答、文章生成和自动翻译等。此外，LlamaIndex 特别提供了构建文档问答系统的功能，使得系统能够自动地从大量文档中检索相关信息并生成答案，这对于需要处理大量知识信息的领域尤其有价值。​

LlamaIndex 还允许对嵌入模型进行微调，以适应特定的任务需求，从而提升了文档问答系统的性能。它支持连接不同类型的数据源，包括结构化、半结构化和非结构化数据，这为应用程序提供了处理和生成答案所需的全面信息。​

此外，LlamaIndex 的设计注重简化开发流程，使得即使是复杂的 NLP 任务也能够通过少量代码实现，而无需深入了解底层的复杂性。这样的设计哲学，不仅降低了开发大型语言模型应用的门槛，而且极大地提升了开发效率和应用性能。​

LlamaIndex GitHub 地址：https://github.com/run-llama/llama_index/

3.3 Dify

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

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