一文搞懂大模型！基础知识、 LLM 应用、 RAG 、 Agent 与未来发展
目录
1 LLM 基础知识
2 LLM 应用
3 LLM 的未来发展方向
LLM 探秘：想要深入了解人工智能界的“新宠”大型语言模型（LLM）吗？本文将带你走进 LLM 的世界，从入门知识到实际应用，全方位解读这个充满魔力的“大模型”。我们将一起揭开 LLM 的神秘面纱，领略其在各个领域的独特魅力。无论你是初学者还是有一定基础的 AI 爱好者，这篇文章都将为你提供宝贵的知识和启发，让你的 AI 之旅更加精彩纷呈！快来加入我们，一起探索 LLM 的奥秘吧！大师兄：当我们提到 LLM 时，你最先想到的是什么？
三金哥：ChatGpt、混元、元宝、copilot、模型训练、RAG、LangChain、智能客服、智能 NPC、AGI、智能体？
大师兄：随着 LLM 的发展，LLM 在我们日常的工作、学习和生活中扮演的角色越来越重要，上面的这些概念你肯定都听说过、了解过以及使用过，那么他们之间是怎样的关系呢。
三金哥：每个都了解那么一点，要是要我把他们之间的关系给完全说清楚，又有那么一点模糊。
大师兄：是的。所以，本着知其然要知其所以然的态度，想要梳理出来一个比较明确的知识图谱，我不仅系统性的学习了一些公司内的和 LLM 相关的文章，还查阅了一些外部资料，并且和 LLM 做了一些深入交流。试着梳理出这篇文章——LLM 的入门全貌：基础、应用与前景。
三金哥：你这个叫法有点奇怪啊，入门还要有个全貌？
大师兄：是啊，LLM 涉及面比较广，我们这篇又是篇科普类的文档，想了半天（大约12小时），觉得还是入门全貌这个标题比较契合。
三金哥：好像听着也有那么一点道理，那我们走着？
大师兄：走着。我们先从 LLM 是什么开始吧。你觉得 LLM 是什么呢？三金哥：从字面意思来讲，LLM 是 Large Language Model 这三个单词的首字母缩写，意为大语言模型。问了 LLM 后，LLM 进一步告诉我：大型语言模型（LLM）是一种基于深度学习技术的自然语言处理工具，能理解和生成文本。通过大量语料库训练，LLM 在翻译、写作、对话等任务中展现出卓越的能力。常见的应用包括自动问答、生成文本、文本摘要等。由于其多模态特性，LLM 还可用于图像和音频处理，为多领域带来创新可能。大师兄：士别三日当刮目相看，三金哥现在对 LLM 的使用已经非常熟练了。三金哥：我们要与时俱进嘛！我记得有句话是这么说的：周期可以对抗，但是时代的潮流不可对抗。能引领潮流是最好的，不能引领潮流，起码也要顺应潮流。大师兄：我们从你的回答中能够看到关于 LLM 是一种基于深度学习技术的自然语言处理（NLP）工具。我之前没有考虑过，但是最近仔细想想，觉得还比较有意思的一个问题：你有考虑过 LLM 和自然语言处理（NLP）工具的关系吗？ 1.2 LLM 与 NLP 的关系 &LLM 的基本特点
三金哥：这个还真有点难到我了。你能用一句我能听得懂的话来总结下 LLM 和 NLP 的关系吗？大师兄：NLP 关注的是对自然语言的理解和处理，而 LLM 则是一种强大的模型范式，用于生成和理解自然语言文本，为各种 NLP 任务提供基础和支持。大师兄：那我们就分别从定义、目标来分别说明下 NLP 和 LLM。- 从定义上：自然语言处理（NLP）是人工智能领域的一个子领域，专注于研究和开发使计算机能够理解、处理、生成自然语言文本的技术和方法。而大型语言模型（LLM）是一类基于深度学习的模型，旨在模拟和生成自然语言文本的模型。
- 从目标上：NLP 的主要目标是让计算机能够像人类一样理解和处理自然语言，包括语言的语法、语义、语用等方面。而 LLM 的主要目标是通过大规模的训练数据来学习自然语言的规律，并能够生成具有语义和语法正确性的文本。
三金哥：这么一说，把LLM叫做自然语言处理工具可能没有那么准确，LLM 更多的是理解和生成文本。不过，从你的回答上，我在思考一个很重要的问题：对于 LLM 来说，生成具有语义和语法正确性的文本是不是还不太够，生成的文本和问题如何对应上的？比如有下面的问答：- 回答：“我认为这个意大利面,就应该拌42号混凝土,因为这个螺丝钉的长度很容易影响到挖掘机的扭矩”
- 单纯从语义和语法正确性貌似没有很大的问题，但是确并没有回答我的问题。
大师兄：你是怎么理解“语义正确”的，上面这句话语法上是没问题的，但从语义角度来看，这段话有些问题：- 意大利面和混凝土：在现实生活中，这两者没有直接联系，意大利面是食品，混凝土是建筑材料，把它们结合在一起明显是不合理的。
- 螺丝钉和扭矩：虽然螺丝钉和扭矩在工程机械上是相关的，但是和意大利面拌混凝土这件事完全是两个不相干的领域。
- 因此，可以说这段话在语法上是正确的，但在语义上却是显得荒谬和不可理解的。虽然这段话在逻辑上没有意义，但在生成语法正确的文本时，只是做到了语法正确（syntax correctness），还需要做到语义合理（semantic plausibility）。
三金哥：哦，明白了，语义正确性是这个意思。那例子改下。- 回答：”我认为 PHP 是最好的编程语言，不接受反驳“
大师兄：这段对话从语法和语义上都是正确的，但是回答完全偏离了问题本身。一个理想的 LLM 模型除了语法和语义正确外，还应该具备的能力是：上下文匹配以及一致性。展开来说，就是回答要能准确对应提问的内容和主题并且回答应该与问题保持一致，不发生语义偏离或者逻辑断裂。
三金哥：你的解释非常的有道理，不过我还是有个疑问。就还是拿上面的问题来举例。
大师兄：非常好的例子。上面的回答除了语法和语义的正确性外，上下文匹配以及一致性也是没有问题的，但是这个回答有个致命的错误：和事实不符。众所周知：2022年 NBA 总冠军是金州勇士队！！！虽然2024年 NBA 总冠军是波士顿凯尔特人队，虽然2021年金州勇士队没有进季后赛，但是2022年 NBA 总冠军是金州勇士队。
大师兄：不好意思，上头了。从上面的例子我们也可以看出，一个 LLM 模型应该具备的必不可少的优秀品质是：确保信息的准确性。
三金哥：那么问题来了，LLM 模型是怎么保证回答的准确性的呢？
大师兄：好问题啊，三金哥你这么快就直指LLM的核心了。总结来说，LLM 通过下面几点来保证回答的正确性：数据训练、持续学习、上下文理解、多模态输入、人工审核、领域适应性。这里面每点展开都能讲一节课了，鉴于读者没付费，我就先不展开了。
三金哥：借用丞相一句台词：“从未见过如此厚颜无耻之人！”
大师兄：被你的意面拌混凝土给拉跑偏了，我们还是说回 LLM 的发展历程啊。如果说，在 LLM 的发展过程中有哪些重要的里程碑事件的话，2017年 Vaswani 等人提出了 Transformer 架构绝对是能算得上之一。
大师兄：那你听说过，GPT（Generative Pretrained Transformer）和 BERT（Bidirectional Encoder Representations from Transformers）吗？
大师兄：这两个词中的 T 就是 Transformer 架构。Transformer 架构是一种基于自注意力机制的神经网络结构，它完全颠覆了之前以循环神经网络（RNN）为主导的序列建模范式。Transformer 架构的出现，实现了并行计算和高效的上下文捕获，极大地提高了自然语言处理的性能。可以说，先有 Transformer，后有 GPT 以及 BERT。
三金哥：然后下一个里程碑事件是 ChatGpt 的发布了吗？
大师兄：是的，ChatGPT 是 GPT-3.5 的微调版本，本质上是一个通用聊天机器人。在2022年11月推出，推出后仅仅两个月，就达到月活过亿。怎么形容 ChatGpt 的发布呢，我觉得“横空出世”这个词比较合适。
三金哥：没错，到现在甚至 ChatGpt 在一定程度上都快成了 LLM 的代名词了。大师兄，我了解到：GPT3 在训练时使用了175B的参数。这是一个什么概念，怎么来理解这 175B 个参数对模型训练的影响。
大师兄：这里的 B 不是 Byte，你是知道的吧。
大师兄：这里的 B 是 Billion 的缩写，175B就是175亿个参数。参数数量，简单来说，就是模型在学习时用来调整自身以适应数据的那部分“旋钮”。想象一下，每个参数就像是一个可以微调的设置，模型通过调整这些参数来更好地理解和生成语言。
当我们说一个模型有1750亿个参数时，这意味着模型内部有1750亿个这样的旋钮。这个数字越大，通常意味着模型的表示能力越强，因为它可以捕捉到更复杂的数据模式。但同时，这也意味着模型需要更多的数据和计算资源来训练。
不过，要注意的是，参数多并不总是好事。如果参数过多，而训练数据不足，模型可能会过拟合，也就是说它在训练数据上表现得很好，但在未见过的数据上就不怎么样了。所以，参数数量和训练数据的平衡非常重要。
三金哥：那使用175B个参数进行训练需要多少资源，要训练多久？
大师兄：好问题，我去查了下资料，可能没那么精确，但是可以了解到一个量级：使用1000张 NVIDIA 80GB A100 GPU（理论算力是 312 TFLOPS）显卡需要22天，花费81.6万美刀才能训练完（如有更精确的数字，欢迎指正）。
三金哥：好家伙，这么贵的啊。所以现在 ChatGpt 的 token 才会这么贵的吗？
大师兄：ChatGpt 的 token 贵的原因除了训练模型比较耗钱外，我们向LLM发起请求时，每个请求都会在 LLM 的内部发起比较复杂的运算，这些运算对硬件的要求也很高，所以每次发起请求时都有不少的运行时成本。另外，模型的维护和优化的成本也比较高。最后，我们要考虑到 LLM 商用模型不是在做慈善，是为了要盈利的。我浅显的经济学知识告诉我 OpenAI 的 ChatGpt 模型虽说远不是垄断企业，但是也绝对不是竞争市场企业，可以大致的把 OpenAI 看成是寡头企业，再考虑到当前 ChatGpt 的良好表现，贵一些还是有贵一些的道理。不过我觉得随着我国国内 LLM 的发展，ChatGpt 是一定会降价的。你听说过航母阻拦索的故事吗？
大师兄：当时兔子航母事业刚起步，航母舰载机在着舰时要使用质量可靠的阻拦索。当时有这种技术的只有大毛和鹰酱两家，大毛死活不卖。经过几轮谈判鹰酱倒是同意卖给兔子，只是需要1000万美元1根，这个阻拦索经过几十到上百次就要进行更换，每天战斗和训练需要上亿的成本，然而航母形成战斗力就必须要从鹰酱这里买。后来兔子面向全国进行招标，发现兔子自己就能造航母阻拦索，并且鹰酱的阻拦索也是从兔子这里进口的。鹰酱从兔子这里进口的阻拦索的价格是40万美元一根，转手卖给美军军队150万美元1根。类似的事情还有很多，很多产品在兔子具有量产能力前，价格都贵的离谱，一旦兔子实现技术突破能进行量产后，量产的价格就能打到骨折。其实讲这个故事想说明的是，打不死我们的终将使我们更强大。
三金哥：吾辈当自强。期待混元早日能够达到 GPT 的效果，这样我们通过 LLM 助力我们的工作就能更进一步了，毕竟使用 GPT 模型还是有很多限制，除了比较贵之外，我们还要考虑敏感数据泄露的风险。
大师兄：没错，安全是第一位的，我们在使用 GPT 时一定要注意信息安全。其实如果条件允许的话，我们可以考虑使用离线模型来助力我们的工作。
三金哥：你是说自己部署 LLM 模型吗？离线模型能达到在线模型的效果吗？运行离线模型需要什么样的硬件资源？
大师兄：相比于在线模型，除了延迟比较小、资源消耗比较少之外，离线模型最大的特点是比较安全，不用把请求发给不受控制的 LLM。一般来说，在 Mac Book M3 上能跑的模型包括：Tiny-BERT、GPT-NEO 等模型，这些模型的参数从几百万到几千万不等。离线模型的部署方案比较成熟，每个离线模型的部署都有可以参考的文档，这里就不重点展开了。其实，除了这种离线模型外，鹅厂还为我们提供了更安全、功能更强大的在线模型的平台——混元一站式平台。台如其名，在这个平台上，我们可以进行数据管理、模型训练、模型调试、模型部署已经模型评测等工作。一般来说，根据业务需求可以使用一些通用或者某些垂域的模型进行微调训练，再将训练后的模型进行部署。这种方式进行训练部署的模型兼具了高安全性和高能力的特点。
三金哥：鹅厂内部的学习资源真的是太丰富了。除了你刚才提到的离线模型和自己训练以及部署模型外，我了解到现在也有很多的本地知识库，你能介绍下吗？
大师兄：我觉得你提的问题非常的好，不过我并不打算现在就来介绍本地知识库。我们这次的目的是为了要系统性的介绍下 LLM 相关的基础以及应用。关于 LLM 的基础知识，我们前面已经基本把 LLM 是什么，LLM 应该具备哪些特性，LLM 的主要发展历史给讲清楚了，又介绍了什么是在线 LLM 模型，什么是离线 LLM 模型。接下来你想了解的是本地知识库，这其实可以归属为 LLM 的应用层面的话题，在聊这个话题之前，我们先来梳理下在应用层面 LLM 有哪些典型的能力和应用。
三金哥：据我说知，LLM 具备非常强大的文本处理能力，展开来说，包括文本的摘要、推理、转换以及扩充的能力。
大师兄：你说的不错，不过你说的只是 LLM 应用中很小的一部分（我总结的可能也不合理、全面，欢迎指正）。在我整理的思路中，将LLM的应用可以被看成两种主要的应用，一种我定义为基础应用，一种定义为了工作流的应用。其中基础的应用在我看来基本都可以归纳为：问答系统，即一个向“无所不知”的LLM提问，由LLM来解答并给出结果的一个系统。三金哥：你别说，仔细想想，上图中的创作与生成、多模态、文本处理、数据分析与观察这些都可以通过问答的形式来与 LLM 进行交互。
大师兄：没错。从交互形式来看，问答系统有 API、web 页面对话、app 交互、智能客服和 IDE 插件等类型。在开篇提到的混元就有 api、web 页面对话和 app 交互这三种方式，其中混元的 APP 版本就是元宝。其实现在国内各个公司的 LLM 都有 api、web 页面对话和 app 交互这几种方式。从实现路径上看，我这里想跟大家讨论的主要是知识库系统的构建和提示词工程这两点。
大师兄：提示词工程，也称为 Prompt Engineering，是一种致力于优化和提高大型语言模型（LLM）输出质量的技术和方法。它主要关注如何设计、构造和优化提示词（Prompt），以引导 LLM 生成更准确、更有用、更符合用户需求的文本。可以说，掌握了提示词工程就掌握了打开 LLM 知识大门的钥匙。
大师兄：在鹅厂大家关于提示词工程的理论知识以及实践非常的丰富了。在看了大家的实践之后，总结了一些提示词工程的技巧：
编写清晰而具体的提示：这是确保 LLM 能够准确理解用户需求并作出相应回应的基础。清晰的提示应该明确表达用户想要 LLM 做什么，提供足够的上下文信息，并尽可能具体地描述期望的输出结果。例如，通过使用分隔符来清晰地表示输入的不同部分，要求结构化的输出，以及要求模型检查是否满足特定条件等。一个小 tips：在和 LLM 交互时，要尽量的明确【做什么】，并且尽量避免【不要做】什么，这样能有助于减少 LLM 的幻觉。
给模型思考的时间：尽管 LLM 具有强大的处理能力，但在处理复杂任务时，给予模型一定的时间来思考和生成更准确的回应往往是有益的。之前参加公司内部的一个培训，老师有提到过：LLM 实际上就是在做文字接龙，我们要做的是降低我们不想要的词的概率，同时提高我们想要的词的概率。我们通过描述，生成结果的过程，即通过指定完成任务所需的步骤来提高 LLM 输出结果的可用性。
控制输出结果的长度、格式和内容：根据用户需求，指定输出的词数、字符数、句子数等，以及提取特定的细节，格式化输出为 HTML 等。另外，可以让 LLM 按照指定的格式进行输出，比如：请你用“它通过【什么方法】，解决了【什么具体的问题】，类似【通俗易懂的比喻】”的格式来解释上面的全部技术名词实体，注意问题要具体。
通过给 LLM 模型参考，解决 LLM 的幻觉，以提高输出结果的正确性：适当的给模型一些参考，也就是通常所属的 one-shot 或者 few-shots，让 LLM 知道输入和输出之间的对应关系。
让 LLM 进行自检自查：由于各种原因，特别是在和 LLM 交互的步骤比较多，提示词比较长的情况下 LLM 的回答有可能是错误的，这时一个可选的选项是在适当的步骤让 LLM 进行自查，自己确定下给出的回答是否正确，是否满足了我们的诉求。类似的方法还有让 LLM 对自己的回答评分，直到回答的结果 LLM 自己认为可以达到满意的分数为止。
设定 LLM 的角色：另外一个非常适用的方法是为 LLM 设定角色，一般来说，在设定角色时可以设定 LLM 的专业领域，回答问题的风格、语气、模版、格式等。一个设定好的格式能让 LLM 回答的内容快速的作为后续操作的输入。比如可以让 LLM 帮忙生成格式化的测试用例，然后快速的把这些测试用例导入到智研平台。
尊重 LLM：在听以为智者的分享时，曾提到过如何与 LLM 进行交互。除了前面提到的要提供 LLM 足够的信息外，智者曾给出建议：要尊重 LLM，要把 LLM 想象成一个和你进行合作的工作伙伴，我们平时怎么和一起协作的伙伴怎么沟通交流，就要怎么和 LLM 一起沟通，好好说话，把话讲明白。尊重也是生产力。
- I 代表 Input（输入），指的是提供给 LLM 的初始信息或背景。
- C 代表 Context（上下文），强调在对话或任务中保持连贯性的重要性。
- I 代表 Instructions（指令），即明确告诉 LLM 你希望它执行什么操作或生成什么内容。
- O 代表 Output（输出），是对 LLM 生成的结果进行评估和反馈的过程。
ICIO 框架鼓励在输入时提供充分的信息，确保上下文的连贯性，给出清晰的指令，并对输出结果进行细致的评估和调整。
- B 代表 Background（背景），指为任务提供必要的背景信息。
- R 代表 Response（响应），即 LLM 生成的回应。
- O 代表 Objective（目标），明确任务的预期目标。
- K 代表 Knowledge（知识），强调 LLM 在特定领域内的知识储备。
- E 代表 Evaluation（评估），对 LLM 的响应进行评估，并根据评估结果进行调整。
BROKE 框架注重从宏观角度识别并优化提示词中的关键要素，以提高 LLM 在特定任务和领域中的表现。
- C 代表 Clarity（清晰度），确保提示词表达清晰，无歧义。
- R 代表 Relevance（相关性），强调提示词与任务目标之间的关联性。
- I 代表 Interactivity（交互性），鼓励与 LLM 进行多轮交互以优化结果。
- S 代表 Specificity（具体性），要求提示词具体明确，避免模糊性。
- P 代表 Precision（精确性），追求 LLM 生成结果的精确度和准确性。
- I 代表 Involvement（参与度），指用户应积极参与到与 LLM 的交互过程中。
- E 代表 Effectiveness（有效性），最终目标是确保 LLM 能够有效生成满足用户需求的文本。
CRISPIE 框架从多个维度出发，提供了一套全面的准则来评估和改进提示词的设计，从而提升 LLM 的交互质量和生成效果。
这些框架都是为了帮助我们更好地理解和利用 LLM 的能力，通过精心设计的提示词来引导模型生成更加准确、有用和符合用户期望的文本。在实际应用中，我们可以根据需要灵活选择或结合这些框架的原则来优化我们的提示词设计。
告诉 LLM 方法论：另一个比较有效的建议是，在和 LLM 交互时，可以授之以渔，告诉他如何完成一个任务所需要的方法论，或者告诉他几个可选的方法论，让 LLM 自己去分析当前问题适合使用哪些方法论。
上面是自己使用过程中以及从公司内的分享、km 文章中总结的几个要点，有很多非常专业的关于提示词工程的文章，受限于文章篇幅和整体思路，以及尊重原创知识产权，这里并没有把所有的内容罗列在这里，大家把这个作为一个参考，详细内容可以到文后的参考文章仔细阅读。
在实际使用的过程中有时只使用其中几个就足以解决我们相对比较简单的问题了。当我们遇到较复杂的问题时，就需要适当的使用上面的一些方法的组合了，这个需要大家发动智慧去探索。
三金哥：你这些建议都是很好的，但是在实施的过程中，可能还是没那么容易掌握，有没有什么办法能让我一键生成很好的提示词呢。
大师兄：这个可以有，就是工具应用稍微麻烦一点，我这里提一些工具，你要是感兴趣的话可以自己去查一查，从查阅的资料来看，这些工具应该还是有效果的，比如：
- PromptPerfect：这是一个专注于提升 LLM 交互体验的工具，它提供了一系列的模板和策略，帮助用户根据不同的任务需求定制化提示词。
- Prompt Studio：这个工具集成了多种分析工具，可以对 LLM 的响应进行深入分析，并据此调整提示词的表述，以获得更精准的输出。
- LLM Optimizer：它通过算法自动优化提示词，减少手动调整的负担。用户只需输入原始提示词和任务目标，工具就能自动生成优化后的提示词。
- Prompt Tuner：这个工具允许用户对 LLM 的输出进行详细的反馈，然后根据这些反馈微调提示词，以实现更有效的交互。
这些工具各有特色，可以根据你的具体需求和偏好来选择使用。
三金哥：没想到，提示词工程有这么多的门道。我发现，大家另外一个实践比较多的方向是本地知识库的构建。我们现在是不是可以展开说一说本地知识库的构建了。大师兄：念念不忘必有回响啊，是时候来个 call back 了。首先，我们要考虑下什么场景比较适合使用本地知识库。当你需要针对特定领域的知识进行问答，而且希望得到的答案具有较高的准确性和专业性时，使用本地知识库会比较适合。而混元首页上是这么描述的：有效解决事实性、时效性问题，提升内容生成效果。比如，你是某个行业的专家，你需要快速获取该领域内的专业信息或解决具体问题时，建立一个包含了大量相关领域资料的本地知识库，可以显著提升你获取信息和解决问题的效率。此外，对于企业内部的知识管理和员工培训，本地知识库也是一个很好的选择，因为它可以确保信息的准确性和安全性，同时方便团队成员共享和学习。其次，我们要回答的问题是，我们要如何构建本地知识库呢。要想回答这个问题，还是要先考虑下，三金哥，在你看来，什么是本地知识库？三金哥：本地知识库嘛，不就是本地的知识嘛。本地的各种 iwiki、在线文档、本地的文档，这些是不是都可以理解为本地知识库。大师兄：没错，这些确实都是本地知识，并且这些知识是构建本地知识库的很重要的一个组成部分。试想这样的一个场景，我在一个文档里定义了一次篮球球赛的秩序，我们假设这个文档的名字叫《篮球联赛秩序册》，这里面规定了，在各种情况下的晋级规则，如果我们把这个文档的相关知识灌输给 LLM，那我们就可以向LLM去提问关于各种情况下，哪个队伍可以晋级了。现在越来越多的AI产品已经开始支持以文件的形式进行输入，让文件作为一个小型的知识库。其实维护一个低成本的知识库的方式就是 iwiki，因为 iwiki 满足了几个特点：权限管理、方便协作、方便获取。一个典型的应用场景是，需要使用 iwiki 上的内容作为支持库是，把 iwiki 文档导出，再把导出的文件提供给 LLM，让 LLM 根据文档来回答问题。三金哥：这是一个成本很低，很好上手的一个本地知识库的模型。那如果我们的本地知识的量级比较大，不适合在文档中存储，还有什么好的方式来构建本地知识库吗？大师兄：这种情况下，比较推荐使用 RAG 以及 LangChain 来构建自己的知识库。RAG（检索增强生成）是一种先进的自然语言处理技术，它通过结合信息检索系统的精确性和语言模型的强大生成能力，为基于自然语言的任务提供了更为灵活和精准的解决方案。
三金哥：RAG 和 LangChain 真是如雷贯耳啊，最近在公司内部听到看到的关于 RAG 和 LangChain 的可是不少啊，大家都讲了这么多了，大师兄你还说这一块吗？
大师兄：那还是要说一说的，就像你说的，大家的实践那么多了，说明基于 RAG 和 LangChain 的方案是切实可行的。我们这篇文章的目的又是给大家一个入门的全貌，那肯定要把最具代表性的 RAG 和 LangChain 分享给大家了。
大师兄：下面将从 RAG 技术定义以及 RAG 技术优势这两个方面来介绍 RAG：
RAG技术定义
RAG 技术指的是对大型语言模型输出进行优化，使其能够在生成响应之前引用训练数据来源之外的权威知识库。这种技术通过动态接入外部资源，使LLM得以即时访问和利用广泛且不断更新的知识库，进而提升模型在问答、对话、文本生成等任务中的表现。
三金哥：从定义来看，RAG 非常的契合本地知识库构建啊。
大师兄：不是一家人不踹一家门么。我们继续来看 RAG 的技术优势。
RAG技术优势
外部知识的利用 RAG 模型可以有效地利用外部知识库，提供更深入、准确且有价值的答案。
数据更新及时性 具备检索库的更新机制，实现知识的即时更新，无需重新训练模型。
答复具有解释性 答案直接来自检索库，具有很强的可解释性，减少大模型的幻觉。
高度定制能力 可以根据特定领域的知识库和prompt进行定制，快速具备该领域的能力。
安全和隐私管理 通过限制知识库的权限来实现安全控制，确保敏感信息不被泄露。
减少训练成本 在数据上具有很强的可拓展性，可以将大量数据直接更新到知识库，无需重新训练模型。
三金哥：看了 RAG 技术定义、技术优势之后，又坚定了要用好 RAG 的信心啊，我已经迫不及待的想要看看使用 RAG 如何构造本地知识库了。
使用 RAG 构建本地知识库的步骤主要包括准备文本资料、文本分块、嵌入以及存储到向量数据库，然后通过检索增强生成（RAG）链来生成回答。以下是详细的步骤和注意事项：
构建本地知识库的步骤
准备文本资料：收集和整理相关领域的文本资料，确保资料的质量和完整性。
文本分块：由于 LLM 的上下文窗口有限，需要将文本资料分割成较小的块，以便 LLM 能够处理。
嵌入以及存储块到向量数据库：使用向量嵌入技术（如Ollama Embeddings）为每个文本块生成向量，并将这些向量存储到向量数据库中，如 Weaviate。
检索 & 增强：利用向量数据库作为检索器，通过用户查询和嵌入向量之间的语义相似性获取数据，然后使用一个固定的聊天模板将检索到的上下文与用户的问题结合起来，发送给 LLM 进行回答。
生成：LLM 根据接收到的上下文和问题生成回答，RAG 链将检索器、聊天模板以及 LLM 组合起来，完成这一过程。
注意事项和优化建议
在构建知识库时，注意文本的质量和多样性，确保覆盖广泛的主题和观点。
在文本分块时，合理设置块的大小和重叠部分，以便 LLM 能够有效地处理。
在嵌入和存储到向量数据库时，考虑使用不同的嵌入模型和数据库技术，以优化检索性能。
在检索增强生成阶段，尝试不同的聊天模板和 LLM 模型，以获得最佳的生成效果。
三金哥：在上面你提到了使用 RAG 构建本地知识库的步骤，其中使用向量嵌入技术为每个文本生成向量的 Embedding 技术以及检索时使用的的向量检索看起来是比较核心的操作，我们有什么办法能将 RAG 落地吗？
2.3.3 使用 LangChain 落地 RAG
大师兄：将 RAG 落地的一个比较成熟的做法是使用 LangChain。
大师兄：简单用一句话来解释：LangChain是一个开源框架，它连接了外部计算和数据源与 LLM（大型语言模型），使得 LLM 可以实时访问外部数据。使用 LangChain 将 RAG（检索增强生成）落地是一个涉及多个组件和步骤的过程。主要的步骤包括：安装和配置 LangChain、准备知识库、编写 LangChain 脚本、集成 LLM 模型、测试和调试以及部署和监控。通过这些步骤，可以将 RAG 技术通过 LangChain 框架落地到实际应用中，从而提升 LLM 在特定领域知识问答中的准确性和专业性。
三金哥：上面的这些步骤还是有些复杂，我们想要真实落地的话，有什么比较快捷的方式吗？
大师兄：非常好的问题。混元最近发布了“混元 Embedding 所以服务的高效革新”这篇文章。文章中提到：混元不仅升级 Embedding 索引服务，还支持用户通过自定义编排和 Agent 表单引导功能，将知识检索与大模型相结合，让用户可轻松定制大模型交互流程，无需复杂编程，迅速构建智能应用，助力大模型充分利用本地知识库，优化智能问答体验。怎么样，是不是已经心动了，快去试试吧。
三金哥：经过你这么一解释，基本把如何构造本地知识库给讲清楚了，在应用层面，除了提示词工程、本地知识库构建之外，还有其他的比较重要的应用吗？
大师兄：重要不重要不知道，工作流绝对是最近热度最高的应用了。
三金哥：我们能先从概念入手吗？先分别介绍下工作流中涉及到的一些概念，再来说一说这两者的关系，以及这两者在实际工作中要如何使用。
大师兄：那我们就先看看 Agent 是什么。在开篇时，让你给出一些和 LLM 相关的关键词，你不是提到了智能体么，其实 Agent 就是智能体呀。不知道你的感受是什么，给我最直观的感受是，最近大家都或多或少的在使用 Agent，现在很多的 AI 相关的实践也都离不开 Agent，但是 km 上关于 Agent 的文章还是比较少。
三金哥：我觉得可能的原因是大家对于 Agent 的应用都还在摸索中，我估计最近关于 Agent 的文章会逐渐多起来了。
大师兄：我也是这么认为的。让我们回到 Agent 的定义：LLM 中的 Agent 是基于大型语言模型（LLM）的智能体，能够自主理解、规划决策并执行复杂任务。它们通过日常语言与用户交流，并根据用户的需求执行相应的任务，展现出更高的灵活性和效率。这些 Agent 可以基于 LLM 的推理和生成能力来构建，它们不仅能够理解和生成文本，还能根据上下文进行规划、学习和适应。
三金哥：那么我们该如何上手去开始使用 Agent 呢。
大师兄：目前很多 AI 工具，包括鹅厂自己的混元、元宝上都已经开始支持智能体（Agent）了。这些平台大同小异，从使用步骤上基本都可以概括为以下的过程：
- 确定目标和场景：首先明确你希望 Agent 在什么场景下执行什么任务。
- 选择合适的 LLM 模型：根据任务的复杂性和性能要求，选择一个合适的 LLM 作为 Agent 的基础。
- 设计 Agent 的行为逻辑：定义 Agent 如何感知输入、做出决策和执行动作的逻辑流程。
- 集成外部资源和工具：如果需要，将 Agent 与外部数据库、API 或其他工具集成，以扩展其功能和能力。
- 训练和优化：在实际数据上训练 Agent，并根据反馈进行迭代优化，以提高其性能和准确性。
通过这些步骤，你可以创建一个功能强大的 Agent，利用 LLM 的能力来解决各种实际问题。
三金哥：Agent 怎么看起来和提示词有这么多的相似之处呀。针对于 Agent 和提示词模板，我们都需要上面<如何使用 Agent>中的各个步骤来达成一个高可用的 Agent。
大师兄：是这样的，其实我们之前的一些实践的过程，也基本都是先从写提示词工程入手，把提示词调试好了之后，基本可以无缝从提示词模板切换到Agent的定义。
三金哥：那 Agent 我们基本了解清楚了，工作流又是什么呀？
大师兄：初步体验了下混元上的“自定义工作流程编排”（工作流的内部叫法），我理解工作流就像搭积木一样，只不过这里是搭一个逻辑流程的积木。首先，得选择好需要的各种插件组件和模型组件，这些就像是搭积木的基本块。然后，通过 DAG 图把它们连接起来，就像积木之间的连接一样。
接下来，要定义好每个组件的输入输出，这就像是确定每块积木的接口，确保它们能够正确地拼接在一起。然后，需要构建和运行这个 DAG 图，这个过程就像是按照设计图来搭建积木城堡。
当然，除了这些基本的步骤，还有一些高级的功能，比如可以通过逻辑分流节点来决定流程的不同走向，这就像是给积木城堡设计不同的通道。最后，当完成了所有的设计和配置，就可以发布设计好的应用了，这样其他人就可以通过 API 来调用你的流程编排了。
三金哥：有点没明白，你说的这个工作流怎么看起来和 Agent 没有什么关系呢？
大师兄：你可以把上面提到的各个组件理解为一个 Agent，在实际编排的过程中，可以自定义 Prompt Template，如果你对我们前文提到的提示词模板和Agent 的关系还有印象的话，那就可以基本理解：这里的 Prompt Template 可以大致的被看做一个 Agent。
三金哥：你这么一说，我就理解了Agent 和工作流的关系了。那现在 Agent Workflow 的应用现状如何？
大师兄：据我所知，各大科技公司如字节跳动的豆包扣子、腾讯的混元等，均提供了支持工作流的平台和工具。这些平台通过提供易于使用的界面和丰富的 API 接口，降低了开发者构建和管理 Agent 的门槛。
Agentic Workflow 和工作流的关系
三金哥：除了工作流之外，我还听说了 Agentic Workflow 这个名词，工作流（Agent Workflow）和 Agentic Workflow 是一个事情吗？
大师兄：我理解，这俩不完全是一回事。如果我说的不对，欢迎大家指正。我先大致的说下我对工作流和 Agentic Workflow 的关系的理解：
前面我们已经介绍了工作流，工作流基本可以被理解为：把 Agent 看做积木的组件，通过这些组件来拼搭积木的过程。而 Agentic Workflow 这个概念是在今年的 4 月初，吴恩达老师在美国红杉做了一场演讲，提出了 Agentic Workflow 的概念，并介绍了 4 种主要的 Agentic Workflow 设计模式。这里谈到的几个概念，对于我们理解 LLM 的应用比较重要，且这几种设计模式可能是未来 LLM 应用的方向。
Agentic Workflow 主要包括以下几种设计模式：
- Reflection（反思）：一个让 AI Agent 通过自我审视和迭代来提高输出质量的过程。这样的机制不仅能让 Agent 更加精准地完成任务，还能让它从错误中学习，不断优化自己的表现。
- Tool Use（工具）：LLM 可以生成代码、调用 API 等工具进行操作。例如，Kimi Chat使用网页搜索工具来检索相关内容，并基于检索结果进行总结分析，最后给出结论。
- Planning（规划）：让 Agent 自行规划任务执行的工作流路径，面向于简单的或一些线性流程的运行。这包括子目标分解、反思与改进，将大型任务分解为较小可管理的子目标处理复杂的任务。
- Multiagent Collaboration（多智能体协同）：多个 Agent 扮演不同角色合作完成任务。例如，通过开源项目 ChatDev，一个大语言模型可以扮演公司 CEO、产品经理、设计师、代码工程师或测试人员等不同角色，共同开发一个应用或复杂程序。
三金哥：使用工具和多智能体协同，这两个光是看概念，都能让人产生无限遐想啊。那 Agentic Workflow 和 Agent 之间又是什么关系呢，知道这两者之间的关系，我应该就更能理解 Agentic Workflow 了。
大师兄：好问题。Agents 就像是能够独立行动的自主系统，它们可以自己完成任务，做出决策，甚至与其他系统或用户互动。而 Agentic Workflow 则是这些 Agents 行动的一种方式，它强调的是通过迭代和互动的方式来提升 AI 的表现。
想象一下，Agents 是一群小侦探，而 Agentic Workflow 就是他们解决案件的方法。小侦探们（Agents）各自有自己的专长，可以独立侦查（执行任务），但他们也可以合作（共享目标和决策），一起解决更复杂的案件。而 Agentic Workflow 就是这个团队合作的框架，它让小侦探们能够反思自己的侦查方法（自我反思），制定计划（规划），并且相互协作（多智能体协同）。
所以，Agents 是执行任务的实体，而 Agentic Workflow 是指导这些实体如何更有效地工作的过程。两者结合起来，就能够创造出更加强大和灵活的人工智能解决方案。
三金哥：我发现关于Agent和工作流的很多说法，你都使用了比喻呀，是不是直接进行说明不大好解释呢。
大师兄：是有一点。这些概念相对比较新，我们的应用又比较少，最好的能说明问题的方式可能就是比喻了。
三金哥：看来我们对于工作流的应用和探索还不够，不知道现在有哪些工作流的成熟的应用。
大师兄：这个你真把我给问到了。这个概念相对比较新，目前我还没看到比较好的应用，后面如果我了解到成功的应用，再和大家分享吧。
三金哥：那也只能这样了吧。我感觉后面这块应该是LLM应用的一个重点方向。你是怎么看待 LLM 的未来应用方向的？
大师兄：你这个问题问的有点太大了，以我浅薄的知识积累，很难回答好这个问题。
三金哥：我一直以为你没有自知之明呢，哈哈
大师兄：我只能试着回答一点。以 LLM 现在具备的能力，越来越多的垂域知识问答系统将会被构建出来，在各自的垂域中大家会逐渐探索利用 LLM 现有的能力去做可落地的提效方案，另外工作流可能会是一个不错的突破口，毕竟多个 Agent 按照一定的套路进行交互，还是让我们比较有想象空间的。
再有，随着 LLM 的发展，我们期望 LLM 能够具有更强大的能力，特别是多模态的能力，当 LLM 具备多模态能力之后，围绕着 LLM 多模态能力的应用将成为未来一段时间的重点。当然，如果发展的顺利的话，在我们的有生之年或许能看到 AGI 的实现。
三金哥：AGI 又是啥？
大师兄：AGI 是 Artificial General Intelligence 的缩写，即通用人工智能，指机器能够完成人类能够完成的任何智力任务的能力。
三金哥：那 AGI 与 LLM 有什么关系？
大师兄：AGI 的实现离不开 LLM 和多模态能力的结合。LLM 通过在计算密集型的自监督和半监督训练过程中，从文本文档中学习统计关系，来获得这些能力。大语言模型也是一种 GenAI，通过输入文本并重复预测下一个标记或单词，来生成新的文本。尽管 AGI 的潜在影响十分巨大，但也存在着许多挑战和风险，比如安全性、隐私保护、失业风险、道德问题等。
三金哥：期待 LLM 能够得到长足的发展，也期望我们所担心的问题，在 LLM 的发展过程中能够得到解决，我们相信人类的智慧。
粤ICP备17114055号
支持私有云部署
