大模型应用开发实战：从LangChain、RAG到LangGraph的进阶路线

1. 从“调API”到“造系统”大模型应用开发到底在学什么很多人第一次接触大模型应用开发都是从一行openai.ChatCompletion.create()开始的。调通那一刻确实兴奋感觉自己摸到了新时代的门槛。但很快就会发现能跑通一个对话demo和能交付一个真正可用的应用之间隔着一整条技术栈的鸿沟。我最初也是这样以为学会调API就等于会做大模型开发结果第一个真实需求就把我打回了原形——用户要的是一个能读懂公司内部文档、能记住上下文、能调用外部工具、还能在回答不确定时主动追问的助手而不是一个只会闲聊的玩具。这就是我决定系统学习大模型应用开发的起点。大模型应用开发说白了就是把大模型当作一个能力内核在它外面搭建一套完整的工程系统让它可以稳定、可控、可扩展地解决具体业务问题。它涉及的核心技术点包括Agent智能体、LangChain、LangGraph、RAG检索增强生成这几大块。Agent负责让模型自主决策和调用工具LangChain提供了串联各种组件的基础抽象LangGraph解决了复杂流程的编排问题RAG则让模型能够基于外部知识库作答。这几样东西不是孤立的它们在实际项目里往往是交织在一起使用的。这篇文章适合谁看如果你已经会写Python、调过大模型API但面对“做一个企业知识库问答”“搭一个能自动处理工单的智能体”这类需求时不知道从何下手那这篇内容就是写给你的。我不会只讲概念而是把我自己踩过的坑、选型时的纠结、调试时的思路都摊开来讲。你会看到我是怎么从零开始一步步把LangChain、LangGraph、RAG这些技术点串成一条完整的学习路线的。2. 学习路线整体设计与技术选型思路2.1 为什么我没有一上来就啃LangGraph刚开始学习的时候最容易犯的错误就是贪多。网上搜“大模型学习路线”出来的结果动辄几十个技术栈从Transformer原理到RLHF微调从向量数据库到Agent框架看得人头皮发麻。我一开始也试图按那个路线走结果学了两个月还在调环境连一个完整项目都没跑起来。后来我调整了策略以项目驱动学习用到什么学什么先跑通再深挖。具体来说我把学习分成了三个阶段。第一阶段是打地基核心是理解大模型API的调用方式、Prompt Engineering的基本技巧、以及Token和上下文窗口的概念。这个阶段不需要任何框架纯手写Python调用就行。第二阶段是学LangChain和RAG因为这是最容易看到成果的部分——搭一个本地知识库问答系统能立刻感受到“大模型外部知识”的威力。第三阶段才是Agent和LangGraph因为这两个涉及更复杂的编排逻辑需要前两个阶段的基础打牢了才好理解。提示不要被“学习路线”绑架。每个人的基础不同如果你已经有后端开发经验完全可以跳过一些基础环节直接从LangChain入手。关键是保持“能跑起来”的正反馈。2.2 LangChain和LangGraph到底什么关系这是我在学习过程中被问得最多的问题也是我自己困惑了很久的地方。简单来说LangChain是一套工具集和抽象层LangGraph是一个流程编排引擎。LangChain提供了Chain、Tool、Memory、Retriever这些组件让你可以快速拼装出一个LLM应用。但当你需要实现循环、条件分支、多Agent协作这类复杂逻辑时LangChain的Chain抽象就不够用了——它是线性的很难表达“如果A则走B否则回到C”这种流程。LangGraph就是为了解决这个问题而生的。它把整个应用建模成一个状态图State Graph每个节点是一个处理步骤边定义了步骤之间的流转条件。你可以把它理解成给大模型应用画了一张流程图模型在图的节点之间流转状态在流转过程中不断更新。我自己的体会是简单的线性流程用LangChain就够了一旦涉及循环、分支、多轮工具调用就应该上LangGraph。两者不是替代关系而是互补关系实际项目里经常是LangChain的组件嵌在LangGraph的节点里用。2.3 RAG不是万能药但没有RAG万万不能RAGRetrieval-Augmented Generation是我认为最值得优先掌握的技术点。原因很简单大模型有两个硬伤一是知识有截止日期二是不知道你私有的数据。RAG通过“先检索、再生成”的方式让模型在回答时参考外部知识库既解决了时效性问题又避免了微调的高成本。但RAG也不是银弹。我见过太多人以为搭个向量数据库、把文档塞进去、检索出来拼到Prompt里就完事了结果实际效果一塌糊涂。问题出在检索质量上——如果检索出来的内容不相关模型再强也生成不出正确答案。所以RAG的核心难点不在“生成”而在“检索”。这就涉及到文档切分策略、Embedding模型选择、向量数据库选型、检索结果重排序等一系列工程细节。后面我会专门用一章来讲这些。3. 核心细节解析与实操要点3.1 环境搭建Conda还是Venv这是个问题大模型应用开发的环境管理比普通Python项目要复杂因为涉及到PyTorch、CUDA、各种向量数据库客户端等重型依赖。我一开始用Venv后来换成了Conda原因很简单Conda在处理二进制依赖和CUDA版本冲突方面要省心得多。特别是如果你打算在本地跑Embedding模型或者做微调Conda几乎是必选项。我的环境配置是这样的Python 3.10不要用3.12很多库还没适配Conda创建独立环境PyTorch根据显卡选择对应CUDA版本。如果你用的是AMD显卡比如RX 6750 GRE那就要走ROCm路线配置会麻烦一些但社区里有不少教程可以参考。对于纯API调用为主的开发其实不需要本地GPU直接用云端API就行环境配置会简单很多。conda create -n llm-dev python3.10 conda activate llm-dev pip install langchain langchain-community langchain-openai pip install langgraph pip install chromadb sentence-transformers注意LangChain的包拆分很细langchain是核心抽象langchain-community是社区集成langchain-openai是OpenAI的官方集成。不要只装一个langchain就以为万事大吉了。3.2 Prompt Engineering别小看这门手艺很多人觉得Prompt Engineering就是“会说话”没什么技术含量。但我在实际项目里发现Prompt的质量直接决定了应用的上限。同样的模型同样的知识库Prompt写得好和写得差效果差距可能是天壤之别。我总结了几条实用的Prompt原则。第一角色设定要具体。不要写“你是一个助手”而要写“你是一个专门处理售后工单的客服专家熟悉退换货政策回答时先确认订单号”。第二输出格式要约束。如果你需要模型返回JSON就在Prompt里明确给出JSON schema并加上“只返回JSON不要有其他内容”。第三Few-shot示例比长篇指令更有效。给两三个输入输出的例子比写五百字的规则说明管用得多。还有一个容易被忽略的点Prompt的版本管理。当你的应用有几十个Prompt模板时散落在代码里会非常难维护。我后来把所有Prompt抽到一个单独的YAML文件里用的时候加载进来改起来方便也方便做A/B测试。3.3 文档切分RAG效果的第一道分水岭RAG的第一步是把文档切分成小块Chunk然后对每个块做Embedding。切分策略直接决定了检索质量。我试过固定长度切分、按段落切分、按语义切分三种方式效果差异非常明显。固定长度切分最简单比如每500个字符切一块重叠50个字符。但问题是它会把一个完整的句子或段落拦腰截断导致检索出来的内容语义不完整。按段落切分效果好一些但遇到长段落还是会出问题。我最后采用的是递归字符切分LangChain里的RecursiveCharacterTextSplitter就是干这个的。它的逻辑是先按双换行切如果块还是太大再按单换行切再不行按句号切层层递进尽量保持语义完整性。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, separators[\n\n, \n, 。, , , , , , ] ) chunks splitter.split_text(document)chunk_size设多少合适我的经验是500到1000之间具体取决于你的文档类型和Embedding模型的最大输入长度。chunk_overlap设成chunk_size的10%到20%目的是让相邻块之间有上下文衔接避免检索时丢失跨块的信息。3.4 Embedding模型选择不是越贵越好Embedding模型负责把文本转成向量它的质量直接影响检索的准确率。市面上的选择很多从OpenAI的text-embedding-3到开源的BGE、M3E、GTE各有优劣。我的建议是如果预算允许且数据不出境用OpenAI的embedding模型最省心如果要求本地部署BGE-large-zh-v1.5是目前中文场景下性价比很高的选择。选Embedding模型时要注意两个参数向量维度和最大输入长度。维度越高表达能力越强但存储和检索成本也越高。最大输入长度决定了你的chunk_size上限如果模型只支持512个token你切1000个字符的块就会被截断。我一般会先用小规模数据测试几个模型用检索命中率来选而不是盲目追求排行榜上的第一名。4. 实操过程与核心环节实现4.1 从零搭一个本地知识库问答系统这是我学习的第一个完整项目也是我认为最适合入门的RAG实战。目标很简单把一批PDF文档灌进去然后能通过自然语言提问系统检索相关段落并生成回答。整个流程分为四步文档加载、切分、向量化存储、检索生成。文档加载用LangChain的PyPDFLoader或者UnstructuredFileLoader前者适合纯文本PDF后者适合有表格和复杂排版的文档。加载后得到的是Document对象列表每个对象包含page_content和metadata。metadata很重要后面检索时可以带上来源信息方便溯源。from langchain_community.document_loaders import PyPDFLoader from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain.chains import RetrievalQA # 加载文档 loader PyPDFLoader(knowledge.pdf) docs loader.load() # 切分 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter(chunk_size800, chunk_overlap100) chunks splitter.split_documents(docs) # 向量化存储 embeddings OpenAIEmbeddings() vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./db) # 检索生成 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) result qa_chain.invoke({query: 公司的报销流程是什么}) print(result[result])这段代码看起来简单但里面有几个关键参数值得展开说。search_kwargs{k: 4}表示检索最相关的4个块k值太小可能漏掉关键信息太大则会引入噪声。我一般会设3到5之间然后根据实际效果调整。temperature0是为了让回答更稳定减少随机性这在知识库问答场景下很重要。4.2 检索质量优化从“能用”到“好用”上面那个基础版本跑通后你会发现效果时好时坏。问题往往出在检索环节。我做了三件事来提升检索质量效果立竿见影。第一件事是加入重排序Rerank。向量检索是基于语义相似度的但相似度高不代表相关性强。重排序模型会对初步检索出的结果做一次精细打分把真正相关的排到前面。我用的比较多的是BGE-reranker把它接在向量检索之后检索准确率能提升不少。第二件事是混合检索。纯向量检索对关键词不敏感比如用户搜“RX6750GRE”向量模型可能把它和“显卡”混在一起。加入BM25关键词检索把向量检索和关键词检索的结果融合能兼顾语义和精确匹配。LangChain里的EnsembleRetriever就是干这个的。第三件事是查询改写。用户的提问往往很口语化直接拿去检索效果不好。我加了一个步骤先用LLM把用户问题改写成更适合检索的形式再去查向量库。比如用户问“那个报销的事怎么弄”改写成“公司报销流程和所需材料”检索命中率会高很多。4.3 用LangGraph搭一个多步骤Agent当你的应用需要多步推理和工具调用时LangGraph就派上用场了。我拿一个实际场景举例一个能自动处理用户咨询的Agent它需要先判断问题类型然后决定是查知识库、查订单系统、还是转人工。用LangGraph的思路是这样的定义一个状态State包含用户输入、对话历史、当前步骤、工具调用结果等字段。然后定义节点Node每个节点是一个处理函数比如“分类问题”“检索知识库”“查询订单”“生成回答”。最后定义边Edge决定节点之间的流转逻辑。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated class AgentState(TypedDict): user_input: str category: str context: str answer: str def classify(state: AgentState): # 用LLM判断问题类型 category llm.invoke(f判断以下问题的类型知识库/订单/其他{state[user_input]}) return {category: category.content} def retrieve(state: AgentState): # 检索知识库 docs retriever.invoke(state[user_input]) return {context: \n.join([d.page_content for d in docs])} def generate(state: AgentState): # 生成回答 answer llm.invoke(f根据以下上下文回答问题\n{state[context]}\n\n问题{state[user_input]}) return {answer: answer.content} def route(state: AgentState): if 知识库 in state[category]: return retrieve return generate graph StateGraph(AgentState) graph.add_node(classify, classify) graph.add_node(retrieve, retrieve) graph.add_node(generate, generate) graph.set_entry_point(classify) graph.add_conditional_edges(classify, route, {retrieve: retrieve, generate: generate}) graph.add_edge(retrieve, generate) graph.add_edge(generate, END) app graph.compile() result app.invoke({user_input: 我的订单什么时候到})这个例子里classify节点负责判断问题类型route函数根据分类结果决定走哪条路。如果是知识库问题先走retrieve再走generate如果是其他问题直接走generate。这就是LangGraph的核心价值——用图的方式表达复杂的控制流比用if-else嵌套清晰得多也更容易扩展。4.4 Agent工具调用的实战细节Agent的核心能力是调用工具。LangChain里定义工具很简单用tool装饰器就行。但实际用起来有几个坑要注意。第一个坑是工具描述要写清楚。LLM是根据工具的名称和描述来决定调不调、怎么调的。如果你只写“查询订单”模型可能不知道需要传什么参数。要写成“根据订单号查询订单状态输入参数为订单号字符串”。第二个坑是工具返回结果要控制长度。如果工具返回一大段JSON会占用大量Token还可能干扰模型判断。我一般会在工具函数里做一层处理只返回关键字段。第三个坑是错误处理。工具调用可能失败比如网络超时、参数格式错误。如果不处理整个Agent就崩了。我的做法是在工具函数里用try-except包裹出错时返回一个友好的错误信息让模型知道发生了什么而不是直接抛异常。5. 常见问题与排查技巧实录5.1 检索不到相关内容怎么办这是RAG项目里最常见的问题。排查思路我一般按这个顺序走先看文档有没有成功加载打印一下chunks的数量和内容再看Embedding有没有正常生成检查向量维度对不对然后手动拿一个问题去检索看返回的块相不相关最后检查chunk_size是不是太大或太小。如果文档加载没问题但检索效果差大概率是切分策略或Embedding模型的问题。中文场景下我强烈建议用专门针对中文训练的Embedding模型用英文模型效果会打折扣。另外如果文档里有大量专业术语可以考虑在切分前先做一次术语标准化把同义词统一。5.2 LangChain版本升级导致代码跑不通LangChain的迭代速度非常快经常一个小版本升级就有API变动。我被这个问题坑过好几次后来养成了两个习惯一是锁定版本号在requirements.txt里写死版本二是关注官方迁移指南升级前先看有哪些breaking changes。如果你遇到ImportError或者AttributeError先去查LangChain的官方文档看对应版本的API。很多以前在langchain包里的东西现在移到了langchain-community或者独立包里。比如OpenAI类现在要从langchain_openai导入而不是langchain.llms。5.3 Agent陷入死循环怎么破Agent调用工具时有时候会反复调用同一个工具陷入死循环。这通常是因为工具返回的结果没有让模型满意模型就不断重试。解决办法有两个一是设置最大迭代次数LangChain的AgentExecutor有max_iterations参数设成5到10之间二是在Prompt里明确告诉模型“如果工具返回结果不理想不要重试直接告知用户”。还有一个更隐蔽的原因工具描述有歧义模型不确定该调哪个工具就来回试。这时候要回去检查工具的名称和描述确保每个工具的职责清晰、不重叠。5.4 本地部署大模型选哪个如果你打算本地跑大模型Ollama是目前最省心的方案。它把模型下载、量化、推理服务都封装好了一条命令就能跑起来。模型选择上中文场景我推荐Qwen2.5系列7B的版本在消费级显卡上就能跑效果也不错。如果你的显卡显存有限可以选量化版本比如Q4_K_M牺牲一点精度换更低的显存占用。但说实话本地部署的模型在复杂推理和工具调用能力上和云端旗舰模型还是有差距。我的建议是开发调试阶段用本地模型省钱生产环境用云端API保效果。两者可以共存通过配置切换。问题类型排查方向常用解决手段检索不到内容文档加载、切分、Embedding调整chunk_size、换Embedding模型、加Rerank代码跑不通版本兼容性锁定版本、查迁移指南、检查导入路径Agent死循环工具描述、迭代限制设max_iterations、优化工具描述回答质量差Prompt、检索质量优化Prompt、加Few-shot、提升检索精度响应速度慢模型选择、并发换小模型、加缓存、异步调用5.5 关于微调什么时候该做什么时候不该做微调是很多人容易冲动去做的事。我的经验是先试Prompt Engineering再试RAG最后才考虑微调。微调的成本很高需要准备高质量的训练数据需要GPU资源而且一旦业务变化微调过的模型可能又要重新训。大部分场景下好的Prompt加上RAG就能解决问题。只有当你要改变模型的输出风格、或者让模型学会一种全新的任务格式时微调才值得考虑。6. 学习资源与进阶方向6.1 我实际用过的学习材料官方文档永远是最好的起点。LangChain和LangGraph的官方文档写得相当详细而且有大量示例代码。我建议先把官方文档里的Quickstart跑一遍然后挑几个和你需求接近的示例深入研究。除了官方文档GitHub上的开源项目也是很好的学习材料看看别人是怎么组织代码、怎么处理边界情况的。动手学大模型这类课程适合补理论基础但不要陷进去。我的原则是理论学到够用就行重点是把东西跑起来。遇到不懂的概念先记下来等实际用到的时候再回头深挖这样学习效率最高。6.2 从单Agent到多Agent协作当你掌握了单Agent的开发后下一步自然是多Agent协作。LangGraph支持多个Agent在同一个图里协作每个Agent有自己的职责和工具集。比如一个客服系统可以有“分类Agent”“知识库Agent”“订单Agent”“质检Agent”它们通过共享状态来协同工作。多Agent的难点在于通信和协调。我的经验是每个Agent的职责要单一Agent之间的接口要清晰。不要让一个Agent既查知识库又查订单这样它的Prompt会非常复杂效果反而不好。拆成多个专职Agent每个只做一件事整体系统的可维护性和可扩展性都会好很多。6.3 关于Agentic RAG和Ontology RAG这两个是RAG的进阶方向。Agentic RAG的核心思想是让Agent自主决定什么时候检索、检索什么、检索几次而不是固定的一次检索。Ontology RAG则是引入知识图谱用实体和关系来增强检索的准确性。这两个方向目前还在快速发展中实际落地案例不算多但值得关注。我的建议是先把基础RAG做扎实再考虑这些进阶方案。7. 一些踩坑之后的真心话学大模型应用开发这段时间我最大的体会是不要追求把每个技术点都学透了再动手而是在动手的过程中逐步深入。我见过太多人卡在“Transformer原理还没搞懂”这一步结果半年过去了连一个RAG都没搭起来。实际上你不需要完全理解注意力机制的数学推导也能搭出一个好用的知识库问答系统。先跑通再优化再深挖原理这个顺序对工程导向的学习来说更高效。另一个体会是大模型应用开发的核心竞争力不在模型本身而在工程能力。模型是别人的API是公开的但怎么切文档、怎么设计Prompt、怎么编排流程、怎么处理异常这些才是拉开差距的地方。我花在调试检索质量上的时间远比花在调API上的时间多。所以如果你问我最该投入精力学什么我的答案是RAG的检索优化和Agent的流程编排这两块学好了大部分应用场景都能覆盖。最后分享一个我常用的调试技巧把每一步的中间结果都打印出来。检索到了哪些块、Prompt长什么样、模型返回了什么、工具调用参数是什么全部打日志。大模型应用是个黑盒你不把中间过程暴露出来根本不知道问题出在哪。我一开始嫌麻烦不打日志结果一个简单的检索问题查了一整天后来加上日志十分钟就定位到了。这个习惯看起来笨但真的省时间。