LLM（large Language Model）大语言模型的6大问题
原生接入LLM的方式有三种，通过API接入、SDK接入和本地部署接入。但是，通过原生方式接入LLM是存在问题的，大致有以下6种主流问题。
1、幻觉问题，对于用户的提问，LLM给出不合乎情理的答案。
比如说，在编码场景，使用redis来接入数据库，redis本身提供了a、b、c三种接口，但是LLM给出的回答却是d接口，这就是一种典型的幻觉场景。
2、提示词问题。对于同一个问题，给LLM提供了两种不同的提示词，LLM会给出两种不同的答案。
提示词的质量和风格直接决定输出结果的准确性和安全性。没有统⼀的规范会导致应⽤⾏ 为不可预测、难以调试，且⽆法规模化地优化效果。
3、切换模型问题。切换不同的LLM，对于不同的厂商提供的LLM接口、输入输出格式和参数也各有不同。这样对于切换模型，就很不方便。
切换成本极高。这意味着⼀旦选定⼀个模型，整个应⽤程序的代码就与该模型的 API 强耦合。切换模型⼏乎等于重写所有与 LLM 交互的代码，严重阻碍了技术选型的灵活性。
4、LLM输出非结构化数据难以与程序接口交互。对于程序接口更希望接收结构化的数据，对于不同的描述体现在不同的字段上。
5、无法获取实时信息。LLM训练是有截至日期的，也就说LLM对于实时、前沿的数据知识，是没有这个能力的。
6、对于非常专业的知识（医学），LLM的回答只能作为参考，并不能100%的信任。因为LLM只是会去进行回答，并未从专业的，特定的知识库中去查询。
对于这个场景，更希望LLM接收到用户问题的输入之后，LLM会去查询专业知识的服务器上的知识库，然后给出回答。这样的回答 才是可信高的。
langchain
对于langchain是如何解决原生调用LLM的6大主流问题如下。
1、幻觉问题
使用agent智能体解决幻觉问题（智能推导），使用RAG技术基本可以解决大多数幻觉问题。
RAG流程如下：
1、用户输入问题。2、将问题转换为向量，在知识库中进行检索。这里的知识库，大多都是向量数据库，可以进行语义相似度进行检索。根据语义检索出相关文档。3、将检索出来的相关文档作为参考答案，和前面的用户输入问题一起输入给LLM。4、有LLM进行整合和输出给用户最终答案。
关于向量数据库的认识和语义相关性的理解如下。
向量就是将文本转换成为一组向量，对于向量可以和三维向量进行类比，向量的长度可以和文本长度进行参考，向量方向可以和语义参考。
对于语义相关性主要是以欧氏距离和余弦相似度作为参考。欧氏距离的是考量两个向量之间的距离，距离越近，语义相关性越强。但是，对于两段文本，语义相似，但是描述长度不同，其欧式距离就越远。因此，欧式距离作为语义相关性判断还是有缺陷的。
对于余弦相似度则是两个向量之间的余弦越相近，语义相关越强。而在向量数据库中检索，更多使用的也是余弦相似度去度量语义相似度。
2、对于提示词问题，就需要使用提示词工程或者人为规定进行统一提示词规范。
3、对于切换大模型，langchain在底层封装了多个大模型，向外提供一个统一的接口进行调用。比如对于GPT、Gemini和DeepSeek等LLM，都能使用统一的调用姿势去使用
4、langchain可以强制要求大模型返回结构化的数据，比如JSON、XML、HTML等
5、langchain提供了工具，在工具里可以封装一个搜索引擎工具，对外部实时、前沿的数据进行获取。对如说deepseek和kimi都提供了联网搜索的功能。
另外对于RAG也可以解决这样的问题，可以对于知识库进行更新，以获取实时前沿数据。
6、可以通过工具，去调用特定的API获取专业的知识。
解决痛点
LangChain 是⼀个⽤于开发由⼤语⾔模型 (LLM) 驱动的应⽤程序的框架。它通过将⾃然语⾔处理 （NLP）流程拆解为标准化组件，让开发者能够⾃由组合并⾼效定制⼯作流。
组件（Components）：⽤来帮助当我们在构建应⽤程序时，提供⼀系列的核⼼构建块，例如语 言模型、输出解析器、检索器等。
自然语⾔处理流程（NLP）：指的是完成⼀个特定 NLP 任务所需的⼀系列步骤。例如，构建⼀ 个"基于公司⽂档的问答机器⼈"的流程可能包括：读取⽂档、分割⽂本、将⽂本转换为向量 （嵌⼊）、存储向量、接收⽤⼾问题、搜索相关⽂本段、将问题和⽂本段组合发送给⼤语⾔模型 （LLM）、解析模型输出并返回答案等。
技术特点
LangChain 框架的设计精髓在于以链式（Chain）的⽅式整合多个组件，从而构建出功能丰富的⼤语 ⾔模型应⽤。链式表⽰ LangChain 允许将多个步骤或多个组件串联起来，⽆需各个组件各⾃完成其能 力，而是⼀次性执行这个"链"上的所有流程！
LangChain 框架提供了⼀系列标准化模块与接口，主要包括以下方面：
• 统⼀的模型调⽤：通过抽象化的接口⽀持多种⼤语⾔模型（例如 OpenAI GPT-4/5、Anthropic Claude 等）和嵌⼊模型，使开发者可以灵活切换不同模型供应商。
• 灵活的提⽰词管理：提供提⽰词模板（Prompt Templates），支持动态⽣成输⼊内容，并可管理 少样本⽰例与提⽰选择策略，以提升模型响应质量。
• 可组合的任务链（Chains）：允许将多个步骤串联成完整流程，如先检索⽂档再⽣成回复，或组合 多次模型调⽤。开发者能够通过⾃定义链实现复杂的任务编排。
• 上下⽂记忆机制（Memory）：⽤于存储多轮对话中的状态信息。LangChain 曾提供多种记忆管理 ⽅案（如对话历史记忆和摘要记忆），以实现连贯的交互体验（注：该功能⽬前已由 LangGraph ⽀持，原有实现已过时）。
• 检索与向量存储集成：⽀持从外部加载⽂档，经分割和向量化处理后存储⾄向量数据库，在查询时 检索相关信息并输⼊⼤语⾔模型，帮助构建检索增强⽣成（RAG）类应⽤。LangChain 兼容多种主 流向量数据库（如 FAISS、Pinecone、Chroma）和⽂档加载⼯具，简化知识库应⽤的开发流程。
langgraph
langchain的局限性
LangGraph 是 LangChain ⽣态系统中晚些出现的⼀个框架，其诞⽣背景与⼤型语⾔模型应⽤⽇益增⻓ 的复杂性密切相关。随着开发者尝试构建更高级的 AI 代理和多轮对话系统，传统链式结构的局限性逐 渐显现：
• 链式流程通常是线性的、预先定义好的步骤，难以处理需要循环、分支或长期状态维护的复杂场 景。
• 此外，在构建多智能体协作、需要人工介入（Human-in-the-loop）或⻓时间运⾏的任务时，需要 更灵活的⼯作流管理和状态持久化⽀持。
比如下面的例子
如果⽤传统的 Chain A -> Chain B -> Chain C 的线性结构来构建，会遇到以下具体问题：
问题1：难以处理循环和分支（无法动态路由和多次询问）
在 "信息收集" 阶段，用户第⼀次可能提供了⼀个不完整的订单号。链式流程是单向的，它⽆法自动 "跳回" 上⼀步再次请求用户补充信息。
结果：只能让整个链失败，或者⽣成⼀个僵硬的错误消息，用户体验非常差。无法实现 "只要信息不 完整，就持续询问直到完整" 这样的逻辑。
问题2：状态维护困难（无法长时间运⾏和记忆上下文）
客⼾服务对话通常是多轮的，可能持续几分钟、几小时甚至几天。传统的链在每次调用时都是"无状 态"的。
结果：状态管理（记忆）的重担完全落在了开发者⾝上，需要依赖外部数据库或缓存来手动存储和读 取对话状态，代码会变得非常臃肿和脆弱。
问题3：难以融入人工介⼊（Human-in-the-loop）
当 AI ⽆法处理时，需要⽆缝地转交给⼈。在链式流程中，这意味着链的执⾏到此中断。⽆法优雅地实 现暂停 AI 流程，等待⼈⼯处理完毕，再将结果返回，继续执⾏后续⾃动化步骤。
结果：整个流程会断裂成两半：AI 部分和人工部分。你需要构建另外的系统来通知人工、接收⼈⼯处 理结果，并重新触发后续的链，这完全破坏了工作流的完整性和可管理性。
问题4：僵化的流程（⽆法根据条件动态跳转）
不同的用户意图需要完全不同的子流程。例如判断用户意图：
• 是"投诉"。我们的链可能预先设计为⾛ A->B->C 路径。
• 是"产品咨询"，可能需要⾛ A->D->E 路径。
在链式结构中，实现这种条件分支非常笨拙，通常需要编写⼀个巨大的"主链"，内部用⼀系列 if-else 语句来调⽤不同的⼦链。
结果：流程图的逻辑变成了代码中的控制流语句，而不是清晰可见的图形化结构。这使得工作流难以设计、调试和可视化。
解决痛点
为了解决这些问题，LangChain 团队于 2024 年推出了 LangGraph 框架，旨在提供⼀种图结构的、状 态化的⽅式来构建复杂的 AI 代理应⽤。
LangChain 团队将 LangGraph 定位为"低层次的编排框架"，用于构建可控、可靠的 AI 代理⼯作 流。目前，LangGraph 已经在⼀些⽣产环境中得到应⽤，例如 LinkedIn、Uber、GitLab 等公司据报 道使用 LangGraph 来构建复杂的⽣成式 AI 代理系统。
例如，我们将上述链式示例改为图结构：
在上述⽰例中，我们可以定义图状态，⽤于存储流程中的临时数据和决策点，例如：
• intent : 用户意图（字符串，如 "return", "inquiry", "complaint"）。
• collected_info : 字典，存储收集到的信息（如订单号、问题描述）。
• needs_human : 布尔值，表⽰是否需要人工介入（默认 False）。
• is_verified : 布尔值，表⽰信息是否已验证（默认 False）。
• is_complete : 布尔值，表⽰流程是否完成（默认 False）。
• message_history : 列表，存储对话历史，⽤于多轮交互。
LangGraph 并不是要取代 LangChain，而是对 LangChain 的扩展和补充。LangGraph 底层⼤量复用 了 LangChain 的组件（如模型接口、工具、记忆等），开发者可以在 LangGraph 的节点中直接使⽤ LangChain 的链或代理作为⼦流程。因此，LangGraph 与 LangChain 是互补关系：
• 对于简单的线性任务，LangChain 的链式结构已经⾜够⾼效；
• ⽽对于需要复杂控制流、⻓期状态和多智能体的场景，LangGraph 提供了更强⼤的⽀持。
技术特点
LangGraph 将应⽤逻辑建模为图（Graph）结构，其中：
• 节点：表示操作或状态。
• 边：表示节点之间的转移和数据流。
这种图式架构相比 LangChain 的链式结构更加灵活，主要体现在：
• 循环与分⽀：LangGraph 中的节点（Node）可以连接到其他任何节点，包括自己。你可以轻松设 置⼀个"信息收集"节点，如果信息不完整，就让流程再次循环回这个节点本⾝，直到条件满足为止。
• 动态路由：通过条件边，可以根据当前状态的值，动态决定下⼀个要执行的节点。例如，在"分 类"节点之后，可以根据分类结果，⾃动路由到"处理退货"、"处理咨询"或"处理投诉"等完 全不同的子图中去。
• 状态维护：LangGraph 有⼀个核心的状态对象，在整个图的执行过程中自动持久化和传递。每个节 点都可以读取和修改这个状态。这意味着用户的对话历史、已收集的信息都会自动保留，轻松支持 长时间运行的任务。
• 持久执⾏：构建能够经受住故障并能长时间运⾏的代理，自动从上次中断的地⽅恢复。
• ⼈机协作：通过在执行过程中的任何时刻检查和修改代理状态，无缝融⼊⼈⼯监督。
• 全面记忆：创建真正具有状态的代理，兼具用于持续推理的短期⼯作记忆和跨会话的长期持久记 忆。
• 使用 LangSmith 进行调试：借助可视化⼯具深⼊洞察复杂代理⾏为，这些⼯具可追踪执⾏路径、 捕获状态转换并提供详细的运⾏时指标。
• 生产级部署：借助专为处理有状态、长时间运行工作流的独特挑战而设计的可扩展基础设施，自信 地部署复杂的代理系统。
总结来说，构建 AI 代理应⽤时，如果⽤传统链式结构构建，会变成⼀个僵硬、脆弱、难以维护的"面 条代码"。而 LangGraph 则能将其建模为⼀个灵活、可靠、可视化程度⾼、且⽀持复杂逻辑（循环、 分支、人工） 的⼯作流图，这正是它为了解决⽇益复杂的 LLM 应⽤而诞⽣的价值所在。