去年开始身边越来越多做前后端、数据分析甚至产品经理的朋友跑来问我同一个问题想搞LLM应用开发但一上来就被Prompt工程、RAG、Agent、LangChain、向量数据库、微调这些名词砸晕了完全不知道从哪里下手。我自己的体会是问题不在知识点太多而是缺一张地图。概念之间是什么关系、谁依赖谁、先学哪个后学哪个没人讲清楚。所以这篇内容我想把LLM应用开发拆成一个五层架构把每个层要解决的核心问题、常用工具、新人容易踩的坑全部串一遍再附上我实际在用的工具箱和选型建议。目标是让刚接触AIGC开发的人也能顺着这条主线一步步搭出真正能跑起来的东西。1. 先看地图为什么LLM应用开发要分五层1.1 新手常见的三种翻车现场先说三种我见过最多的入门方式基本都翻过车。第一种一上来就啃深度学习理论。从Transformer论文开始埋头搞注意力机制、位置编码、训练损失研究了两个星期代码一行没写最后也不知道这些知识怎么变成产品。第二种把Prompt当成全部。整天研究提示词技巧结果做个稍微复杂点的业务逻辑就卡住了因为不会管理上下文、不会接数据、不会让模型调用工具。第三种反过来了盲目追热点。听说Agent火一上来就铺LangChain抄了一堆现成案例出了问题根本不知道是哪一层挂掉的。这三种方式的问题都一样没有分层意识。1.2 五层架构的划分逻辑我习惯把LLM应用开发分成五层每一层解决一类独立问题。从下往上分别是第一层算力与模型接入。解决“模型从哪里来、怎么调用、花多少钱”的问题。第二层模型选型与定制。解决“用哪个基座模型、要不要微调”的问题。第三层数据与知识层。解决“怎么把私域知识喂给模型”的问题这块的核心是RAG。第四层编排与逻辑层。解决“怎么把模型变成一套能干活的工作流”的问题包括Prompt工程、工具调用、Agent。第五层产品与交互层。解决“怎么把能力包装成一个可靠、可用、可迭代的产品”的问题。分层不是学术上的严格分类它更像一张工程地图。好处是每当你遇到一个报错或者效果不达预期你能立刻定位问题出在哪一层而不是在整坨代码里瞎找。比如模型答非所问你可能先查Prompt如果你给了文档但它还是瞎编你可能要去查数据层看检索到底召回了什么如果服务一并发就卡死那是第一层接入或者第五层缓存的问题。我在带新人时会先让他们记住这句话先跑通再分层最后谈优化。大部分人的问题是连最小闭环都没有就急着上微调、上Agent框架结果每一层的细节都变成了拦路虎。2. 五层架构逐层拆解每层要做什么、用到什么工具2.1 第一层算力与模型接入——先把模型搞到手再说这一层是地基解决的核心问题是你打算用哪里的算力以什么方式使用模型。对初学者来说最优解几乎都是调用大模型API而不是自己去部署一个开源模型。原因很简单部署一个能用的开源模型第一步就得解决显卡问题。哪怕是用量化过的几B小模型推理时的体验和头部商用模型也差得很远而且折腾环境一两天就过去了。调用API的话注册、拿Key、发一个请求五分钟就能跑通。这一层你需要建立三个概念Token是模型计数的基本单位中文场景下大概一个字对应1到2个token。你每次调API输入和输出都会计费所以“成本”不是按次数算的是按Token总量算的。我见过有人做文档总结把十万字的合同一次性塞进上下文一次调用就烧掉一大笔钱这就是典型不懂Token成本。上下文窗口是指模型一次能处理的输入加输出的总长度。很多人以为窗口越大越好但其实大量的真实场景中塞满窗口会导致三个问题成本飙升、响应变慢、注意力被稀释——模型后面可能在无关细节上“迷失”。所以现在主流的做法不是把所有内容都塞进去而是只把最相关的片段放进去这就是后面第三层RAG要做的事。**温度Temperature**是模型输出的随机性参数。取值范围一般是0到1之间做事实类问答、信息抽取建议调低0.1到0.3比较稳做文案创意、头脑风暴再调高一些。很多新手从头到尾用默认值模型在知识问答场景里一本正经地胡编其实调整温度就能缓解一部分。接入层还有一个容易忽略的点接口的稳定性设计。模型服务偶尔会超时、限流你的代码里必须有超时重试、降级提示这些基本逻辑。我见过有开发者在生产环境里模型服务一抖动整个功能就挂掉用户只看到白屏连个“服务繁忙”的提示都没有这种基础问题其实是第一层没做好。2.2 第二层模型选型与轻量定制——别一上来就微调第二层主要回答两个问题用哪个模型需不需要改造这个模型。模型选型没有一个万能答案但有三个维度可以参考第一是能力匹配度。如果你做的是中文知识问答、内容总结领先的中文模型已经足够好如果你要做复杂推理和代码生成就要选推理能力更强的模型。第二是场景约束。你的应用是否涉及敏感数据、是否需要私有化部署、是否需要离线运行这些硬约束会直接决定你只能选择哪一类模型。第三是生态成熟度。有些模型虽然参数表现不错但工具链、文档、社区支持比较薄弱遇到问题连个参考案例都找不到对新手很不友好这点往往比跑分更重要。说到模型改造我必须劝退一下90%的新项目根本不需要微调。很多人拿到业务场景第一反应是“我要微调一个行业专属模型”。实际上多数业务场景的瓶颈不在模型不懂这个行业而在模型没有你手上的具体资料。这种问题用第三层的RAG就能解决成本低、迭代快、效果可预期。数据一变重新灌一遍就行不用重新训练模型。那什么时候才需要微调一般是这几种情况模型输出格式极其特殊且用Prompt怎么都约束不住需要让模型模仿特定的语气、风格或领域术语推理成本敏感希望用一个更小的模型达到接近大模型的效果。这些都属于后话建议你先把RAG链路跑通再说。这一层还有两个基本功建立基准测试集和做基线评估。找几十条典型问题固定下来每次改动Prompt或者换模型都拿同一套问题去对比效果。没有这个习惯的话你根本说不清改动到底是变好了还是变坏了。我自己的做法是维护一个非常小的“黄金问答集”不求多但每条都覆盖核心场景效果评估几分钟就能做完。2.3 第三层数据与知识层——RAG才是真正的护城河如果说大模型是发动机那RAG就是给发动机供油的管路系统。它解决的核心问题是怎么让模型基于你的私有知识回答而不是靠它记忆里的常识瞎编。RAG的全称是检索增强生成基本逻辑可以拆成四步第一步准备知识库。把你手头的文档——PDF、Word、网页、数据库内容——做清洗去掉页眉页脚、无关广告、重复段落。这一步很脏很累但直接影响后面的检索效果偷懒不得。第二步切片和向量化。把清洗后的文档切成一个个片段再用文本向量模型Embedding Model把每个片段转成一串数字向量。切多碎是个经验活段落太短语义不完整太长检索不精准。我处理中文文档的经验是每个片段300到500字比较合适相邻片段保留30到50字的重叠避免一个完整句子被硬生生切到两段里。第三步把向量存进向量数据库。做检索的时候把用户的问题也转成向量然后在库里找最接近的TopK个片段。这里的K值我建议从5到10开始调你会发现它有很强的“既要又要”属性K太小信息不够K太大噪声太多答案反而更难生成。第四步也是很多教程不会强调的一步重排Rerank。向量检索只是快速粗筛它找回来的片段经常有“看起来像但实际上不相关”的。这时候用一个更精细的排序模型对TopK结果重新打分只保留真正有用的2到3个片段放进上下文。加了重排之后问答准确率通常是肉眼可见地往上涨。我在数据层踩过最大的坑是拿到一手资料就往向量库里灌没有做清洗和格式归一化。结果一问到具体数字模型回答的出处竟然是文档里的广告文案。所以我现在处理文档的流程是先转成纯文本、去重、识别标题层级、拆分段落然后再进切片环节。整个链路里清洗花的时间比向量化多三倍但这三倍时间换来的效果提升非常值得。另外数据层的更新策略也要提前想好。你不可能每次都重建整个向量库所以设计上要考虑增量更新新增文档只处理新增部分删除文档也要能同步删掉对应的向量索引。这些看起来是脏活但它是LLM应用能否长期稳定运行的关键。2.4 第四层编排与逻辑层——从Prompt到Agent第四层是整个架构里最“像写代码”的地方任务是编排模型的行为。先说Prompt工程。别把它理解成“跟模型说好话”它的本质是给模型划定任务边界。一个稳定的生产级Prompt至少包含五个要素角色设定、任务描述、输入数据、约束条件、输出格式。角色设定让模型知道用什么立场说话任务描述要具体到“做什么、不做什么”输入数据就是你从上一层检索出来的内容约束条件包括“只能基于给定资料回答不知道就说不知道”输出格式可以用JSON、Markdown或者固定模板方便程序解析。我在实际项目里用过最实用的一句话是“如果上下文中没有相关信息请直接回答‘未找到相关资料’不要自行补充。”加上这一句幻觉率能降一半。然后是工具调用。模型本身不能查天气、不能下单、不能读写数据库但它能输出一段结构化的调用指令。比如用户问“今天北京适合跑步吗”模型可以输出一个JSON格式的天气查询请求你的代码解析这个请求去调用真实天气接口再把结果返回给模型生成最终回答。再往上是Agent。Agent本质上就是一个循环思考当前任务拆成什么步骤调用对应的工具观察返回结果再决定下一步做什么。很多新人把Agent当成万能的其实它只是一个把大模型、工具、记忆组合起来的执行框架。它的难点不在“怎么让模型聪明”而在“怎么让流程可控”。你必须要给Agent设定最大调用次数、明确的终止条件、异常处理分支否则它会在一个错误路径上来回绕最后不是超时就是烧钱。我见过最离谱的一次一个Agent因为工具返回格式变了连续调用了十几次同一个失败接口账单涨得飞快。我对第四层的建议是先不用任何Agent框架用普通代码把流程写清楚再去理解框架。比如一个客服助手逻辑就是判意图、查知识库、必要时调接口、生成回答。用if-else加函数调用就能写出来。等你对每一步都敏感了再上框架这时候你能读懂框架到底帮你做了什么而不是被框架牵着走。很多人一上来就铺LangChain出了问题根本分不清是Prompt的问题、工具的问题还是记忆的问题就是因为缺少这套最基本的流程感。2.5 第五层产品与交互层——最容易忽略的一层第五层就是把你跑通的模型能力包装成一个真正能用的产品。这一层乱七八糟的细节特别多但每一条都踩在线上。第一个是流式输出。大模型生成几百字要好几秒如果让用户干等着全部生成完再显示体验非常差。生产级应用基本都用流式输出也就是模型每生成几个字就推送一次用户看到的是打字机的效果。这要求前端配合做流式渲染后端做好连接管理和中断处理。第二个是记忆管理。多轮对话里你不能每次都把全部历史记录塞给模型Token成本受不了上下文也迟早撑爆。常规做法是维护一个滑动窗口只保留最近几轮对话再加上圈住用户核心信息的长期记忆库。那些“帮我记住我喜欢喝美式”之类的信息走长期记忆具体的聊天内容走短期窗口。第三是安全与防注入。用户输入是一段不可信的文本里面可能藏着“忽略之前的指令”这种恶意Prompt。你的设计上要做隔离系统指令和用户输入不要混在一起渲染敏感操作必须二次确认必要时对输出的内容做脱敏和过滤。模板渲染时也务必用转义处理别让用户构造的内容直接变成一套新的指令。第四是评估与监控。LLM应用和传统软件最大的区别是输出不确定所以线上要有一套监控响应时间、错误率、Token消耗、用户反馈选项至少要有基础的记录。我再强调一次任何模型输出都不可能100%正确。所以产品的交互设计上必须给用户留一条“这个回答有问题我要重新生成或转人工”的路径。这一点不做模型答错一次你可能就流失一个用户。3. 爆火工具箱盘点按层选型不交智商税工具不在多而在匹配你当前所在的层。我一向反对“全家桶”式地全上这里我按上面五层对应的需求盘一下我现在实际会用的工具箱。3.1 编排调度类先从原生代码开始再看框架两款主流的开源编排框架LangChain和LlamaIndex想必大家都听过。LangChain生态最大组件最全模型接入、Prompt模板、记忆、Agent、工具调用都覆盖了。但它的抽象层级比较多新手直接上手时经常出现“代码能跑但不知道它在干嘛”的情况。LlamaIndex更聚焦在“数据接入与检索”这件事上对构建知识库、索引、检索这块的设计更友好如果你核心需求就是RAG可以先从它下手。不过我的个人建议是第一个项目请先用原生代码手写跑通之后再对照框架看它的设计。手写一遍RAG链路大概就两百行代码的样子你写完之后再去看LangChain的检索模块会瞬间理解它每个抽象是为了解决什么问题。直接上框架只会让你获得一种“虚假的熟练感”。3.2 本地模型部署类轻量工具值得关注如果确实需要本地跑模型做实验推荐关注开源模型部署工具Ollama这类轻量方案。它的价值是把“下载模型、起服务、暴露API”这三件事压缩成几条命令对前期做技术验证和离线演示特别方便。你不需要理解底层推理引擎的复杂细节先跑起来再说这也是符合分层思维的做法。我个人的使用场景包括在没网的环境下给客户做Demo以及测试一些小模型在不同参数下的输出风格。真到了高并发生产环境才需要考虑GPU推理服务之类的重型方案。3.3 一站式应用平台类适合快速验证想法如果你不想从零写前后端或者只想快速验证一个业务想法有没有价值Dify这类可视化编排平台很值得看看。它把模型管理、知识库、Prompt编排、Agent流程都集成在一个界面里你可以用拖拽的方式先把流程做出来手机端一测行不行马上知道。我对这类平台的定位是“快速试错工具”。它不能替代你理解底层原理但能极大压缩从想法到Demo的时间。很多独立开发者和中小团队做内部工具时直接用这类平台就够了根本不需要自研一套编排系统。3.4 可观测与评估类越早接入越好等到应用上了生产你马上会意识到评估和监控的重要性。现在也有一些开源的LLM应用可观测工具可以记录每次调用的输入输出、Token用量、延迟、成本。我建议从第一个线上项目开始就把日志留好不然出了问题你连复现现场的机会都没有。评估方面除了自己维护黄金问答集也可以关注一些做评测编排的开源组件它会帮你自动跑一批测试集输出各个维度的评分对比。注意这类工具看的是相对趋势不是绝对分数别迷信数字核心还是回到你自己的业务场景里逐个看案例。3.5 向量数据库类不要贪多贪新向量数据库这个品类选择非常多开源的、托管的都有。我给新人的建议很简单第一个项目用你最熟悉或最容易本机跑起来的开源向量库就行比如Chroma、FAISS这类数据量在百万级以下完全够用。别一上来就上分布式向量集群那是自找麻烦。向量库只是工具你的核心竞争力是数据清洗、切片策略、Embedding选型和检索质量这些跟换哪个库关系不大。换个库也就是改几行配置真正的难点从来不是存储引擎本身。我觉得选工具的底层逻辑就一条你的项目处在哪个阶段就用哪个阶段的工具别为了“以后会用到”去提前引入复杂度。之前见一个独立开发者产品还在验证期就上了微服务加K8s加一套完整的监控体系光维护基础设施就耗掉了一半精力产品反而迟迟没跑起来。4. 实操从零搭一个文档问答机器人理论说再多不如跑一个最小的完整项目。这里我用自己的伪代码风格给你拆一个“文档问答机器人”的完整链路每一步都对标五层架构里的某一层。4.1 目标与前置准备我们要做的东西是上传一份产品说明文档然后用户可以像聊天一样问“这个产品的退款政策是什么”。流程就是文档切片、向量化、构建索引、检索、生成回答。主流程用Python实现依赖尽量少文档解析、文本向量模型、一个本机向量库、大模型API。整个项目跑起来后你能清楚地看到每一层代码长什么样。4.2 文档加载与切片这一步对应第三层“数据与知识层”的前半段。from docx import Document from pathlib import Path def load_docx_and_chunk(path: str, chunk_size: int 400, overlap: int 60) - list[str]: doc Document(path) full_text \n.join(p.text.strip() for p in doc.paragraphs if p.text.strip()) chunks [] start 0 text_len len(full_text) while start text_len: end start chunk_size chunks.append(full_text[start:end]) start max(0, end - overlap) return chunks这里的chunk_size和overlap是经验值。400字左右一个片段中文场景下语义相对完整overlap设60字是为了确保一个关键句刚好被切在边缘时下一个片段仍能包含它。这俩参数没有绝对最优你应该用自己的文档多测几版比较检索命中率再定。4.3 向量化与索引构建继续在第三层里操作但进入向量化和存储环节。from sentence_transformers import SentenceTransformer encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) def build_index(chunks: list[str]): embeddings encoder.encode(chunks).tolist() # 使用本机向量库构建索引此处以熟悉的开源库为例 import chromadb client chromadb.PersistentClient(path./kb_db) collection client.get_or_create_collection(product_kb) ids [fchunk_{i} for i in range(len(chunks))] collection.add(idsids, documentschunks, embeddingsembeddings) return collection这里选中文文本向量模型时注意要选对中文支持好的模型英文模型处理中文句子效果会差不少。Embedding模型的细节直接影响检索质量但不用太过纠结先在官方推荐的模型里选一个用起来等主链路通了再回来对比替换。4.4 检索与生成检索对应第三层的召回部分生成对应第四层和第二层。def query_kb(question: str, collection, top_k: int 5): q_emb encoder.encode([question]).tolist() results collection.query(query_embeddingsq_emb, n_resultstop_k) return results[documents][0] def generate_answer(question: str, context_chunks: list[str]) - str: context \n\n.join(context_chunks) prompt f请基于以下资料回答问题。 资料 {context} 问题{question} 要求 1. 只依据资料回答资料里没有的内容请回答“未找到相关资料”。 2. 回答要简洁控制在200字以内。 # 调用大模型API # response your_llm_client.chat(prompt, temperature0.2) return 模拟返回根据资料退款政策是... def doc_qa(question: str, collection): chunks query_kb(question, collection) return generate_answer(question, chunks)这个环节有三个容易踩的坑。第一个是TopK的设置。K值太小资料可能不完整K值太大无关片段混进来会干扰生成。我建议先用5然后去看召回的片段到底相不相关逐个调整。经常有人只看最终答案效果不检查中间召回结果导致模型被带偏也不知道问题出在哪。第二个是Prompt里必须明确“不知道就直说”。不加这句话模型就会基于自己的惯性知识强行回答看起来流畅实际内容不在你的知识范围内这就是幻觉来源。第三个是温度要调低。问答场景一般设0.1到0.3之间太高了会带来随机性同一个问题两次回答不一样这在知识型应用里很致命。4.5 跑通之后的三个升级方向主链路能跑之后不要急着加功能先把这三个升级做了价值最大。第一个是引用溯源。把回答里每一句话跟召回的原文片段关联起来输出时标注“来源文档第几节第几段”。这一步直接提升用户信任感也方便排查模型是不是读了错误资料。第二个是重排。在向量召回TopK之后用一个重排模型对结果重新打分只保留最相关的2到3个片段。我前面已经说过这是RAG效果提升最明显的操作之一几乎每个项目都能用上。第三个是评估集。把你业务里最典型的二三十个问题固定下来每次改切片、换向量模型、调Prompt都跑一遍对比效果。没有评估集你所有的“感觉变好了”都只是感觉。5. 常见问题与排查技巧实录5.1 上下文爆掉与Token超限报错信息千奇百怪但本质就是一句话你往请求里塞的东西太多了。排查思路先算账。输入Prompt文本大概多少字换算成Token加上期望输出的Token如果接近模型窗口上限就要削减内容。常规手段有三个缩小检索TopK、精简Prompt模板、给历史对话做滑动窗口。还有个技巧是把长文档里“不重要的参考信息”丢弃——如果模型只需要某个数字别把整个表格塞过去让它用结构化输出只提取数字。5.2 检索结果牛头不对马嘴表现是模型回答很流畅但内容跟用户问的完全不沾边。问题十有八九出在第三层。先看召回片段原文是不是真的相关。如果召回的片段本身就偏了查三件事清洗环节是否把关键信息误删了、切片粒度是否太粗导致一个片段混了多个主题、Embedding模型是否选得不对。如果召回片段本身看起来相关但生成回答没用上那就是Prompt里没把“只能依据资料”写清楚或者TopK太大把噪声也引进了。5.3 Prompt输出不稳定同一批问题今天输出正常明天格式就乱了。这种不稳定多半不是模型“抽风”而是你在Prompt里用了一些模糊表达。要稳定输出就要给出精确到字符的格式约定。比如要JSON就明确“输出一个JSON对象不要包含任何解释、Markdown代码块标记或额外字段”。给一个最坏情况下的兜底解析JSON失败时程序应该捕获异常并自动重试而不是直接崩掉。5.4 Agent死循环表现是调用次数多、Token消耗高但任务一直没推进。基本原因就是流程没有设止损线。给Agent加上硬性约束最大调用次数设为5到10次、单轮超时时间、工具失败的重试次数。还有一个容易被忽略的点工具返回结果过长也会反过来塞爆上下文导致模型“迷失”在工具输出里。工具返回信息要做截断和摘要只保留任务所需的关键字段。5.5 成本与延迟失控成本主要看Token消耗延迟主要看请求链路。降成本最有效的手段不是换便宜模型而是减少无效Token。比如每次请求都带着一大段历史记录这部分经常是沉默成本。延迟方面模型输出是token逐字生成的输出越长等待越久所以Prompt里限制回答长度对延迟改善非常直接。加一层缓存也能显著降低成本——常见问题如果命中了缓存根本不需要再调用模型。我把这些高频问题整理成一个速查表现象优先排查层处理建议模型答非所问第三层检查召回片段相关性模型胡编乱造第二、四层降低温度Prompt要求“不知道就直说”响应太慢第一、五层限制输出长度启用流式输出成本增长快第一、五层加缓存做历史窗口裁剪格式总解析失败第四层Prompt给精确格式约定代码做容错重试Agent反复调用工具第四层设最大调用次数工具返回做摘要写在最后的经验整理完这套五层架构我最想对新人说的一句话其实是LLM应用开发目前最大的门槛不是技术难度而是信息噪音。网上到处是“XX框架已死”“XX范式要取代RAG”之类的话题你跟着焦虑下去会发现每个月都有新概念但落到具体项目上你真正天天打交道的还是模型接入、检索质量、Prompt稳定性、成本监控这些老几样。五层架构这套框架我用了很久团队里带新人也都先讲这个因为它的价值不是“新”而是能帮你厘清优先级。我自己最近的一个体会是把一个最简单的RAG链路的每个环节吃透——清洗、切片、向量化、召回、重排、生成——远比追着新框架跑更有复利。复杂应用无非是这些基础环节的排列组合当你对每一层都有手感之后什么新工具出现你都能在半天里上手。最后分享一个小技巧每当你接触新概念别急着记笔记先问自己两个问题——它属于哪一层它解决的是这一层的什么问题答不上来说明这个概念离你的实战距离还远可以往后放一放。用这种方式过滤信息你会轻松很多而且会发现真正值得学的东西远没有你以为的那么多。