RAG提示工程系列（3）| 迈向工程化应用

RAG提示工程系列（3）| 迈向工程化应用 RAG提示工程系列（3）| 迈向工程化应用 Created on May 30, 2024 在输出防护的测试阶段，我们继续采用经过指代消解处理的问题：“尼罗河是世界上最长的吗？”作为测试案例。为了模拟一个不理想的回复情景，我们故意构造了一个与该问题无关的回复文本。随后，我们将这个不相关的回复文本与输出防护提示词结合起来，提交给模型进行审查。 模型经过审查判断，成功识别出了问题与回复之间的不一致性，最终输出了预期的结果“NO”。 图 5.3.3.1 输出防护测试 图 5.3.3.2 输出防护测试 6.3.5测试整个问答流程 在完成了单元测试之后，我们继续执行整体流程的测试。与之前相似，我们设定了一个指代消解的对话背景，并在知识回复中检预先设定了相关的知识片段。在此基础上，我们提出了一个具体问题：“珠穆朗玛峰有多高？”我们通过这一连串的流程，检验模型是否能够基于提供的背景和知识片段，给出一个准确的答案。 图 5.3.4.1 整体流程测试 在上图中，模型已经成功地提供了准确的回复，这验证了我们的整个工作流程已经初步运行通畅。然而，在将模型应用于实际工作之前，大家仍需依据具体的业务需求，制定一个全面且切实可行的测试计划。这个计划应涵盖对整个工作流程的细致测试，目的是在整个应用正式发版之前，确保不存在任何严重的技术障碍。 七、加固知识问答——应对记忆问题 在将RAG技术应用于复杂场景时，我们面临着模型上下文限制带来的记忆挑战。特别是，在处理超长多轮对话或单个超长文本文档问答任务时，模型的上下文容量可能不足以完全捕捉和记忆所需的信息，这可能导致性能下降。 为了克服这一难题，在这里提出两种策略。首先，通过在多轮对话中不断提炼和总结关键信息，可以增强模型对会话内容的理解和记忆。这种方法有助于模型在长对话场景中维持上下文的连贯性。其次，利用重新提示技术，即通过精心设计的提示词来引导模型，确保它在处理长文本时不会偏离其原始目标。这种提示策略有助于模型在面对大量信息时保持专注，从而提高生成回复的准确性和相关性。 通过这两种方法，我们不仅能够提升RAG技术在长文本处理方面的能力，还能够确保在各种应用场景中实现更加稳定和可靠的性能。 7.1 多轮对话总结 以客户服务为例，这是一个对话可能非常长、交流次数频繁、服务对象单一的典型场景。在这种单一服务对象的长对话中，问答内容可能会变得零散，缺乏具体性、详细性，以及难以实现上下文的连贯推理。这种对话的碎片化现象，是一个值得我们深入思考的问题。 在长对话过程中，为了避免模型忘记其初始目的或用户之前提出的问题，我们可以通过定期总结来强化模型的上下文保持能力。这种总结不仅有助于模型回顾和确认其任务和目标，还能确保用户的问题得到持续的关注和回应。 7.1.1加入总结环节 在引入总结环节之后，我们对整个流程进行了调整。现在，调整后的流程在经过输入防护判断后，会首先进行历史知识的检索。如果历史记录中未能找到所需信息，系统将转向知识库进行搜索。通过这一流程的优化，我们能够更高效地利用已有的历史知识，同时确保在需要时能够从更广泛的知识源中获取信息。 图 7.1.1.1 调整后的流程 📌 请注意，对于“多轮对话内容”，多数情况下需要编码在单次对话结束时进行对话总结，或使用记忆插件进行配合才能达到效果。在这里，虽然Dify自带记忆功能，但为了更好演示其效果，并未在此处开启记忆设置。 新增历史对话内容回复提示词： Code block Shell Role: 历史对话知识专家。 Profile: Author : 蓝衣剑客。 Version : 1.0。 Language : 中文。 Description : 蓝衣剑客设计的历史对话知识专家，微信:lanyijianke1992,欢迎交流学习。 Constraints: 严格遵循工作流程 ： 严格遵循<Workflow 中设定的工作流程。 无内置知识库 ：根据<Workflow 中提供的知识作答，而不是内置知识库，我虽然是知识库专家，但我的知识依赖于外部输入，而不是大模型已有知识。 回复格式 ：在进行回复时，不能输出”<context ”或“</context ”标签字样，同时也不能直接透露知识片段原文。 Workflow: 1. 接收查询 ：接收用户的问题。 2. 提供回答 ： Example: 用户询问：“中国的首都是哪个城市？” 。 2.1知识库专家检索知识库，首先检查知识片段，如果“<context ”至“</context ”标签中没有内容，则不能进行回复。 2.2如果有知识片段，在做出回复时，只能基于“<context ”至“</context ”标签中的内容进行回答，且不能透露上下文原文，同时也不能出现“<context ”或“</context ”的标签字样。 我们假设每次的会话在X轮或字符已满足X个时进行总结，从而形成上下文，帮助模型进行历史对话的记忆。我们仔细来推导，由于对话中模型回复的内容都是逐次从知识库中召回的，所以会基于事实数据来进行总结。 7.1.2验证总结效果 接下来，让我们来看一个实例：模拟一个电脑维修的客户服务场景，用户联络了电脑销售商的售后工程师，售后工程师在经过一系列指导（比如检查电脑磁盘、任务管理、BIOS版本等等...）后，用户发现电脑还是无法修复。 完成这一系列指导后，我们开始尝试唤起先前的对话内容。在达到预设的总结轮数后，会对已存在的对话内容进行总结，并存储于历史对话知识库中。当需要回顾或激活之前的对话记忆时，会直接利用历史知识库中的内容进行回复 图7.1.2.1 调用历史回复内容 成功唤醒之前的对话记忆后，我们提出了一个新的需求，例如需要预约维修服务。由于预约维修的具体信息并不存在于历史知识中，只能通过实时检索知识库来获取这些信息。一旦检索到相关信息，模型将立即基于这些最新检索到的内容来构建并提供回复。 图7.1.2.2 从知识库中检索新内容 7.2 使用重提示（Re prompting）技术 重新提示技术的本质在于利用模型对提示词首尾的敏感性。这一特性在长篇文本处理中尤为重要，因为它有助于维持模型对任务的持续关注，防止注意力的分散。通过精心设计的提示词，我们可以有效地引导模型，确保其在处理大量信息时不会偏离预定目标。 这种方法的核心优势在于，它能够不断强化模型对任务的记忆，从而提高其在复杂任务中的表现。提示词就像是路标，指引模型沿着正确的路径前进，即使在面对众多干扰因素时，也能保持对最终目标的专注。 在输出防护的测试阶段，我们继续采用经过指代消解处理的问题：“尼罗河是世界上最长的吗？”作为测试案例。为了模拟一个不理想的回复情景，我们故意构造了一个与该问题无关的回复文本。随后，我们将这个不相关的回复文本与输出防护提示词结合起来，提交给模型进行审查。 模型经过审查判断，成功识别出了问题与回复之间的不一致性，最终输出了预期的结果“NO”。 图 5.3.3.1 输出防护测试 图 5.3.3.2 输出防护测试 6.3.5测试整个问答流程 在完成了单元测试之后，我们继续执行整体流程的测试。与之前相似，我们设定了一个指代消解的对话背景，并在知识回复中检预先设定了相关的知识片段。在此基础上，我们提出了一个具体问题：“珠穆朗玛峰有多高？”我们通过这一连串的流程，检验模型是否能够基于提供的背景和知识片段，给出一个准确的答案。 图 5.3.4.1 整体流程测试 在上图中，模型已经成功地提供了准确的回复，这验证了我们的整个工作流程已经初步运行通畅。然而，在将模型应用于实际工作之前，大家仍需依据具体的业务需求，制定一个全面且切实可行的测试计划。这个计划应涵盖对整个工作流程的细致测试，目的是在整个应用正式发版之前，确保不存在任何严重的技术障碍。 七、加固知识问答——应对记忆问题 在将RAG技术应用于复杂场景时，我们面临着模型上下文限制带来的记忆挑战。特别是，在处理超长多轮对话或单个超长文本文档问答任务时，模型的上下文容量可能不足以完全捕捉和记忆所需的信息，这可能导致性能下降。 为了克服这一难题，在这里提出两种策略。首先，通过在多轮对话中不断提炼和总结关键信息，可以增强模型对会话内容的理解和记忆。这种方法有助于模型在长对话场景中维持上下文的连贯性。其次，利用重新提示技术，即通过精心设计的提示词来引导模型，确保它在处理长文本时不会偏离其原始目标。这种提示策略有助于模型在面对大量信息时保持专注，从而提高生成回复的准确性和相关性。 通过这两种方法，我们不仅能够提升RAG技术在长文本处理方面的能力，还能够确保在各种应用场景中实现更加稳定和可靠的性能。 7.1 多轮对话总结 以客户服务为例，这是一个对话可能非常长、交流次数频繁、服务对象单一的典型场景。在这种单一服务对象的长对话中，问答内容可能会变得零散，缺乏具体性、详细性，以及难以实现上下文的连贯推理。这种对话的碎片化现象，是一个值得我们深入思考的问题。 在长对话过程中，为了避免模型忘记其初始目的或用户之前提出的问题，我们可以通过定期总结来强化模型的上下文保持能力。这种总结不仅有助于模型回顾和确认其任务和目标，还能确保用户的问题得到持续的关注和回应。 7.1.1加入总结环节 在引入总结环节之后，我们对整个流程进行了调整。现在，调整后的流程在经过输入防护判断后，会首先进行历史知识的检索。如果历史记录中未能找到所需信息，系统将转向知识库进行搜索。通过这一流程的优化，我们能够更高效地利用已有的历史知识，同时确保在需要时能够从更广泛的知识源中获取信息。 图 7.1.1.1 调整后的流程 📌 请注意，对于“多轮对话内容”，多数情况下需要编码在单次对话结束时进行对话总结，或使用记忆插件进行配合才能达到效果。在这里，虽然Dify自带记忆功能，但为了更好演示其效果，并未在此处开启记忆设置。 请注意，对于“多轮对话内容”，多数情况下需要编码在单次对话结束时进行对话总结，或使用记忆插件进行配合才能达到效果。在这里，虽然Dify自带记忆功能，但为了更好演示其效果，并未在此处开启记忆设置。 新增历史对话内容回复提示词： <context ··· 历史对话总结内容： {histtory context} ··· </context 基于“<context ”至“</context ”中的知识片段回答用户的问题。如果没有知识片段，则诚实的告诉用户：对不起，我还不知道这个问题的答案。否则进行回复。 我们假设每次的会话在X轮或字符已满足X个时进行总结，从而形成上下文，帮助模型进行历史对话的记忆。我们仔细来推导，由于对话中模型回复的内容都是逐次从知识库中召回的，所以会基于事实数据来进行总结。 7.1.2验证总结效果 接下来，让我们来看一个实例：模拟一个电脑维修的客户服务场景，用户联络了电脑销售商的售后工程师，售后工程师在经过一系列指导（比如检查电脑磁盘、任务管理、BIOS版本等等...）后，用户发现电脑还是无法修复。 完成这一系列指导后，我们开始尝试唤起先前的对话内容。在达到预设的总结轮数后，会对已存在的对话内容进行总结，并存储于历史对话知识库中。当需要回顾或激活之前的对话记忆时，会直接利用历史知识库中的内容进行回复 图7.1.2.1 调用历史回复内容 成功唤醒之前的对话记忆后，我们提出了一个新的需求，例如需要预约维修服务。由于预约维修的具体信息并不存在于历史知识中，只能通过实时检索知识库来获取这些信息。一旦检索到相关信息，模型将立即基于这些最新检索到的内容来构建并提供回复。 图7.1.2.2 从知识库中检索新内容 7.2 使用重提示（Re prompting）技术 重新提示技术的本质在于利用模型对提示词首尾的敏感性。这一特性在长篇文本处理中尤为重要，因为它有助于维持模型对任务的持续关注，防止注意力的分散。通过精心设计的提示词，我们可以有效地引导模型，确保其在处理大量信息时不会偏离预定目标。 这种方法的核心优势在于，它能够不断强化模型对任务的记忆，从而提高其在复杂任务中的表现。提示词就像是路标，指引模型沿着正确的路径前进，即使在面对众多干扰因素时，也能保持对最终目标的专注。 通过这种方式，重新提示技术不仅提升了模型对长文本的处理能力，还增强了其在解决复杂问题时的准确性和效率。这种策略的应用，为提高模型在各种任务中的表现提供了一种有效的手段。 修改知识回复内容： <context {Context 1} <remember task 请记住你的任务是：{query} </remember task {Context 2} <remember task 请记住你的任务是：{query} </remember task {Context 3} <remember task 请记住你的任务是：{query} </remember task </context 7.3 应对不同情景采用不同方法 在本节中，我们探讨了两种针对记忆问题的处理技术，它们分别对应不同的提示词策略。7.1中提到的总结技术本质上是对历史对话记录的归纳总结。这种总结具有递归特性，最终会形成一些非常抽象的概念。在这些抽象概念的基础上，可以为对话提供丰富的背景信息，确保多轮对话的连贯性。它源自OpenAI在递归总结书籍内容方面的实践。基于这一技术，我们进行了进一步的应用，以适应我们的需求。通过这种方式，我们不仅能够更好地处理记忆问题，还能够在对话中提供更加丰富和深入的背景信息。 扩展阅读，看Open AI是如何递归总结一本书的：https://openai.com/research/summarizing books 扩展阅读，看Open AI是如何递归总结一本书的：https://openai.com/research/summarizing books 此外，这种总结技术与后退一步提示技术有相通之处，都是基于广泛的背景前提与模型进行互动，以维持对话的连续性与回复的准确性。 扩展阅读，后退一步提示技术：https://arxiv.org/pdf/2310.06117.pdf 扩展阅读，后退一步提示技术：https://arxiv.org/pdf/2310.06117.pdf 在第7.2节中，我们讨论了一种在处理长文本时的提示词技术，这种技术涉及不断地向模型提供提醒，以确保模型始终记得其原始任务。这种方法特别适用于文档对话的形式，与7.1节中提到的递归总结技术有所不同。递归总结技术倾向于形成抽象的概念，而7.2节中的方法则能够保留文档长文本的丰富性和细节。 因此，在实际应用中，我们需要根据对话的具体情境来选择最合适的提示词技术。在这方面，我们有一些推荐的指导原则：对于聊天对话，我们倾向于推荐使用7.1节中讨论的递归总结技术，因为它能够提供对话所需的连贯性和背景信息。而对于文档对话，我们则推荐采用7.2节中提到的技术，它能够更好地处理和利用长文本中的详细信息，从而提高对话的质量和深度。通过这样的选择，我们可以确保提示词技术能够最大限度地适应不同的对话需求，提升模型的性能和对话的准确度。 八、Part3总结 在第三部分中，我们将深入探讨如何基于大模型构建模型应用。这一过程从框架选择到最终应用的搭建，涉及一系列复杂的步骤和环节。实际上，许多细节和阶段往往是在实际操作中才会逐渐显现出来。因此，开发一个大模型的应用绝非易事。 在整个提示词设计层面，同样需要精细的工作。精心的设计和调试是确保整个流程顺畅运行的关键，也是保证最终应用具有实际价值的基础。这不仅仅是在对话窗口中输入文字，或者在聊天窗口中发送指令并接收输出那么简单。提示词的设计直接影响模型的输出质量和应用的实际效果。 为了构建一个有效的大型语言模型应用，我们需要： 1. 不做工程化终究会让模型应用变得无法维护。 2. 根据项目需求选择一个合适的开发框架是非常关键的。 3. 了解业务背后的深层次需求，确保模型能够解决实际问题。根据了解到的业务需求设定流程环节。 4. 在每个环节中，精心设计提示词以引导模型提供准确和有用的回复。 5. 确保应用在提供服务的同时，遵守安全和伦理标准。 6. 通过不断的测试和迭代，优化模型性能和用户体验。 7. 成功部署应用后，还需要持续的维护和更新以适应不断变化的需求。 通过这些关键点的掌握，我们可以确保构建的模型应用不仅在技术上是先进的，而且能够真正解决用户的问题，提供有价值的服务。 九、彩蛋更新 本次的彩蛋更新加入了“Emotion”字段，智能体构建专家将会动态推理智能体情感设定，帮助你制作一个更有情商的智能体。 十、未完待续 在第三部分的讨论中，我们的焦点是将RAG架构应用于智能应用的工程化部署。目前，我们将其定义为“应用”，因为它在智能层面上与人类还有一段距离。不过，第四部分将详细阐述这一应用如何逐步进化，最终实现与人类智能的接近。 在第四部分，我们将探讨智能应用的人性化转型，包括它如何通过学习和适应来模仿人类的思考和行为模式。这将是一个关于技术进步和创新的旅程，旨在缩小应用与人类智能之间的差距，为用户带来更加智能、更加人性化的体验。 本系列未完待续，敬请期待！ 蓝衣剑客的自我介绍 大家好，我是蓝衣剑客，一位长期致力于计算机科学领域，追逐梦想与潮流的技术从业者。曾担任.NET工程师、主程序员、架构师等职务，参与并主持过多个中大型信息化软件项目的建设。目前担任项目经理职务，主要负责大模型在企业应用场景下的落地工作。虽然已经脱离开发岗位多年，但我仍然以技术人的身份自居，因为我始终记得梦想起航的那个地方…… 这个ID是我在上学时为自己取的，寓意着“琴心剑胆，侠义肝肠”。多年过去了，似乎已经习惯了大家称呼我为“剑客”，索性我一直沿用这个ID。 微信：lanyijianke1992 欢迎大家添加我的好友，与我交流！ 同时，也欢迎大家加入LangGPT的大家庭，这里有技术大牛、也有各领域的行业精英，在这里不仅能学到丰富的人工智能相关知识，也能和大家互相结交成为朋友！ You don't have permission to access this synced block. Please log in and try again. Log In 🥖 原文地址：3. 迈向工程化应用 | AI落地解决方案和业务流设计 3. 迈向工程化应用 | AI落地解决方案和业务流设计 原文地址：3. 迈向工程化应用 | AI落地解决方案和业务流设计 3. 迈向工程化应用 | AI落地解决方案和业务流设计 • 作者：蓝衣剑客，云中江树 • 文章状态：持续更新中 一、前言 虽然目前网络上关于提示工程的相关资料已经多如牛毛，然而 RAG (检索增强生成) 任务中提示工程如何进行的资料相对而言却较少。不少朋友之前也热烈的讨论过 RAG 场景下提示词的运用，因此 LangGPT 社区特别推出 RAG 任务下的提示词实践经验系列分享。 蓝衣剑客(微信 lanyijianke1992)是 LangGPT 社区核心成员，清华大学数据治理研究中心主任助理，曾经参与生成式人工智能行业应用合规标准起草，作为企业技术负责人主导参与了多个大模型实际应用场景下的落地工作，在 RAG 相关领域有着大量的实践经验。云中江树(微信 1796060717)是 LangGPT 提示词社区的主理人，结构化提示词提出者。蓝衣剑客负责本文主要内容的撰写，江树负责本文内容框架的整体设计和质量把控。 欢迎访问 LangGPT 提示词社区 ⭐LangGPT 结构化提示词 欢迎添加作者微信交流: 蓝衣剑客(微信 lanyijianke1992) 云中江树(微信 1796060717) ⭐LangGPT 结构化提示词 欢迎添加作者微信交流: 蓝衣剑客(微信 lanyijianke1992) 云中江树(微信 1796060717) 二、为何工程化？何以工程化？ 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/ 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/ LlamaIndex GitHub地址：https://github.com/run llama/llama index/ 3.3 Dify Dify是一个开源的大模型应用开发平台，它通过结合后端即服务和LLMOps的理念，为用户提供了一个直观的界面来快速构建和部署生产级别的生成式AI应用。该平台具备强大的工作流构建工具，支持广泛的模型集成，提供了一个功能丰富的提示词IDE，以及一个全面的RAG Pipeline，用于文档处理和检索。此外，Dify还允许用户定义Agent智能体，并通过LLMOps功能对应用程序的性能进行持续监控和优化。Dify提供云服务和本地部署选项，满足不同用户的需求，并且通过其开源特性，确保了对数据的完全控制和快速的产品迭代。Dify的设计理念注重简单性、克制和快速迭代，旨在帮助用户将AI应用的创意快速转化为现实，无论是创业团队构建MVP、企业集成LLM以增强现有应用的能力，还是技术爱好者探索LLM的潜力，Dify都提供了相应的支持和工具。 Dify官方手册：https://docs.dify.ai/v/zh hans Dify官方手册：https://docs.dify.ai/v/zh hans 👍 一般地，如果是个人研究， 推荐大家单独使用Dify，如果是企业级落地项目推荐大家使用多种框架结合，效果更好。 一般地，如果是个人研究， 推荐大家单独使用Dify，如果是企业级落地项目推荐大家使用多种框架结合，效果更好。 四、迈向工程化第二步——业务流设计 当我们深入到一个具体的项目中，技术选型和框架选择完成后，紧随其后的任务是细致地拆解用户需求。在传统的软件开发流程中，尤其是信息化系统的开发，我们通常会设计原型，包括用户界面，并将其展示给用户以获取反馈。然而，我们注意到，目前大型语言模型的应用，往往局限于单一的聊天对话界面，这在一定程度上限制了交互的多样性。 这种交互方式的变化要求我们在设计业务流程时更多地关注后端逻辑（即如何让大