我是在整理 GitHub Star 列表的时候翻到 awesome-llm-apps 这个仓库的。它表面上是一份链接清单但顺着目录一层层点进去会发现过去两年大模型应用开发领域几乎所有值得关注的方向都在这了。很多人拿到这种 awesome 仓库的第一反应是收藏然后就没有然后了。我想换一种打开方式不把它当书签而是当一张应用地图按图索骥去理解 LLM 到底是怎么落地的。这份清单为什么值得单独拿出来聊因为它不只是好用工具列表更像一个开源世界的活体样本。从最早的文本补全 Demo到后来的 RAG、Agent、多模态应用仓库里收录的项目变化基本就是 LLM 应用生态的编年史。对于正在做技术选型、准备从零搭一个 LLM 应用、或者想系统补齐大模型应用知识的人来说把这份仓库读透比乱刷几十篇教程都管用。1. awesome-llm-apps 到底收集了什么1.1 一份项目清单为什么值得专门研究很多人对 awesome 类仓库的印象是什么都往里塞含金量参差不齐。但 awesome-llm-apps 不太一样它的筛选标准偏务实收录的多半是能跑、有文档、有明确应用场景的项目。这意味着你可以把它当作一份经过社区筛选的参考实现目录而不是单纯的书签堆。我当时做的一件事是把仓库里的项目按核心能力重新归了一下类而不是按它原本的目录分类。归完类之后整个 LLM 应用开发的脉络就清晰了——无非是几件事让模型更会对话、让模型学会查资料、让模型能调用工具、让模型能自主完成任务、再把某一类任务做到极致。所谓 LLM 应用本质上就是这五类能力的排列组合。另外一个值得专门研究的原因是这类仓库里的项目大多标明了技术栈。你能看到同一个 RAG 需求有人用 LangChain 做有人用 LlamaIndex 做还有人完全自己写检索逻辑。横向对比这些实现能很快建立起什么场景配什么方案的直觉。这种直觉靠看文档是养不出来的必须看真实项目的取舍。1.2 从仓库结构看 LLM 应用生态的变化如果翻看过几个不同时期的 awesome 类仓库会发现一个明显的趋势早期收录的大多是怎么调用 API 做一个聊天机器人的教程型项目代码量很小核心就是拼接 Prompt、调用 Completion 接口。那时候大家还在解决能不能聊起来的问题。后来仓库里开始大量出现带数据库、带 Embedding、带检索链路的项目。这说明大家意识到光靠模型自身知识做问答幻觉和多轮一致性根本压不住必须把外部知识库接进来。再往后Agent 类项目爆发AutoGPT、MetaGPT、BabyAGI 这类名字频繁出现社区讨论的热词从 LLM 变成了 LLM Agent。现在的 awesome-llm-apps 里还能看到很多垂直行业应用比如法律文书审查、医疗问答、金融报表分析甚至智能家居控制。仓库目录结构的演进恰好对应了大模型应用的三次跃迁从直接问模型到让模型查了再答再到让模型自己决定怎么查、怎么答、怎么行动。理解了这条线再回头看那些五花八门的项目就不会觉得乱了。2. 从清单反推 LLM 应用的五种主流形态2.1 ChatBot基础但未必简单我在仓库里看到很多 ChatBot 项目第一反应是这有什么好收录的后来真去读了几个实现才发现把对话体验做好非常难。基础的 ChatBot 只需要维护 Prompt 和上下文窗口但生产级 ChatBot 要解决的问题包括多轮对话的上下文压缩、角色一致性、敏感内容过滤、超长对话的记忆管理还有流式输出的体验优化。一个容易被忽略的细节是上下文管理。大模型的上下文窗口是有限的对话轮次一多要么截断早期的内容要么做摘要压缩。很多开源项目在 Prompt 里用了一个很朴素但有效的策略早期完整对话保留中间对话做摘要最新对话全部保留。这个思路在生产环境里非常实用远比无脑加长上下文窗口省钱。2.2 RAG解决幻觉问题最务实的路径RAG检索增强生成几乎是现在 LLM 应用的事实标准。它的核心逻辑很简单模型回答问题之前先从外部知识库里检索相关内容把检索结果拼进 Prompt再让模型基于这些材料作答。这样模型的答案就有据可依幻觉问题能被压下去一大截。在 awesome-llm-apps 里RAG 类项目是最多的也最值得反复研究。有的是通用文档问答有的是企业知识库有的做到了多轮检索、重排序、混合检索。我强烈建议把其中一两个项目的源码完整读一遍尤其是看它的检索链路是怎么设计的——因为 RAG 的效果瓶颈通常不在模型而在检索质量。RAG 还有一个容易被低估的好处它让知识更新变得便宜。模型微调一次要花不少算力和数据准备时间而更新知识库只需要重新灌文档。很多企业上 LLM 的第一站选 RAG就是这个原因。2.3 Agent从会聊天到会做事LLM Agent 是现在热度最高的方向。它的核心机制是推理 行动循环模型先拆解任务决定调用哪个工具拿到工具返回的结果再决定下一步做什么直到任务完成。这个过程被称为 ReAct 模式。仓库里这类项目非常多但实现水平差距很大。我见过最简单的 Agent 只是一个 if-else 套 API 调用也见过复杂的多 Agent 协作系统。判断一个 Agent 实现好不好的关键不在于它调用了多少工具而在于它的规划能力和容错能力。规划能力决定任务拆解得好不好容错能力决定了当工具调用失败时Agent 是死循环还是能自我纠正。我的建议是先别急着上复杂框架自己用 200 行代码实现一个能调用两个工具的最小 Agent把模型返回的 Function Call 和工具执行结果之间的循环走通之后再去看框架的源码会轻松很多。2.4 自动化工作流把大模型嵌进业务流程工作流类应用和 Agent 的界限有些模糊但侧重点不一样。Agent 偏自主决策工作流偏确定执行。比如一个每周自动整理行业新闻并生成摘要邮件的任务用工作流实现就是固定步骤抓取 RSS - 清洗文本 - 调模型总结 - 格式化 - 发邮件。每一步都确定中途不需要 Agent 来做决策。这种应用的价值在于稳定和可控。在真实的业务场景里多数企业并不需要模型像人一样随机应变而是需要模型在预设的流程里稳定输出。awesome-llm-apps 里很多工业级项目都是这个思路它们把 LLM 当成流程中的一个算子而不是让 LLM 主导整个流程。2.5 多模态与垂直领域应用仓库里还有一批多模态应用比如文档图片解析、表格转结构化数据、流程图理解。这类应用的关键在于把非结构化数据转换成 LLM 能吃进去的结构化文本或向量。还有一批垂直领域应用比如法律、医疗、金融它们的共同特点是通用模型不够用必须叠加领域知识库、专用 Prompt 和严格的输出校验。垂直领域应用给我最大的启发是数据准备优先级高于一切。很多项目的时间分配是80% 花在数据采集、清洗和标注上20% 花在模型和提示词上。这跟很多人想象的调调模型就好完全不同。如果真想在某个行业落地 LLM先把数据工程做好比什么都重要。3. 面对一堆 awesome 项目怎么做出选型3.1 框架选择的三个判断标准看着仓库里几十个框架很容易陷入选择困难。我的判断标准只有三个第一社区活跃度。一个框架 Star 数多少不是最关键的关键是最近三个月有没有持续提交Issue 有没有人回应。LLM 领域变化太快没人维护的框架三个月就废了。第二抽象层次是否匹配。LangChain 提供了非常高的抽象链、代理、内存、检索器都封装好了适合快速搭建原型。LlamaIndex 更偏数据和索引适合做知识库类应用。如果你想完全掌控每一步那就自己写主流程只借用向量数据库这类底层组件。第三是否容易调试。LLM 应用最大的问题是黑盒一旦效果不好你要能快速定位是 Prompt 的问题、检索的问题还是后处理的问题。框架如果能提供详细的日志和中间结果输出调试成本会低很多。3.2 什么时候可以自研、什么时候必须借框架我的经验是玩原型、验证想法大胆用框架因为快。上生产、控成本、追性能谨慎用框架因为框架在你和模型之间加了一层又一层封装出了问题很难排查。打个比方框架像是装修公司的全包服务你提需求它交付结果过程你基本不用管。但当你想换特殊材料、改特殊结构时全包服务的灵活性就不够了。自研则是自己当工长每个环节都清楚但前期的学习成本和沟通成本都很高。一个折中方案是半自研用成熟的向量数据库和模型 SDK但检索逻辑、Prompt 组装、输出解析都自己写。这个方案在 awesome-llm-apps 的很多高质量项目里非常常见。它们看起来没用大框架架构反而清爽出问题也容易定位。3.3 数据准备的优先级高于模型选择很多人一开始就纠结用哪个模型是 GPT 还是开源模型参数要 7B 还是 70B。但真做下来你会发现模型之间的效果差异远小于数据干净不干净带来的差异。一个文档问答应用如果文档切分合理、Embedding 质量高、检索排序调得好哪怕用一个较小的模型也能答得很不错。反过来数据一团糟文档里全是扫描件的 OCR 错误标题和正文混在一起再大的模型也救不回来。所以我的建议是选型阶段先把数据流程打通跑通一个最小闭环再回头换模型。不要先在模型上花一周时间最后发现数据根本喂不进去。4. 亲手复现一个 RAG 应用一次完整的落地过程光看仓库里的项目不自己动手跑一遍始终是纸上谈兵。下面我以最典型的 RAG 文档问答为例完整走一遍从环境准备到效果调优的过程。4.1 环境准备和模型选型复现 RAG 应用第一步是确定运行环境。我的建议是如果有 GPU哪怕只有一张 8G 显存的卡也可以跑 7B 级别的开源模型。如果没有 GPU先用 API 方式调用云端模型跑通流程之后再考虑本地部署。向量数据库先用 FAISS它是纯本地的安装简单等数据量上到百万级再换 Milvus 或 Qdrant。我这次复现用的是国产开源模型加 FAISS没有用任何重型框架主流程全部自己写。这样做的好处是每一步发生了什么我心里都有数。4.2 文档处理三件套加载、分块、清洗加载这一步是从 PDF、Word、网页里把文本抽出来。看起来简单但坑很多PDF 可能是扫描件需要 OCR网页有大量导航和广告需要正文抽取Word 里可能嵌了表格直接抽文本会失去结构。分块是最影响效果的一步。常见策略是固定字符数切片比如每 500 个字符切一块块间重叠 50 字符。但更推荐按语义边界切比如按标题、段落、句子切。因为固定长度硬切会把一句话拦腰截断检索到的是残缺内容生成质量必然受影响。我做分块时的伪代码大概是这样的from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, separators[\n\n, \n, 。, , , ., , ], ) chunks splitter.split_text(article)这里的核心技巧是 separators 的顺序优先级高的分隔符先尝试尽量保证一个块内是完整的语义单元。chunk_overlap 的作用是让上下文在边界处有交叉避免信息断档。清洗常常被忽略。我见过一个项目清洗前和清洗后的检索准确率差了近 20 个百分点。清洗至少要做这几件事去掉页眉页脚和页码、修正 OCR 常见的误识字符、统一全半角、去掉零宽字符和乱码。这些活儿不性感但特别值钱。4.3 向量化、入库和检索文本分好块之后每一块要转成向量。Embedding 模型的选择直接决定检索效果。中英文混合文档我一般先拿几组真实 query 去测不同 Embedding 模型的召回率而不是无脑选参数量最大的。向量入库的代码相对简单import faiss from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh-v1.5) vectors model.encode(chunks, normalize_embeddingsTrue) index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors)检索时有一个关键步骤叫重排序。第一轮向量检索召回前 20 条候选再用一个重排序模型精排取前 3-5 条作为最终上下文。重排序的效果往往是立竿见影的它能显著提升最终答案的准确率。4.4 组装生成链路检索到相关内容后把内容组装进 Prompt让模型输出答案。这一步的关键是明确告诉模型只能根据提供的材料回答不要推测如果材料里没有答案要承认不知道。我常用的 Prompt 模板大概是请根据以下材料回答问题。如果材料中没有足够信息请直接回答材料中未提及不要编造。 材料 {context} 问题{question}注意三件事第一把问题和材料放在最后避免长上下文中材料被淹没第二要求模型引用材料中的关键句子方便追溯第三设置拒绝回答路径这是抑制幻觉的最后一道防线。4.5 效果评估和调优很多人跑通流程就完事了从不评估效果。这是 RAG 应用上不了线的最大原因。至少要准备一个几十条问题的评测集每条问题标注标准答案然后跑一遍算三个指标召回率正确的上下文有没有被检索出来。准确率最终答案对不对。引用率模型有没有忠实引用了材料。评测完如果发现答案不行按这个顺序排查先看检索回来的上下文对不对再改分块和 Embedding如果上下文没问题但答案不对再改 Prompt 和后处理。千万不要一上来就换模型那是效率最低的调优方式。5. 部署阶段遇到的实际问题5.1 显存不够和推理速度慢本地部署开源模型时最头疼的就是显存。7B 模型用 FP16 精度大概要 14G 显存很多人只有 8G 卡。解决办法是量化把模型量化到 INT4显存占用直接减半效果损失基本可接受。推理速度是另一个问题。小模型流式输出还好一旦并发上来单卡很快被打满。我的经验是先用并发压测工具测出单实例的极限 QPS。再根据业务的峰值流量反推需要几个实例。能走 API 就尽量走 API自己的 GPU 主要用于定制化场景。5.2 流式输出的坑LLM 应用现在几乎都要求流式输出就是一个字一个字地蹦出来。流式怎么实现不难难的是和前端配合。一个常见问题是后端把整段话缓存好了才发送前端拿到的是完整答案但已停止输入的指示是流式的导致用户以为还在生成。另一个问题是 SSEServer-Sent Events连接在中间挂了前端没有重连策略交互直接卡死。我的建议是流式协议尽早定好字段、事件类型、结束标志都写在接口文档里。前后端对不上调试成本极高。5.3 成本和预算控制大模型应用的成本大头在推理。很多人上线后才发现一个文档问答用户问一个问题背后其实是两次模型调用一次是生成答案一次是判断回答是否安全和准确。如果加上重排序、摘要、意图识别一次请求可能触发四五次模型调用成本直接翻几倍。控制成本有几个实用手段第一设置单用户限流和日调用上限第二对高频问题做缓存相似 query 直接命中缓存不重复调模型第三系统提示词和上下文尽量精简Token 就是钱。5.4 日志是排查问题最重要的依据LLM 应用的日志比传统应用更重要因为你的系统里有大量不确定性。除了常规的请求日志和错误日志我强烈建议把每次请求的 Prompt、检索到的上下文、模型原始输出都打出来。这样出了问题才能回溯到底是检索错了还是模型生成错了。我一直用一个字段记录追溯信息用户问题、检索上下文 ID、Prompt 版本、模型版本、耗时、Token 数。有了这些排查线上问题的效率能提升一大截。6. 我的体会和给新手的一点建议6.1 做应用和调模型是两件完全不同的事这是我在翻完 awesome-llm-apps 之后最大的感触。很多人一上来就钻研模型训练、微调、损失函数但真实世界里的 LLM 应用更多是在解决工程问题数据怎么清洗检索怎么设计服务怎么部署成本怎么控制。模型本身只是一个被调用的组件真正决定应用上限的是环绕在模型周围的工程系统。这解释了为什么仓库里那么多成功项目用的模型未必是最强的但工程链路一定是扎实的。如果你想把 LLM 落地优先补工程能力而不是扎进预训练和损失函数里。当然如果目标是做模型本身那是另一条路。6.2 把 awesome-llm-apps 用起来的正确姿势最后分享一个把这种资源仓库用起来的实操方法。不要从头到尾当成文档读那样读不完也记不住。我的方法是先快速扫一遍项目名把感兴趣的挑出来然后挑一个和你当前需求最接近的把它跑起来读源码里你最关心的那部分接着改一改加上你自己的数据或需求看它能不能跑通最后把它拆了用你自己的方式重写一遍。这个过程走三遍你对 LLM 应用的理解就会远超那些只看不练的人。awesome-llm-apps 的价值不在链接本身而在于它给你划出了一个个可以下钻的坐标。真正动手时你会发现LLM 应用的难点从来不是模型能力而是如何把一个模糊的业务需求翻译成一条条可验证的工程链路。这个能力没有捷径只能靠一个个项目喂出来。
从 awesome-llm-apps 看大模型应用的五大落地形态与工程实践
我是在整理 GitHub Star 列表的时候翻到 awesome-llm-apps 这个仓库的。它表面上是一份链接清单但顺着目录一层层点进去会发现过去两年大模型应用开发领域几乎所有值得关注的方向都在这了。很多人拿到这种 awesome 仓库的第一反应是收藏然后就没有然后了。我想换一种打开方式不把它当书签而是当一张应用地图按图索骥去理解 LLM 到底是怎么落地的。这份清单为什么值得单独拿出来聊因为它不只是好用工具列表更像一个开源世界的活体样本。从最早的文本补全 Demo到后来的 RAG、Agent、多模态应用仓库里收录的项目变化基本就是 LLM 应用生态的编年史。对于正在做技术选型、准备从零搭一个 LLM 应用、或者想系统补齐大模型应用知识的人来说把这份仓库读透比乱刷几十篇教程都管用。1. awesome-llm-apps 到底收集了什么1.1 一份项目清单为什么值得专门研究很多人对 awesome 类仓库的印象是什么都往里塞含金量参差不齐。但 awesome-llm-apps 不太一样它的筛选标准偏务实收录的多半是能跑、有文档、有明确应用场景的项目。这意味着你可以把它当作一份经过社区筛选的参考实现目录而不是单纯的书签堆。我当时做的一件事是把仓库里的项目按核心能力重新归了一下类而不是按它原本的目录分类。归完类之后整个 LLM 应用开发的脉络就清晰了——无非是几件事让模型更会对话、让模型学会查资料、让模型能调用工具、让模型能自主完成任务、再把某一类任务做到极致。所谓 LLM 应用本质上就是这五类能力的排列组合。另外一个值得专门研究的原因是这类仓库里的项目大多标明了技术栈。你能看到同一个 RAG 需求有人用 LangChain 做有人用 LlamaIndex 做还有人完全自己写检索逻辑。横向对比这些实现能很快建立起什么场景配什么方案的直觉。这种直觉靠看文档是养不出来的必须看真实项目的取舍。1.2 从仓库结构看 LLM 应用生态的变化如果翻看过几个不同时期的 awesome 类仓库会发现一个明显的趋势早期收录的大多是怎么调用 API 做一个聊天机器人的教程型项目代码量很小核心就是拼接 Prompt、调用 Completion 接口。那时候大家还在解决能不能聊起来的问题。后来仓库里开始大量出现带数据库、带 Embedding、带检索链路的项目。这说明大家意识到光靠模型自身知识做问答幻觉和多轮一致性根本压不住必须把外部知识库接进来。再往后Agent 类项目爆发AutoGPT、MetaGPT、BabyAGI 这类名字频繁出现社区讨论的热词从 LLM 变成了 LLM Agent。现在的 awesome-llm-apps 里还能看到很多垂直行业应用比如法律文书审查、医疗问答、金融报表分析甚至智能家居控制。仓库目录结构的演进恰好对应了大模型应用的三次跃迁从直接问模型到让模型查了再答再到让模型自己决定怎么查、怎么答、怎么行动。理解了这条线再回头看那些五花八门的项目就不会觉得乱了。2. 从清单反推 LLM 应用的五种主流形态2.1 ChatBot基础但未必简单我在仓库里看到很多 ChatBot 项目第一反应是这有什么好收录的后来真去读了几个实现才发现把对话体验做好非常难。基础的 ChatBot 只需要维护 Prompt 和上下文窗口但生产级 ChatBot 要解决的问题包括多轮对话的上下文压缩、角色一致性、敏感内容过滤、超长对话的记忆管理还有流式输出的体验优化。一个容易被忽略的细节是上下文管理。大模型的上下文窗口是有限的对话轮次一多要么截断早期的内容要么做摘要压缩。很多开源项目在 Prompt 里用了一个很朴素但有效的策略早期完整对话保留中间对话做摘要最新对话全部保留。这个思路在生产环境里非常实用远比无脑加长上下文窗口省钱。2.2 RAG解决幻觉问题最务实的路径RAG检索增强生成几乎是现在 LLM 应用的事实标准。它的核心逻辑很简单模型回答问题之前先从外部知识库里检索相关内容把检索结果拼进 Prompt再让模型基于这些材料作答。这样模型的答案就有据可依幻觉问题能被压下去一大截。在 awesome-llm-apps 里RAG 类项目是最多的也最值得反复研究。有的是通用文档问答有的是企业知识库有的做到了多轮检索、重排序、混合检索。我强烈建议把其中一两个项目的源码完整读一遍尤其是看它的检索链路是怎么设计的——因为 RAG 的效果瓶颈通常不在模型而在检索质量。RAG 还有一个容易被低估的好处它让知识更新变得便宜。模型微调一次要花不少算力和数据准备时间而更新知识库只需要重新灌文档。很多企业上 LLM 的第一站选 RAG就是这个原因。2.3 Agent从会聊天到会做事LLM Agent 是现在热度最高的方向。它的核心机制是推理 行动循环模型先拆解任务决定调用哪个工具拿到工具返回的结果再决定下一步做什么直到任务完成。这个过程被称为 ReAct 模式。仓库里这类项目非常多但实现水平差距很大。我见过最简单的 Agent 只是一个 if-else 套 API 调用也见过复杂的多 Agent 协作系统。判断一个 Agent 实现好不好的关键不在于它调用了多少工具而在于它的规划能力和容错能力。规划能力决定任务拆解得好不好容错能力决定了当工具调用失败时Agent 是死循环还是能自我纠正。我的建议是先别急着上复杂框架自己用 200 行代码实现一个能调用两个工具的最小 Agent把模型返回的 Function Call 和工具执行结果之间的循环走通之后再去看框架的源码会轻松很多。2.4 自动化工作流把大模型嵌进业务流程工作流类应用和 Agent 的界限有些模糊但侧重点不一样。Agent 偏自主决策工作流偏确定执行。比如一个每周自动整理行业新闻并生成摘要邮件的任务用工作流实现就是固定步骤抓取 RSS - 清洗文本 - 调模型总结 - 格式化 - 发邮件。每一步都确定中途不需要 Agent 来做决策。这种应用的价值在于稳定和可控。在真实的业务场景里多数企业并不需要模型像人一样随机应变而是需要模型在预设的流程里稳定输出。awesome-llm-apps 里很多工业级项目都是这个思路它们把 LLM 当成流程中的一个算子而不是让 LLM 主导整个流程。2.5 多模态与垂直领域应用仓库里还有一批多模态应用比如文档图片解析、表格转结构化数据、流程图理解。这类应用的关键在于把非结构化数据转换成 LLM 能吃进去的结构化文本或向量。还有一批垂直领域应用比如法律、医疗、金融它们的共同特点是通用模型不够用必须叠加领域知识库、专用 Prompt 和严格的输出校验。垂直领域应用给我最大的启发是数据准备优先级高于一切。很多项目的时间分配是80% 花在数据采集、清洗和标注上20% 花在模型和提示词上。这跟很多人想象的调调模型就好完全不同。如果真想在某个行业落地 LLM先把数据工程做好比什么都重要。3. 面对一堆 awesome 项目怎么做出选型3.1 框架选择的三个判断标准看着仓库里几十个框架很容易陷入选择困难。我的判断标准只有三个第一社区活跃度。一个框架 Star 数多少不是最关键的关键是最近三个月有没有持续提交Issue 有没有人回应。LLM 领域变化太快没人维护的框架三个月就废了。第二抽象层次是否匹配。LangChain 提供了非常高的抽象链、代理、内存、检索器都封装好了适合快速搭建原型。LlamaIndex 更偏数据和索引适合做知识库类应用。如果你想完全掌控每一步那就自己写主流程只借用向量数据库这类底层组件。第三是否容易调试。LLM 应用最大的问题是黑盒一旦效果不好你要能快速定位是 Prompt 的问题、检索的问题还是后处理的问题。框架如果能提供详细的日志和中间结果输出调试成本会低很多。3.2 什么时候可以自研、什么时候必须借框架我的经验是玩原型、验证想法大胆用框架因为快。上生产、控成本、追性能谨慎用框架因为框架在你和模型之间加了一层又一层封装出了问题很难排查。打个比方框架像是装修公司的全包服务你提需求它交付结果过程你基本不用管。但当你想换特殊材料、改特殊结构时全包服务的灵活性就不够了。自研则是自己当工长每个环节都清楚但前期的学习成本和沟通成本都很高。一个折中方案是半自研用成熟的向量数据库和模型 SDK但检索逻辑、Prompt 组装、输出解析都自己写。这个方案在 awesome-llm-apps 的很多高质量项目里非常常见。它们看起来没用大框架架构反而清爽出问题也容易定位。3.3 数据准备的优先级高于模型选择很多人一开始就纠结用哪个模型是 GPT 还是开源模型参数要 7B 还是 70B。但真做下来你会发现模型之间的效果差异远小于数据干净不干净带来的差异。一个文档问答应用如果文档切分合理、Embedding 质量高、检索排序调得好哪怕用一个较小的模型也能答得很不错。反过来数据一团糟文档里全是扫描件的 OCR 错误标题和正文混在一起再大的模型也救不回来。所以我的建议是选型阶段先把数据流程打通跑通一个最小闭环再回头换模型。不要先在模型上花一周时间最后发现数据根本喂不进去。4. 亲手复现一个 RAG 应用一次完整的落地过程光看仓库里的项目不自己动手跑一遍始终是纸上谈兵。下面我以最典型的 RAG 文档问答为例完整走一遍从环境准备到效果调优的过程。4.1 环境准备和模型选型复现 RAG 应用第一步是确定运行环境。我的建议是如果有 GPU哪怕只有一张 8G 显存的卡也可以跑 7B 级别的开源模型。如果没有 GPU先用 API 方式调用云端模型跑通流程之后再考虑本地部署。向量数据库先用 FAISS它是纯本地的安装简单等数据量上到百万级再换 Milvus 或 Qdrant。我这次复现用的是国产开源模型加 FAISS没有用任何重型框架主流程全部自己写。这样做的好处是每一步发生了什么我心里都有数。4.2 文档处理三件套加载、分块、清洗加载这一步是从 PDF、Word、网页里把文本抽出来。看起来简单但坑很多PDF 可能是扫描件需要 OCR网页有大量导航和广告需要正文抽取Word 里可能嵌了表格直接抽文本会失去结构。分块是最影响效果的一步。常见策略是固定字符数切片比如每 500 个字符切一块块间重叠 50 字符。但更推荐按语义边界切比如按标题、段落、句子切。因为固定长度硬切会把一句话拦腰截断检索到的是残缺内容生成质量必然受影响。我做分块时的伪代码大概是这样的from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, separators[\n\n, \n, 。, , , ., , ], ) chunks splitter.split_text(article)这里的核心技巧是 separators 的顺序优先级高的分隔符先尝试尽量保证一个块内是完整的语义单元。chunk_overlap 的作用是让上下文在边界处有交叉避免信息断档。清洗常常被忽略。我见过一个项目清洗前和清洗后的检索准确率差了近 20 个百分点。清洗至少要做这几件事去掉页眉页脚和页码、修正 OCR 常见的误识字符、统一全半角、去掉零宽字符和乱码。这些活儿不性感但特别值钱。4.3 向量化、入库和检索文本分好块之后每一块要转成向量。Embedding 模型的选择直接决定检索效果。中英文混合文档我一般先拿几组真实 query 去测不同 Embedding 模型的召回率而不是无脑选参数量最大的。向量入库的代码相对简单import faiss from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh-v1.5) vectors model.encode(chunks, normalize_embeddingsTrue) index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors)检索时有一个关键步骤叫重排序。第一轮向量检索召回前 20 条候选再用一个重排序模型精排取前 3-5 条作为最终上下文。重排序的效果往往是立竿见影的它能显著提升最终答案的准确率。4.4 组装生成链路检索到相关内容后把内容组装进 Prompt让模型输出答案。这一步的关键是明确告诉模型只能根据提供的材料回答不要推测如果材料里没有答案要承认不知道。我常用的 Prompt 模板大概是请根据以下材料回答问题。如果材料中没有足够信息请直接回答材料中未提及不要编造。 材料 {context} 问题{question}注意三件事第一把问题和材料放在最后避免长上下文中材料被淹没第二要求模型引用材料中的关键句子方便追溯第三设置拒绝回答路径这是抑制幻觉的最后一道防线。4.5 效果评估和调优很多人跑通流程就完事了从不评估效果。这是 RAG 应用上不了线的最大原因。至少要准备一个几十条问题的评测集每条问题标注标准答案然后跑一遍算三个指标召回率正确的上下文有没有被检索出来。准确率最终答案对不对。引用率模型有没有忠实引用了材料。评测完如果发现答案不行按这个顺序排查先看检索回来的上下文对不对再改分块和 Embedding如果上下文没问题但答案不对再改 Prompt 和后处理。千万不要一上来就换模型那是效率最低的调优方式。5. 部署阶段遇到的实际问题5.1 显存不够和推理速度慢本地部署开源模型时最头疼的就是显存。7B 模型用 FP16 精度大概要 14G 显存很多人只有 8G 卡。解决办法是量化把模型量化到 INT4显存占用直接减半效果损失基本可接受。推理速度是另一个问题。小模型流式输出还好一旦并发上来单卡很快被打满。我的经验是先用并发压测工具测出单实例的极限 QPS。再根据业务的峰值流量反推需要几个实例。能走 API 就尽量走 API自己的 GPU 主要用于定制化场景。5.2 流式输出的坑LLM 应用现在几乎都要求流式输出就是一个字一个字地蹦出来。流式怎么实现不难难的是和前端配合。一个常见问题是后端把整段话缓存好了才发送前端拿到的是完整答案但已停止输入的指示是流式的导致用户以为还在生成。另一个问题是 SSEServer-Sent Events连接在中间挂了前端没有重连策略交互直接卡死。我的建议是流式协议尽早定好字段、事件类型、结束标志都写在接口文档里。前后端对不上调试成本极高。5.3 成本和预算控制大模型应用的成本大头在推理。很多人上线后才发现一个文档问答用户问一个问题背后其实是两次模型调用一次是生成答案一次是判断回答是否安全和准确。如果加上重排序、摘要、意图识别一次请求可能触发四五次模型调用成本直接翻几倍。控制成本有几个实用手段第一设置单用户限流和日调用上限第二对高频问题做缓存相似 query 直接命中缓存不重复调模型第三系统提示词和上下文尽量精简Token 就是钱。5.4 日志是排查问题最重要的依据LLM 应用的日志比传统应用更重要因为你的系统里有大量不确定性。除了常规的请求日志和错误日志我强烈建议把每次请求的 Prompt、检索到的上下文、模型原始输出都打出来。这样出了问题才能回溯到底是检索错了还是模型生成错了。我一直用一个字段记录追溯信息用户问题、检索上下文 ID、Prompt 版本、模型版本、耗时、Token 数。有了这些排查线上问题的效率能提升一大截。6. 我的体会和给新手的一点建议6.1 做应用和调模型是两件完全不同的事这是我在翻完 awesome-llm-apps 之后最大的感触。很多人一上来就钻研模型训练、微调、损失函数但真实世界里的 LLM 应用更多是在解决工程问题数据怎么清洗检索怎么设计服务怎么部署成本怎么控制。模型本身只是一个被调用的组件真正决定应用上限的是环绕在模型周围的工程系统。这解释了为什么仓库里那么多成功项目用的模型未必是最强的但工程链路一定是扎实的。如果你想把 LLM 落地优先补工程能力而不是扎进预训练和损失函数里。当然如果目标是做模型本身那是另一条路。6.2 把 awesome-llm-apps 用起来的正确姿势最后分享一个把这种资源仓库用起来的实操方法。不要从头到尾当成文档读那样读不完也记不住。我的方法是先快速扫一遍项目名把感兴趣的挑出来然后挑一个和你当前需求最接近的把它跑起来读源码里你最关心的那部分接着改一改加上你自己的数据或需求看它能不能跑通最后把它拆了用你自己的方式重写一遍。这个过程走三遍你对 LLM 应用的理解就会远超那些只看不练的人。awesome-llm-apps 的价值不在链接本身而在于它给你划出了一个个可以下钻的坐标。真正动手时你会发现LLM 应用的难点从来不是模型能力而是如何把一个模糊的业务需求翻译成一条条可验证的工程链路。这个能力没有捷径只能靠一个个项目喂出来。