1. 为什么一个awesome-llm-apps列表值得所有开发者细看作为一个常年混迹技术社区的老开发我有个不算秘密的习惯——GitHub上凡是名字里带awesome前缀的项目我都会先点个星再说。但说真话大部分列表点进去翻两页就吃灰了真正让我反复回看的没几个awesome-llm-apps恰好是其中之一。原因不复杂大语言模型LLM这几年从论文里的技术名词变成了产品团队手里实实在在的解决方案而LLM应用这个方向上的信息更新速度实在太快今天不看明天就落后。这样一个专门聚合高质量LLM应用的清单相当于有人帮你把这一领域最值得参考的项目筛了一遍。简单解释一下awesome列表是什么。它本质上是开源社区维护的资源索引按主题归类把某一领域值得看的项目、框架、工具、论文、教程聚到一起靠志愿者手工维护、持续更新。awesome-llm-apps专门收集的就是那些真正能跑、能参考、有工程价值的LLM应用实现。对刚入门的人来说它能帮你快速建立这个领域的地图对已经在一线做应用开发的团队来说它更像一本选型目录省掉大量盲目试错的时间。这篇文章我想从一个实战开发者的角度把awesome-llm-apps背后让我印象最深的几条主线拆开聊LLM应用到底有哪几种典型形态、每一类在解决什么问题、工程落地时怎么选型、哪些坑是只有真正写过代码才知道的。不管你是刚接触大模型的学生还是要在公司里主导一个AI功能上线的研发负责人读完应该能对LLM应用到底怎么做有一个清晰的坐标系。1.1 awesome列表为什么在LLM时代特别有价值LLM应用这个领域有一个非常特殊的现象迭代快到你没法靠传统方式吸收信息。框架每周发新版本模型能力几个月就上一个台阶提示词技巧今天有效明天可能被新架构刷掉。写书的速度跟不上变化看论文又太零散博客质量参差不齐。这种情况下awesome这种人工维护、按主题组织的清单就成了一个非常高效的信息过滤器。维护者会在收录项目时做几件事确认项目还能跑、有足够的star或社区验证、把项目按场景分类并标注用途。这相当于有人替你做了初步尽调。我在接到新项目需求时经常会先去翻类似列表看看有没有人已经做过接近的东西直接站在别人的肩膀上而不是从零造轮子。这个习惯真的能省掉至少一周的调研时间。1.2 LLM应用与传统AI应用的分水岭核心是编排很多人对LLM应用的第一印象是接个API写个聊天框。但真正做过之后你会发现传统AI应用的核心是训练一个更好的模型而LLM应用的核心早就变成了怎么把一个模型放进真实业务系统里。举个例子传统的意图识别模型你训练好、部署一个服务、输入输出都是固定的结构化数据。LLM应用完全不是这个套路——用户输入是开放的、不可控的输出也是开放的你要考虑上下文管理、检索增强、工具调用、流式输出、结果评测、安全过滤。这些工作全都发生在模型之外是一整套系统工程。我在看完大量参考项目后最大的感受就是好的LLM应用功夫都在模型外面。2. 从列表里看到的六大类LLM应用形态把热门列表里的项目扫一遍会发现绝大多数LLM应用可以归成几大类。每一类的技术难点完全不同我一个个拆开讲。2.1 对话助手类看似简单工程细节全在后端对话机器人是LLM应用最经典的形态。ChatGPT爆火之后几乎所有团队的第一反应都是我们也做一个自己的对话产品。但真正把对话产品做好远比想象中复杂。首先对话要管理上下文。模型不是无限记忆的你要在应用层做多轮历史的裁剪、摘要、滑动窗口。其次还要处理流式输出让用户看到字一个一个蹦出来体感上快很多还要允许用户编辑提问、说出刚才那句话换个方式说。我在接触这类参考项目时发现做得好的方案通常会在后端把对话状态从简单的消息列表升级成带角色的结构化会话甚至支持多会话隔离、长期记忆持久化。我记得自己最早练手时犯的最大错误就是没管上下文长度。聊到第二十几轮token被塞满模型开始忘记最早说过的话回答质量断崖式下跌。后来才学会做历史摘要和裁剪而这些成熟方案在参考项目里几乎都能找到现成实现。2.2 RAG知识库问答把大模型绑到业务数据上RAGRetrieval-Augmented Generation检索增强生成是LLM应用里含金量最高、也最实用的一大类。为什么需要RAG因为大模型的通用知识有截止时间更不可能知道你公司内部的产品文档和客户资料。RAG的思路是先把你自己的资料切块、向量化、存进向量数据库用户提问时先做检索把相关片段拼进上下文再交给大模型生成回答。这样做的好处非常多。回答有出处可查可以随时更新资料而不需要重新训练模型还能通过权限控制决定哪些内容能被检索到。在参考列表里RAG相关项目数量是最多的也是最考验工程能力的一类。切块策略、embedding模型选择、向量数据库选型、重排序、检索阈值、上下文拼接顺序每个环节都在影响最终效果。我在第4节会用一个完整实操案例把这条链路展开讲这里先不铺开。2.3 Agent自主代理让大模型从动嘴到动手如果说对话和RAG还停留在让模型回答问题Agent类应用就是让模型完成任务。这也是LLM powered autonomous agents能成为热词的原因。这类应用的核心是让大模型具备工具调用的能力你给它几个可执行工具比如查天气、发邮件、查数据库、执行代码它自己规划步骤、循环调用工具、根据结果调整行动直到目标完成。Agent的想象空间巨大但工程难度也直线上升。模型可能陷入死循环可能误用工具甚至可能产生预期之外的行为。实际项目中必须给Agent加保险工具白名单、最大步数限制、人工确认节点、异常分支回退。参考列表里这类项目通常还附带完整的任务规划与反思机制很值得照着源码一行一行读。我自己的经验是第一次做Agent项目时千万不要追求全自动让机器完全自主行动在现阶段风险极高半自动、人审机行才是稳妥路线。2.4 垂域应用与多模态LLM往行业里扎除了通用赛道越来越多项目在往垂直领域深耕。比如面向智能家居的AIoT场景用Agent自动调度全屋设备面向金融、医疗、法律等行业的垂域LLM围绕数据准备、微调、评测做了完整工具链。垂直化趋势很容易理解——通用模型能力再强不贴合行业数据、行业术语、业务流程实际用起来就是别扭。所以我见过的LLM应用几乎都会有一个垂域化的环节。要么做RAG把行业知识喂进去要么做微调让模型说话更像行业专家更常见的是两者结合。我在做一个供应链问答系统之前也曾以为接个大模型就行后来才真正体会到垂域LLM的数据准备才是重头戏。数据清洗、去重、格式转换、敏感信息脱敏、评测集构造……这些往往是最耗时、也最决定项目成败的部分。2.5 数据处理与评测工具容易被忽略的地基列表里还有一类项目不能忽略就是数据处理和评测工具。很多人以为数据准备就是把文档丢进去实际上要做的事远多于此。文档格式解析PDF、Word、Markdown、版面还原、表格抽取、长文本切块、向量化、去重、质量打分每一步都有对应的工具链。而评测工具负责回答我这个改动到底是变好了还是变差了。我在实际项目里发现评测往往是最容易被砍掉的一环但恰恰是它决定了项目能不能持续迭代。没有评测集所有人都在凭感觉改prompt改完也不知道是变好还是变坏。所以我在任何LLM项目里都要先建一个最小评测集哪怕只有五十条也比完全没有强。2.6 多智能体协作从单个Agent到Agent群最后聊一下多智能体这是最近讨论度快速上升的方向。单个Agent能力有限于是有人开始设计多个Agent分工协作的架构一个负责拆解任务一个负责写代码一个负责审查代码一个负责汇总输出。这种编排模式在复杂任务里效果确实不错但复杂度也高Agent之间的通信格式、任务分配逻辑、死锁处理、上下文共享每一个都是工程难题。参考项目里这类实现往往在协议上下足功夫比如强制Agent之间用结构化的JSON传递信息而不是自由文本对话。我建议新人先别碰多智能体除非你已经把单Agent的任务做得足够稳定。否则调试起来会让你怀疑人生。3. 落地一个LLM应用之前先把选型和架构想清楚聊完类型进入工程部分。我发现很多团队第一次做LLM应用时第一步就开始写代码写到一半发现模型选错了、框架不顺手、上下文管理一团糟然后推翻重来。所以我的建议是动手之前先想清楚下面几个问题。3.1 模型选型不能只看跑分六个维度综合权衡模型选型是LLM应用里最容易被低估的决策。很多人第一反应是哪个模型跑分高选哪个但实际工程里要考虑的远不止效果。我一般用六个维度来权衡维度关键问题实操建议效果在你具体任务上的表现不要只看榜单用你自己的数据抽测20条上下文长度能处理多长的文档和对话128K以上更从容但成本也更高推理成本每千token的价格高吞吐场景成本差异会非常大推理延迟首token时间、每秒生成速度实时交互场景要重点压测数据合规数据能否出域、能否私有化敏感场景必须本地部署生态兼容函数调用、流式、JSON模式支持Agent应用对工具调用要求高对大多数做产品验证的团队我的建议是先用一个成熟的商业API把端到端流程跑通验证业务价值再考虑是否能换开源模型私有化部署来降本。反过来如果产品对数据安全要求极高那从一开始就要把本地部署考虑进去选型范围会相应收缩。我自己经历过一次惨痛教训项目做到一半客户突然提了数据不出域的要求整个技术栈不得不推倒重选。这个事最好在需求阶段就问清楚。3.2 Prompt和上下文管理是工程资产不是随手写的几句话很多初学者以为Prompt就是给模型写一段话。实际上Prompt在工程里应当被当作一等公民来管理。我在项目里一般会这样做Prompt模板放在独立目录不硬编码在代码里方便改版本和做A/B。每个模板带版本号和变更记录线上效果出问题时能快速回滚。准备好几组典型输入每次改完模板就跑一遍回归。上下文管理方面要区分三类内容系统指令、检索回来的动态内容、历史对话。这三者各有优先级和放置顺序。我的经验做法是把系统指令放最前面明确告诉模型它的角色和规则检索内容紧跟其后作为参考资料历史对话放在最后。同时总的输入长度控制在模型上下文窗口的70%以内剩下30%留给生成空间避免模型有进无出。3.3 构建Agent的安全边界工具调用是核心突破口Agent类应用成败的关键往往在工具调用设计。工具定义得太粗模型不知道怎么用定义得太细模型规划步骤会爆炸。一般来说工具数量控制在5到10个比较合适。每个工具的description要写得极其明确包括它做什么、参数是什么、什么情况下不该用它。这一步偷懒的话模型就会乱调用工具生产事故就是这么来的。工具执行层还要做几道保险超时控制强制加幂等性设计必须考虑权限校验不能省。模型一旦调错真实系统会被误伤。比如你给Agent一个发送邮件的工具如果不校验收件人白名单和频率限制它可能连续发几十封垃圾邮件给你客户。这些细节在参考项目的源码里都能看到但只有自己踩过坑才会真正重视。4. 完整实操用一个RAG问答应用跑通全流程理论说得再多不如动手写一个。我拿一个典型的RAG问答应用做例子完整走一遍从环境准备到评测收敛的过程这套流程我在多个项目里验证过照着做基本不会跑偏。4.1 环境准备与框架选择技术栈上我推荐一套稳妥的组合Python 3.10以上依赖管理用uv或pip搜索引擎向量数据库先用轻量级的Chroma后期数据量大了再换MilvusEmbedding模型bge-m3或text-embedding-3-small兼顾效果和性价比LLM先用一个支持OpenAI兼容接口的API编排框架新手建议从LlamaIndex或原生代码入手LangChain虽然生态大但封装太多出了问题反而难追我的个人建议是如果你只做一个RAG问答完全可以手写核心代码不过一两百行。手写的最大好处是每一步都知道发生了什么出了问题能快速定位。框架适合在业务复杂起来之后再引入。4.2 数据准备和索引构建切块是门手艺活先处理原始文档。第一步是切块切块大小我一般用300到500个字符重叠50个字符。为什么是这个范围太小了语义不完整块与块之间是割裂的太大会超过embedding模型的有效处理范围检索精度下降。重叠是为了避免上下文在接头处断裂。具体大小可以根据你的文档类型调整——技术文档偏大一些对话记录偏小一些。切完块之后要做清洗去掉页眉页脚、多余换行、无意义的特殊符号。然后向量化入库。这里有个细节很容易被忽略除了存向量和原文文本一定要存metadata比如来源文档名、章节标题、页码、发布时间。这些信息后来在做引用标注和权限过滤时非常关键。没有metadata你的RAG回答就是无源之水用户问一句你凭什么这么说系统答不上来信任感瞬间崩塌。这是我踩坑换来的教训。我第一版RAG系统没存metadata回答正确率看着还行但一上内测就被同事问住了这段结论是哪份文档里的我只能尴尬地说我查查。后来加上metadata回答时携带来源整个产品才真正可用。4.3 检索、重排与生成一条完整的RAG链路查询阶段的流程是先把用户问题向量化从向量库里召回top-k我默认先取5再做重排序把最相关的3个片段拼进上下文最后交给LLM生成回答。可以用参考列表里常见项目的思路自己实现也很简单from openai import OpenAI from chromadb import PersistentClient client OpenAI() db PersistentClient(path./docs_db) collection db.get_or_create_collection(kb) def query_rag(question: str) - str: resp client.embeddings.create( modeltext-embedding-3-small, inputquestion ) qvec resp.data[0].embedding hits collection.query( query_embeddings[qvec], n_results5 ) # 重排序用交叉编码器或LLM对候选片段打分 reranked rerank(question, hits[documents][0]) top3 reranked[:3] context \n\n.join( f[来源{i1}]{doc} for i, doc in enumerate(top3) ) prompt f仅基于以下资料回答用户问题不要编造。资料中没有的信息明确回答“未找到”。回答末尾标注引用编号。 资料 {context} 问题{question} 回答 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content这里我要特别强调一下重排序环节。向量检索本质是语义近似它返回的结果相关性并不精确。我第一版没做重排序效果时好时坏后来加了交叉编码器重排后准确率提升非常明显。重排序比向量检索贵很多所以只作用在召回后的小候选集上性价比最高。插图RAG链路的四大环节示意图文档解析 → 向量化入库 → 召回重排 → 生成回答生成阶段的prompt设计也很关键。必须告诉模型只基于给定资料回答、资料中没有就如实说不知道、标注来源编号。温度参数调低设置为0.2左右让输出更稳。很多人喜欢让模型自由发挥但在RAG场景里自由发挥就意味着幻觉。4.4 搭建一个最小评测体系让优化有据可依评测是很多人会跳过的环节但它恰恰是LLM应用持续迭代的地基。没有评测你无法判断一次改动到底是变好了还是变差了。我的习惯是准备一个50到100条的评测集覆盖三类问题正常问题、边界问题资料里没有但要能拒答、带干扰信息的问题用户故意诱导模型别用资料。然后定期跑一遍看三个指标检索命中率正确的资料是否被召回到top-k里。这个指标衡量的是检索环节的健康度。回答准确率生成内容是否正确、完整。这可以人工评也可以让强模型打分。引用正确率回答中给出的来源编号是否真的对得上。这一点直接关系到产品的可信度。有了这三组数字你就能在改切块参数、换embedding模型、调重排策略之间做出理性判断而不是凭感觉拍脑袋。这是我做过那么多项目后认为最重要的习惯。5. 踩坑实录与高频问题速查最后这部分我把自己和社区里反复踩到的坑整理一下。LLM应用开发跟传统后端开发有一个很大的不同问题不是非黑即白的出故障了排查链条也长所以提前建立一套故障处理框架非常有用。5.1 幻觉问题不是一个Bug而是一个需要系统性解法的问题幻觉hallucination是LLM应用中最常被吐槽的问题但我要说一句幻觉不是Bug它是生成模型的固有属性。指望模型自己知道不知道是靠不住的系统的解法比模型自律更可靠。我在项目里的做法是层层设防第一层用RAG给足高质量上下文让模型没必要编第二层在prompt里明确资料里没有就答不知道弱化它自由发挥的冲动第三层对高风险场景强制要求引用来源没有引用就不给出答案第四层也是很多人会忽略的在入口处做拒答用户问的问题明显不在知识库范围内直接拦截不让模型回答。最后一道防线是加规则或小模型对输出做校验发现高置信度幻觉就退回重答。这一套组合拳下来幻觉率能压到可接受范围。5.2 上下文窗口与成本压力的平衡术上下文窗口越来越大的今天很多团队反而不舍得用因为窗口越大每轮请求的prompt费用越高。我在项目中一般这样优化系统指令只拼一次尽量把不动的部分放在前缀缓存里历史对话做摘要而非把所有原始对话全塞进去检索片段数量控制在2到3个多一个就是多一份钱对高频接口做流式输出首token快速返回会让用户感觉延迟低很多另外一个容易被忽视的点是模型的输入输出单位。有的供应商按输入、输出分开计费输出通常更贵。如果场景是长文本生成成本结构会完全不同。选型之前把账单模型预估清楚别等到月底看账单傻眼。5.3 安全合规与业务风险的边界LLM应用扩大了攻击面安全问题不能忽视。我在项目里至少会做这四件事第一对用户输入做注入防护防止忽略之前的指令这类提示词注入第二控制模型可调用的工具范围高危操作必须走人工审批第三对模型输出做敏感信息过滤防止私密数据被模型无意生成第四数据脱敏在数据准备阶段就做不要在生成阶段再补救。我见过一个真实案例某公司把内部文档接进RAG后没有做权限隔离导致低权限员工检索到了高权限文档的内容。这不是模型的错是系统权限设计缺失。RAG系统的数据访问权限必须在检索层控制而不是依赖模型去懂事。5.4 从Demo到生产最后一公里最容易翻车我把项目从demo推到生产环境的时候遇到的问题和开发阶段完全不同。demo阶段可以用任何向量数据库生产环境要考虑高可用和数据持久化demo阶段可以直接调模型API生产环境要做限流、熔断、重试和优雅降级。这些能力在参考列表的项目里很多都有现成实现但只有自己集成一遍才会理解为什么要有它们。印象最深的一次翻车是demo环境跑得好好的一上生产流量向量数据库并发一上来就超时。排查半天发现是没用连接池默认配置只允许有限并发。这种问题在设计阶段想不到只能靠压测暴露。所以我的建议是功能开发完成别急着上先做一轮压测和故障演练把可能挂掉的环节都打一遍。我个人在这些项目里反复体会最深的一点是LLM应用的复杂度不在软件里而在它的不确定性上——模型是不可靠的组件你要做的是用系统设计去包容它的不可靠。这个心态转换过来许多问题就会从模型为什么这么蠢变成我的系统为什么不聪明。心态对了剩下的就是工程问题而工程问题总是有解的。 从awesome-llm-apps解锁LLM应用六大形态与工程落地
1. 为什么一个awesome-llm-apps列表值得所有开发者细看作为一个常年混迹技术社区的老开发我有个不算秘密的习惯——GitHub上凡是名字里带awesome前缀的项目我都会先点个星再说。但说真话大部分列表点进去翻两页就吃灰了真正让我反复回看的没几个awesome-llm-apps恰好是其中之一。原因不复杂大语言模型LLM这几年从论文里的技术名词变成了产品团队手里实实在在的解决方案而LLM应用这个方向上的信息更新速度实在太快今天不看明天就落后。这样一个专门聚合高质量LLM应用的清单相当于有人帮你把这一领域最值得参考的项目筛了一遍。简单解释一下awesome列表是什么。它本质上是开源社区维护的资源索引按主题归类把某一领域值得看的项目、框架、工具、论文、教程聚到一起靠志愿者手工维护、持续更新。awesome-llm-apps专门收集的就是那些真正能跑、能参考、有工程价值的LLM应用实现。对刚入门的人来说它能帮你快速建立这个领域的地图对已经在一线做应用开发的团队来说它更像一本选型目录省掉大量盲目试错的时间。这篇文章我想从一个实战开发者的角度把awesome-llm-apps背后让我印象最深的几条主线拆开聊LLM应用到底有哪几种典型形态、每一类在解决什么问题、工程落地时怎么选型、哪些坑是只有真正写过代码才知道的。不管你是刚接触大模型的学生还是要在公司里主导一个AI功能上线的研发负责人读完应该能对LLM应用到底怎么做有一个清晰的坐标系。1.1 awesome列表为什么在LLM时代特别有价值LLM应用这个领域有一个非常特殊的现象迭代快到你没法靠传统方式吸收信息。框架每周发新版本模型能力几个月就上一个台阶提示词技巧今天有效明天可能被新架构刷掉。写书的速度跟不上变化看论文又太零散博客质量参差不齐。这种情况下awesome这种人工维护、按主题组织的清单就成了一个非常高效的信息过滤器。维护者会在收录项目时做几件事确认项目还能跑、有足够的star或社区验证、把项目按场景分类并标注用途。这相当于有人替你做了初步尽调。我在接到新项目需求时经常会先去翻类似列表看看有没有人已经做过接近的东西直接站在别人的肩膀上而不是从零造轮子。这个习惯真的能省掉至少一周的调研时间。1.2 LLM应用与传统AI应用的分水岭核心是编排很多人对LLM应用的第一印象是接个API写个聊天框。但真正做过之后你会发现传统AI应用的核心是训练一个更好的模型而LLM应用的核心早就变成了怎么把一个模型放进真实业务系统里。举个例子传统的意图识别模型你训练好、部署一个服务、输入输出都是固定的结构化数据。LLM应用完全不是这个套路——用户输入是开放的、不可控的输出也是开放的你要考虑上下文管理、检索增强、工具调用、流式输出、结果评测、安全过滤。这些工作全都发生在模型之外是一整套系统工程。我在看完大量参考项目后最大的感受就是好的LLM应用功夫都在模型外面。2. 从列表里看到的六大类LLM应用形态把热门列表里的项目扫一遍会发现绝大多数LLM应用可以归成几大类。每一类的技术难点完全不同我一个个拆开讲。2.1 对话助手类看似简单工程细节全在后端对话机器人是LLM应用最经典的形态。ChatGPT爆火之后几乎所有团队的第一反应都是我们也做一个自己的对话产品。但真正把对话产品做好远比想象中复杂。首先对话要管理上下文。模型不是无限记忆的你要在应用层做多轮历史的裁剪、摘要、滑动窗口。其次还要处理流式输出让用户看到字一个一个蹦出来体感上快很多还要允许用户编辑提问、说出刚才那句话换个方式说。我在接触这类参考项目时发现做得好的方案通常会在后端把对话状态从简单的消息列表升级成带角色的结构化会话甚至支持多会话隔离、长期记忆持久化。我记得自己最早练手时犯的最大错误就是没管上下文长度。聊到第二十几轮token被塞满模型开始忘记最早说过的话回答质量断崖式下跌。后来才学会做历史摘要和裁剪而这些成熟方案在参考项目里几乎都能找到现成实现。2.2 RAG知识库问答把大模型绑到业务数据上RAGRetrieval-Augmented Generation检索增强生成是LLM应用里含金量最高、也最实用的一大类。为什么需要RAG因为大模型的通用知识有截止时间更不可能知道你公司内部的产品文档和客户资料。RAG的思路是先把你自己的资料切块、向量化、存进向量数据库用户提问时先做检索把相关片段拼进上下文再交给大模型生成回答。这样做的好处非常多。回答有出处可查可以随时更新资料而不需要重新训练模型还能通过权限控制决定哪些内容能被检索到。在参考列表里RAG相关项目数量是最多的也是最考验工程能力的一类。切块策略、embedding模型选择、向量数据库选型、重排序、检索阈值、上下文拼接顺序每个环节都在影响最终效果。我在第4节会用一个完整实操案例把这条链路展开讲这里先不铺开。2.3 Agent自主代理让大模型从动嘴到动手如果说对话和RAG还停留在让模型回答问题Agent类应用就是让模型完成任务。这也是LLM powered autonomous agents能成为热词的原因。这类应用的核心是让大模型具备工具调用的能力你给它几个可执行工具比如查天气、发邮件、查数据库、执行代码它自己规划步骤、循环调用工具、根据结果调整行动直到目标完成。Agent的想象空间巨大但工程难度也直线上升。模型可能陷入死循环可能误用工具甚至可能产生预期之外的行为。实际项目中必须给Agent加保险工具白名单、最大步数限制、人工确认节点、异常分支回退。参考列表里这类项目通常还附带完整的任务规划与反思机制很值得照着源码一行一行读。我自己的经验是第一次做Agent项目时千万不要追求全自动让机器完全自主行动在现阶段风险极高半自动、人审机行才是稳妥路线。2.4 垂域应用与多模态LLM往行业里扎除了通用赛道越来越多项目在往垂直领域深耕。比如面向智能家居的AIoT场景用Agent自动调度全屋设备面向金融、医疗、法律等行业的垂域LLM围绕数据准备、微调、评测做了完整工具链。垂直化趋势很容易理解——通用模型能力再强不贴合行业数据、行业术语、业务流程实际用起来就是别扭。所以我见过的LLM应用几乎都会有一个垂域化的环节。要么做RAG把行业知识喂进去要么做微调让模型说话更像行业专家更常见的是两者结合。我在做一个供应链问答系统之前也曾以为接个大模型就行后来才真正体会到垂域LLM的数据准备才是重头戏。数据清洗、去重、格式转换、敏感信息脱敏、评测集构造……这些往往是最耗时、也最决定项目成败的部分。2.5 数据处理与评测工具容易被忽略的地基列表里还有一类项目不能忽略就是数据处理和评测工具。很多人以为数据准备就是把文档丢进去实际上要做的事远多于此。文档格式解析PDF、Word、Markdown、版面还原、表格抽取、长文本切块、向量化、去重、质量打分每一步都有对应的工具链。而评测工具负责回答我这个改动到底是变好了还是变差了。我在实际项目里发现评测往往是最容易被砍掉的一环但恰恰是它决定了项目能不能持续迭代。没有评测集所有人都在凭感觉改prompt改完也不知道是变好还是变坏。所以我在任何LLM项目里都要先建一个最小评测集哪怕只有五十条也比完全没有强。2.6 多智能体协作从单个Agent到Agent群最后聊一下多智能体这是最近讨论度快速上升的方向。单个Agent能力有限于是有人开始设计多个Agent分工协作的架构一个负责拆解任务一个负责写代码一个负责审查代码一个负责汇总输出。这种编排模式在复杂任务里效果确实不错但复杂度也高Agent之间的通信格式、任务分配逻辑、死锁处理、上下文共享每一个都是工程难题。参考项目里这类实现往往在协议上下足功夫比如强制Agent之间用结构化的JSON传递信息而不是自由文本对话。我建议新人先别碰多智能体除非你已经把单Agent的任务做得足够稳定。否则调试起来会让你怀疑人生。3. 落地一个LLM应用之前先把选型和架构想清楚聊完类型进入工程部分。我发现很多团队第一次做LLM应用时第一步就开始写代码写到一半发现模型选错了、框架不顺手、上下文管理一团糟然后推翻重来。所以我的建议是动手之前先想清楚下面几个问题。3.1 模型选型不能只看跑分六个维度综合权衡模型选型是LLM应用里最容易被低估的决策。很多人第一反应是哪个模型跑分高选哪个但实际工程里要考虑的远不止效果。我一般用六个维度来权衡维度关键问题实操建议效果在你具体任务上的表现不要只看榜单用你自己的数据抽测20条上下文长度能处理多长的文档和对话128K以上更从容但成本也更高推理成本每千token的价格高吞吐场景成本差异会非常大推理延迟首token时间、每秒生成速度实时交互场景要重点压测数据合规数据能否出域、能否私有化敏感场景必须本地部署生态兼容函数调用、流式、JSON模式支持Agent应用对工具调用要求高对大多数做产品验证的团队我的建议是先用一个成熟的商业API把端到端流程跑通验证业务价值再考虑是否能换开源模型私有化部署来降本。反过来如果产品对数据安全要求极高那从一开始就要把本地部署考虑进去选型范围会相应收缩。我自己经历过一次惨痛教训项目做到一半客户突然提了数据不出域的要求整个技术栈不得不推倒重选。这个事最好在需求阶段就问清楚。3.2 Prompt和上下文管理是工程资产不是随手写的几句话很多初学者以为Prompt就是给模型写一段话。实际上Prompt在工程里应当被当作一等公民来管理。我在项目里一般会这样做Prompt模板放在独立目录不硬编码在代码里方便改版本和做A/B。每个模板带版本号和变更记录线上效果出问题时能快速回滚。准备好几组典型输入每次改完模板就跑一遍回归。上下文管理方面要区分三类内容系统指令、检索回来的动态内容、历史对话。这三者各有优先级和放置顺序。我的经验做法是把系统指令放最前面明确告诉模型它的角色和规则检索内容紧跟其后作为参考资料历史对话放在最后。同时总的输入长度控制在模型上下文窗口的70%以内剩下30%留给生成空间避免模型有进无出。3.3 构建Agent的安全边界工具调用是核心突破口Agent类应用成败的关键往往在工具调用设计。工具定义得太粗模型不知道怎么用定义得太细模型规划步骤会爆炸。一般来说工具数量控制在5到10个比较合适。每个工具的description要写得极其明确包括它做什么、参数是什么、什么情况下不该用它。这一步偷懒的话模型就会乱调用工具生产事故就是这么来的。工具执行层还要做几道保险超时控制强制加幂等性设计必须考虑权限校验不能省。模型一旦调错真实系统会被误伤。比如你给Agent一个发送邮件的工具如果不校验收件人白名单和频率限制它可能连续发几十封垃圾邮件给你客户。这些细节在参考项目的源码里都能看到但只有自己踩过坑才会真正重视。4. 完整实操用一个RAG问答应用跑通全流程理论说得再多不如动手写一个。我拿一个典型的RAG问答应用做例子完整走一遍从环境准备到评测收敛的过程这套流程我在多个项目里验证过照着做基本不会跑偏。4.1 环境准备与框架选择技术栈上我推荐一套稳妥的组合Python 3.10以上依赖管理用uv或pip搜索引擎向量数据库先用轻量级的Chroma后期数据量大了再换MilvusEmbedding模型bge-m3或text-embedding-3-small兼顾效果和性价比LLM先用一个支持OpenAI兼容接口的API编排框架新手建议从LlamaIndex或原生代码入手LangChain虽然生态大但封装太多出了问题反而难追我的个人建议是如果你只做一个RAG问答完全可以手写核心代码不过一两百行。手写的最大好处是每一步都知道发生了什么出了问题能快速定位。框架适合在业务复杂起来之后再引入。4.2 数据准备和索引构建切块是门手艺活先处理原始文档。第一步是切块切块大小我一般用300到500个字符重叠50个字符。为什么是这个范围太小了语义不完整块与块之间是割裂的太大会超过embedding模型的有效处理范围检索精度下降。重叠是为了避免上下文在接头处断裂。具体大小可以根据你的文档类型调整——技术文档偏大一些对话记录偏小一些。切完块之后要做清洗去掉页眉页脚、多余换行、无意义的特殊符号。然后向量化入库。这里有个细节很容易被忽略除了存向量和原文文本一定要存metadata比如来源文档名、章节标题、页码、发布时间。这些信息后来在做引用标注和权限过滤时非常关键。没有metadata你的RAG回答就是无源之水用户问一句你凭什么这么说系统答不上来信任感瞬间崩塌。这是我踩坑换来的教训。我第一版RAG系统没存metadata回答正确率看着还行但一上内测就被同事问住了这段结论是哪份文档里的我只能尴尬地说我查查。后来加上metadata回答时携带来源整个产品才真正可用。4.3 检索、重排与生成一条完整的RAG链路查询阶段的流程是先把用户问题向量化从向量库里召回top-k我默认先取5再做重排序把最相关的3个片段拼进上下文最后交给LLM生成回答。可以用参考列表里常见项目的思路自己实现也很简单from openai import OpenAI from chromadb import PersistentClient client OpenAI() db PersistentClient(path./docs_db) collection db.get_or_create_collection(kb) def query_rag(question: str) - str: resp client.embeddings.create( modeltext-embedding-3-small, inputquestion ) qvec resp.data[0].embedding hits collection.query( query_embeddings[qvec], n_results5 ) # 重排序用交叉编码器或LLM对候选片段打分 reranked rerank(question, hits[documents][0]) top3 reranked[:3] context \n\n.join( f[来源{i1}]{doc} for i, doc in enumerate(top3) ) prompt f仅基于以下资料回答用户问题不要编造。资料中没有的信息明确回答“未找到”。回答末尾标注引用编号。 资料 {context} 问题{question} 回答 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content这里我要特别强调一下重排序环节。向量检索本质是语义近似它返回的结果相关性并不精确。我第一版没做重排序效果时好时坏后来加了交叉编码器重排后准确率提升非常明显。重排序比向量检索贵很多所以只作用在召回后的小候选集上性价比最高。插图RAG链路的四大环节示意图文档解析 → 向量化入库 → 召回重排 → 生成回答生成阶段的prompt设计也很关键。必须告诉模型只基于给定资料回答、资料中没有就如实说不知道、标注来源编号。温度参数调低设置为0.2左右让输出更稳。很多人喜欢让模型自由发挥但在RAG场景里自由发挥就意味着幻觉。4.4 搭建一个最小评测体系让优化有据可依评测是很多人会跳过的环节但它恰恰是LLM应用持续迭代的地基。没有评测你无法判断一次改动到底是变好了还是变差了。我的习惯是准备一个50到100条的评测集覆盖三类问题正常问题、边界问题资料里没有但要能拒答、带干扰信息的问题用户故意诱导模型别用资料。然后定期跑一遍看三个指标检索命中率正确的资料是否被召回到top-k里。这个指标衡量的是检索环节的健康度。回答准确率生成内容是否正确、完整。这可以人工评也可以让强模型打分。引用正确率回答中给出的来源编号是否真的对得上。这一点直接关系到产品的可信度。有了这三组数字你就能在改切块参数、换embedding模型、调重排策略之间做出理性判断而不是凭感觉拍脑袋。这是我做过那么多项目后认为最重要的习惯。5. 踩坑实录与高频问题速查最后这部分我把自己和社区里反复踩到的坑整理一下。LLM应用开发跟传统后端开发有一个很大的不同问题不是非黑即白的出故障了排查链条也长所以提前建立一套故障处理框架非常有用。5.1 幻觉问题不是一个Bug而是一个需要系统性解法的问题幻觉hallucination是LLM应用中最常被吐槽的问题但我要说一句幻觉不是Bug它是生成模型的固有属性。指望模型自己知道不知道是靠不住的系统的解法比模型自律更可靠。我在项目里的做法是层层设防第一层用RAG给足高质量上下文让模型没必要编第二层在prompt里明确资料里没有就答不知道弱化它自由发挥的冲动第三层对高风险场景强制要求引用来源没有引用就不给出答案第四层也是很多人会忽略的在入口处做拒答用户问的问题明显不在知识库范围内直接拦截不让模型回答。最后一道防线是加规则或小模型对输出做校验发现高置信度幻觉就退回重答。这一套组合拳下来幻觉率能压到可接受范围。5.2 上下文窗口与成本压力的平衡术上下文窗口越来越大的今天很多团队反而不舍得用因为窗口越大每轮请求的prompt费用越高。我在项目中一般这样优化系统指令只拼一次尽量把不动的部分放在前缀缓存里历史对话做摘要而非把所有原始对话全塞进去检索片段数量控制在2到3个多一个就是多一份钱对高频接口做流式输出首token快速返回会让用户感觉延迟低很多另外一个容易被忽视的点是模型的输入输出单位。有的供应商按输入、输出分开计费输出通常更贵。如果场景是长文本生成成本结构会完全不同。选型之前把账单模型预估清楚别等到月底看账单傻眼。5.3 安全合规与业务风险的边界LLM应用扩大了攻击面安全问题不能忽视。我在项目里至少会做这四件事第一对用户输入做注入防护防止忽略之前的指令这类提示词注入第二控制模型可调用的工具范围高危操作必须走人工审批第三对模型输出做敏感信息过滤防止私密数据被模型无意生成第四数据脱敏在数据准备阶段就做不要在生成阶段再补救。我见过一个真实案例某公司把内部文档接进RAG后没有做权限隔离导致低权限员工检索到了高权限文档的内容。这不是模型的错是系统权限设计缺失。RAG系统的数据访问权限必须在检索层控制而不是依赖模型去懂事。5.4 从Demo到生产最后一公里最容易翻车我把项目从demo推到生产环境的时候遇到的问题和开发阶段完全不同。demo阶段可以用任何向量数据库生产环境要考虑高可用和数据持久化demo阶段可以直接调模型API生产环境要做限流、熔断、重试和优雅降级。这些能力在参考列表的项目里很多都有现成实现但只有自己集成一遍才会理解为什么要有它们。印象最深的一次翻车是demo环境跑得好好的一上生产流量向量数据库并发一上来就超时。排查半天发现是没用连接池默认配置只允许有限并发。这种问题在设计阶段想不到只能靠压测暴露。所以我的建议是功能开发完成别急着上先做一轮压测和故障演练把可能挂掉的环节都打一遍。我个人在这些项目里反复体会最深的一点是LLM应用的复杂度不在软件里而在它的不确定性上——模型是不可靠的组件你要做的是用系统设计去包容它的不可靠。这个心态转换过来许多问题就会从模型为什么这么蠢变成我的系统为什么不聪明。心态对了剩下的就是工程问题而工程问题总是有解的。