BLLM / ALLM – before and after LLM。这个标题我想了很久最后还是决定用最直白的方式聊。作为一个从2018年就开始做文本处理、最近三年又一头扎进大模型落地项目的开发者我太有资格说这个话题了。LLM不是突然冒出来的它是前面十几年NLP技术积累到一定程度之后的质变。很多人现在只看到LLM的“神”却不太了解LLM之前那个“人”的时代也不太清楚这个分水岭到底切在了哪里。这篇文章我想把BLLMBefore LLM和ALLMAfter LLM两个阶段放在一起对比着写从技术原理、工程架构、开发方式、部署运维到个人技能树的变化全部摊开来讲。不管你是刚准备入坑大模型的新人还是想给老旧系统做LLM化改造的工程师或者是被老板一句话“把AI加上去”砸中的倒霉蛋这篇文章都能给你一些真实可用的参考。内容会有点长但我尽量不写废话。1. BLLM时代LLM出现之前我们是怎么做文本理解的1.1 传统NLP流水线从分词到词向量先说BLLM时代。那时候我们做一个文本理解任务流程跟做菜一样得一步一步来。第一步分词中文比英文麻烦还得专门选分词工具jieba、HanLP、LTP换着用。分完词要去做去停用词、词性标注然后再把词变成向量。向量化这块经历过几个阶段最早的one-hot稀疏向量就是给每个词发一个身份证号维度爆炸还看不出词和词之间的关系。后来有了Word2Vec、GloVe这类静态词向量能算出“国王-男人女人女王”这种经典关系了但一个词不论在什么语境下都只有一个向量遇到“苹果”这种词就抓瞎到底是水果还是手机模型不知道。2018年BERT出来之后大家都觉得“动态词向量”这波稳了。BERT会根据上下文给每个token生成不同的向量表示解决了多义词问题在大量任务上刷新了SOTA。但是注意BERT本质上还是一个“编码器”它擅长的是把文本变成好的向量然后接一个简单的分类头去干活。要做生成任务还是得靠GPT、T5这类“编码器-解码器”或者纯“解码器”架构。那个年代如果你想做一个能自动写文案、自动回答问题的系统要么用生成式模型一篇一篇微调要么用检索式方案从库里找现成答案效果都挺拧巴。1.2 模型选型与标注地狱BERT微调统治的几年BLLM时代最让人崩溃的不是模型本身而是数据标注。我2019年做过一个工单自动分类项目业务方给了两万条工单要分成37类。我们找了三个标注员标了一个月中间开会对了三轮标准最后一致率勉强到85%。就这质量的数据喂给BERT微调上线之后准确率92%听起来不错吧但剩下的8%在业务场景里全是投诉重灾区。而且每换一个业务域、每加一个类别就得重新标数据、重新训练一次微调流程跑下来光卡点至少两三周。更别说领域数据涉及隐私不能出内网只能在内部那几台V100上排队训。那时候我经常半夜起来看训练日志看到loss曲线抖一下就心头一紧。除了标注还有特征工程的隐性成本。分类任务还好BERT直接吃文本。但很多传统NLP任务还是依赖人工特征比如做命名实体识别要拼词典、做规则、搞词边界特征做关系抽取甚至要依赖句法依存树。这些特征工程的经验非常值钱但也非常脆弱换一个领域就基本归零。我做过的几个项目里最耗时间的不是模型训练而是“清洗数据-标数据-抽特征-调规则”这个循环模型本身反而像个任人打扮的小姑娘谁的特征好她就听谁的。1.3 那时候的工程架构模型端和推理端长什么样BLLM时代的工程架构跟现在比简直像两个物种。模型端我们一般用PyTorch或者TensorFlow写好训练脚本挂在GPU服务器上跑用TensorBoard盯着loss。训练完的产物是一个model.pt或者saved_model.pb文件再配一个tokenizer、label_map.json、config.json这一坨东西就是“模型端”的全部。交付给线上服务时用Flask或FastAPI包一层HTTP接口或者用TensorFlow Serving、TorchServe做标准推理服务这部分就是“推理端”。推理端的优化逻辑和现在也挺不一样。因为BERT这种模型size在110M到340M之间单张GPU卡能塞下主要瓶颈是batch里的padding浪费和CPU端的预处理。那时候流行做动态batch、按长度排序、TensorRT加速还有蒸馏成小模型。我记得很清楚有个项目要把BERT-base蒸馏成TinyBERT蒸馏完精度掉了1.2个点但推理速度从25ms降到6ms业务方特别满意。这种“模型变小、精度换速度”的玩法现在在LLM时代反而不太常用了因为小模型在生成能力上和几百B的大模型差距太大蒸馏的门槛也高了很多。还有一个关键差异BLLM时代的模型是“专用”的。一个分类模型只能分类一个实体识别模型只能识别实体一个摘要模型只能做摘要。如果你想做一个大而全的智能客服得把意图分类、实体抽取、FAQ检索、话术生成好几个模型串起来每个模型单独部署、单独维护、单独监控。整个系统的复杂度随着模块数量指数上涨线上出一个问题排查链路比破案还难。2. ALLM时代大模型把整条流水线压成了一次推理2.1 从“训练模型”到“设计提示词”核心技能迁移GPT-3在2020年发布的时候说实话我还没太当回事觉得就是个会接话茬的玩具。直到2022年底ChatGPT出来我才意识到这东西不是“又一个大模型”而是“NLP的终结者”。为什么这么说因为LLM把所有曾经需要单独训练的NLP任务全部吸收进了同一个模型里。分类你给它几个例子它就会分类。抽取你告诉它要抽什么字段它就给你JSON。摘要、改写、翻译、问答、生成……全都不需要单独训了你只需要写提示词。这意味着什么意味着过去那套“数据标注特征工程模型微调单独部署”的技能树一下子变成了“提示词设计上下文管理输出约束”的新技能树。我见过最极端的例子有个同事压根没学过机器学习但因为英语好、逻辑清晰、擅长写prompt做的LLM应用效果比有些算法工程师还好。当然我不是说算法功底没用了调优RAG、做模型微调、优化推理这些照样需要硬功夫。但“用LLM解决一个文本任务”的门槛确实从“需要几个月的数据和训练”降到了“需要一下午写prompt和调试”这个变化是真真切切的。还有一点很重要ALLM时代错误模式和调试方式也变了。BLLM时代模型出错往往是“学偏了”你需要去看训练数据哪里不对、特征哪里冲突。ALLM时代模型出错往往是“理解偏了”你需要去调整提示词的措辞、示例的排列、少样本的选取。有一次我让LLM从合同里抽取甲方乙方和金额它总把“甲方委托乙方”里的“乙方”当成甲方。后来我在prompt里加了一条“注意甲方是出钱的一方乙方是干活的一方”再给了三个极端例子准确率直接上来了。这种调试方式在BLLM时代是不可想象的因为模型权重是固定的你只能通过调整输入文本去影响它的行为这反而是更纯粹的“自然语言编程”。2.2 推理端成为主战场显存、吞吐、延迟ALLM时代模型端和推理端的概念还在但内容和地位完全变了。模型端从“训练一个专用小模型”变成了“选择或微调一个通用大模型”普通人基本不再有从头训练的选项——几百B参数的模型预训练成本是千万美元量级不是一般公司能碰的。于是开源社区撑起了模型端的大旗Llama、Qwen、Mistral、DeepSeek这些开源模型让普通人也能拥有一线大模型权重。而个人和公司真正花时间最多的是推理端。推理端的核心矛盾是显存放不下、吞吐上不去、延迟压不住。一个7B模型FP16精度下光权重就要14GB加上KV cache和中间激活一张24GB的消费级显卡勉强能跑但并发一高就卡死。如果是70B模型FP16权重要140GB至少四张A100 80G才能塞下还得做张量并行。推理框架也随之爆发llama.cpp用GGUF量化格式让CPU也能跑模型Ollama把本地部署简化成了三条命令vLLM用PagedAttention把吞吐提升了好几倍还有TensorRT-LLM、TGI、SGLang这些专业推理服务。这里面的选型逻辑我放在后面实操部分细讲这里先记住一个结论ALLM时代的推理端优化性价比最高的手段就是量化批处理而不是去改模型。再有一点ALLM时代多了一个BLLM时代少有的问题输出不确定性。同一个prompt同一条输入两次请求的结果可能不一样。这对上层应用是非常棘手的你没法用“精确匹配”去做自动化测试。所以现在工程上普遍引入了temperature0、seed固定、结构化输出JSON mode、function calling这些手段尽可能让模型“稳定发挥”。我在生产环境里基本把temperature设为0.1到0之间虽然牺牲一点多样性但换来了可复现性这对做应用的人来说太重要了。2.3 RAG出现之后知识库的玩法彻底变了RAG检索增强生成是ALLM时代最出圈的技术方案没有之一。它的出现直接回答了一个致命问题LLM的知识截止到训练数据那一刻你问它最新的事情、问它你们公司的内部制度它只会一本正经地胡编。RAG的思路特别好懂LLM不知道答案没关系你先从外部知识库检索出相关内容再把这段内容塞进prompt里让模型“读着资料回答问题”。这样一来知识库是活的了改一条文档第二天系统就生效终于不用为了更新知识去重新训练模型了。BLLM时代我们也有检索系统最典型的是Elasticsearch做全文检索或者用向量召回把文本embedding成向量然后算相似度。但那时候检索和生成是两套独立的系统检索出来的东西顶多作为“候选推荐”展示给用户生成也不看检索结果。RAG把这两者焊死了检索出的片段进入了生成模型的上下文模型的回答必须基于这些片段否则就是“无源之水”。这背后的Prompt结构通常是系统指令检索到的参考资料用户问题输出要求。有一个细节很关键检索结果的质量直接决定回答质量。如果检回来10段内容8段是无关的模型很容易被带偏所以RAG的上限其实由检索环节决定LLM只是把检索结果“翻译”成了人话。这也是为什么现在大家越来越重视embedding模型选型、切分策略、重排模型一套组合拳下来才叫完整的RAG系统而不是随便接个向量库就完事。我后面实操部分会专门讲RAG的调优。3. 实操记录一个老项目的LLM化改造3.1 项目背景和原始方案传统检索BERT分类说了这么多对比来一个我亲手做的迁移项目大家感受会更具体。背景是这样一家客户有个内部政策问答系统知识库里有三千多篇制度文档涉及报销、考勤、审批、IT支持等十几个大类。原本的方案是Elasticsearch做关键词检索配合一个BERT分类模型识别用户问题属于哪个大类然后按类目过滤搜索结果。这套系统的问题很明显一是用户问法稍微口语化一点比如“我出差回来机票钱怎么报”ES的BM25匹配效果就非常差因为文档里写的是“差旅费”“交通费”“报销标准”这类词字面重合太少。二是即便检索到了正确文档系统只能返回“文档标题匹配片段”用户还得自己打开文档找答案体验很割裂。三是BERT分类模型每次新增类目都要重新标注、重训、再部署维护成本居高不下。当时团队评估了两个方向一个是继续优化ES查询和BERT模型一个是直接上RAGLLM。对比了一圈考虑到模型端我们内部有A100推理端追求快速迭代最终决定先做一个小范围POC概念验证。POC的目标很朴素挑十类高频问题每类找20条真实用户问法一共200条测试集看RAG方案能不能在“答对率”和“答案可读性”上双杀老系统。为了控制变量检索引擎还是用ES但加了向量检索分支也就是说走“稀疏检索稠密检索混合召回”的路子。模型端选了Qwen系列的中文开源模型推理端先用Ollama快速验证跑通了再切vLLM。这套POC我用了一个周末加两个晚上效率比当年调BERT快太多了。3.2 从传统方案迁移到RAGLLM的关键步骤整个迁移过程可以拆成六个步骤每一步都有坑我一个个说。第一步是知识库清洗。三千多篇制度文档格式乱七八糟有PDF、Word、Excel扫描件还有从内部OA导出的HTML。我全部转成纯文本统一编码为UTF-8然后按章节结构切分。这里有一个特别重要的经验切分策略直接决定检索质量千万不要无脑按固定字数切。制度文档的语义边界通常在条款级别比如“报销标准”“报销流程”“发票要求”各是一条独立信息。我用的方案是先按一级标题分块再按二级标题和条款号继续细分每一块的chunk_size控制在200到500个中文字符之间重叠50个字符防止上下文断裂。实测下来这个策略比固定512字符切分的命中率高出十五个百分点左右。第二步是混合检索选型。我在ES里同时建了BM25索引和向量索引向量用的是当时中文embedding表现比较稳的bge-large-zh维度1024。查询时两路各自召回top20再用Reciprocal Rank FusionRRF做一个简单融合取top10作为候选。这一步要特别说明为什么要做混合检索制度文档里的专业术语和用户问法经常完全不同比如文档叫“资产处置”用户问“旧电脑怎么处理”BM25基本召回不到但向量检索能靠语义拉回来。反过来像“考勤”“报销”这种高频词BM25的精确匹配又往往比向量检索更可靠。两路互补比单路稳得多这是RAG落地的一个铁律。第三步是重排。召回top10里仍然有跟问题关联度很低的内容如果全部塞给LLM模型会被无关信息干扰。我加了一个bge-reranker-large重排模型把问题和每个候选片段拼接打分再取top3到top5作为最终上下文。这一步不便宜每个query要多花几十毫秒但效果提升非常明显。用我们测试集跑下来加了重排之后回答的引用准确率提高了大概八个点。第四步是构建Prompt模板。我用的结构是系统指令参考资料列表每段前面带编号和来源标题用户问题输出要求。系统指令里明确写了三条第一只依据参考资料回答问题参考资料里没有的信息要直接说“资料中没有提及”严禁编造第二回答要直接、简洁不要绕圈子第三引用到具体文档是哪个编号要在答案里标注来源。输出要求里规定了如果用户问的问题不在知识范围内就返回固定话术。这四段结构缺一不可尤其是“禁止编造”这一条不写进去模型真的会一本正经地胡说。第五步是输出链路改造。为了让结果对下游自动化测试友好我让模型输出JSON格式{“answer”: “回答文本”, “sources”: [“编号1”, “编号2”]}。在OpenAI兼容接口里用response_format参数强制JSON如果是本地部署的模型我会在prompt末尾强补一句“只输出JSON不要输出其他内容”并在解析侧做了容错处理。这步做完之后系统的可测试性大大提升我可以用脚本自动跑200条测试集统计答案命中和来源准确率再也不用人肉肉眼一个一个看了。第六步是评估闭环。我定义了两个核心指标答案准确率answer_accuracy和来源准确率source_accuracy。答案准确率靠人工抽检加LLM裁判来源准确率就是检查模型标注的文档编号是不是真的能回答这个问题。评估数据我固定下来每次改动Prompt、切分策略、检索参数都用同一套测试集回归防止“修了一个问题引出三个新问题”。这套评估流程是ALLM时代最重要的工程实践没有之一。很多团队LLM应用上线翻车就是因为在“感觉还行”的时候就松手了。3.3 模型端与推理端的部署选型Ollama、LM Studio、llama.cpp部署这块我踩过的坑最多值得单独拿出来讲。先说结论不同场景有不同选型没有一个万金油方案。如果只是个人学习、本地跑个demoOllama是最省心的。它把模型下载、量化、运行、API服务一条龙全包了装完扔一条ollama run qwen2.5:7b就能聊起来。Ollama的model library里也直接列好各种GGUF量化版不用自己操心怎么转格式。我本地这台4090机器上就跑着Ollama24G显存刚好塞下Qwen2.5 14B的Q4_K_M量化版日常写写prompt、测测RAG链路非常稳。如果是跨平台图形界面、想要ChatGPT那种聊天体验LM Studio值得一试。它在Windows、macOS上都有客户端可以下载HuggingFace上的模型带聊天界面、本地API服务还能在模型加载时自动选GPU offload层数。很多完全不会命令行的同事靠LM Studio也能玩起本地模型对非技术背景的人非常友好。另外它支持OpenAI兼容API可以无缝接到各类第三方客户端。如果是要上生产、扛并发那就得用vLLM或者SGLang。vLLM的PagedAttention机制能把显存利用率拉到非常高的水平连续批处理continuous batching让在线推理的吞吐量比原生HuggingFace pipeline高出几倍到几十倍不等。我有个线上服务用vLLM部署Qwen2.5-72B-AWQ量化版4卡A100并发压到100路首token延迟压在1.5秒以内效果稳定。SGLang在多模态和结构化输出上有些独到优化但vLLM生态更成熟我建议优先vLLM。另外如果是纯CPU环境部署llama.cpp是最后防线量化到Q4之后一个7B模型在32核服务器上也能跑出每秒十来个token虽然慢但至少能跑。这里还要补充一个体能上的忠告不要一上来就追求大模型。如果业务场景只需要做分类、抽取这种简单任务7B到14B的模型完全够用延迟和成本都低一个量级。我习惯的做法是先用最便宜的模型验证方案能通再横向对比大模型的效果最后根据“效果增量值不值成本增量”做决策。很多时候你会发现72B比7B提升的那三四个点根本不是业务方感知得到的差距但推理成本贵了十倍。3.4 效果对比和成本测算POC做完之后我做了详细的对比表放在这里供参考维度老系统ESBERT新系统RAGLLM测试集答案准确率61%86%来源准确率无来源标注82%平均响应时间300ms2.8s重排后新增类目成本标注训练部署约两周写入知识库约半天维护成本需要长期盯模型指标需要维护知识库质量和Prompt版本答案准确率从61%涨到86%这个幅度对业务方来说是肉眼可见的“质变”。代价也很明确响应时间从300ms涨到2.8秒这里主要是LLM生成耗时多轮对话体感倒还好但如果做高并发查询延迟必须靠工程手段压。我的策略是能用缓存就缓存高频问题提前生成答案存Redis检索阶段砍掉重排来省时间比如纯关键词查询直接走BM25不加向量召回生成阶段用小模型兜底74B处理不了再升级大模型。成本测算下来单次回答的GPU成本大概是0.02到0.05元日均一万次问答的话月成本在两万块上下大头在GPU机器折旧和电费相比雇人工客服还是便宜太多了。最后再说一句POC阶段别追求完美。我先用最简单的“ES向量检索Qwen7B”跑通全链路所有组件都选最容易上手的证明业务价值之后再逐步优化。这个“先跑通、再调优”的顺序特别重要很多团队死在第一步就想着把RAG做到完美结果两个月过去了连个能演示的东西都没有。4. 常见问题与排查技巧实录4.1 本地部署LLM的常见崩溃与对策本地跑LLM我遇到最多的问题集中在三个地方显存溢出、模型加载慢、输出乱码。显存溢出OOM是最常见的。7B模型FP16要14G显存加上KV cache和输入序列长度16G显卡稍微长一点的对话就爆。解决办法有三个方向一是用GGUF量化版Q4_K_M能把7B压缩到4.4G左右效果损失在可接受范围二是缩小上下文长度设成4096甚至2048KV cache占用会大幅下降三是升级推理框架vLLM的PagedAttention能按需分配KV cache而不是一次性预留最大空间这对长对话场景帮助非常大。模型加载慢的根源一般是磁盘IO和量化格式。HuggingFace的原始模型是分片bin格式加载时要全部读一遍再做反量化动辄一分钟起步。换成GGUF格式后因为量化过程已经预先做好直接mmap映射到内存加载速度能缩短到十几秒。所以本地玩模型强烈建议直接用GGUF配合llama.cpp或Ollama都是这个思路。输出乱码的坑多数出在中文编码和tokenizer不匹配。之前我用一个老模型的时候生成的回答中间总是冒出“[UNK]”标记后来发现是这个模型的词表里中文覆盖太少。解决办法就是换中文语料预训练充分的新模型Qwen系列和DeepSeek系列在这块都做得不错。另外还要注意终端和API的编码设置我见过有人用Ollama服务一切正常但用Python requests去调时没设置encodingutf-8结果中文全乱。4.2 RAG检索质量差的排查思路RAG系统最经典的坑就是“模型回答得太流畅但内容完全不对”。这种“一本正经地胡说八道”十有八九是检索环节出了问题。排查路径从下往上走先看检索召回的内容到底准不准再决定要不要改模型Prompt。第一步调切分。chunk太大一段里面塞了好几个主题向量表示被平摊稀释检索结果自然不够聚焦chunk太小语义信息不完整模型也难做推理。我的经验值纯文本合适范围是200到500个字符表格数据按行和列分别切代码按函数块切。切分完一定要人工抽检20到30条看看每个chunk是否“语义自洽”。第二步看召回数量。很多时候召回top1就对了但因为后续几段都是噪声模型被带跑偏了。可以把召回数量从top5降到top3或者加强重排环节让最相关的段落排到最前面。之前我测试过有重排和无重排答案准确率差八个点以上关键就在这里。第三步检查embedding模型和query之间的gap。如果你的知识库是高度专业化的领域比如医疗、法律、工业用通用embedding模型可能效果一般。可以考虑换领域优化的embedding模型或者对用户query做改写。一个简单技巧构建一个“query改写”环节让LLM把口语化问题先改写成“关键词专业术语”的检索表达式再拿改写后的文本来检索。我在保险行业的项目里用这一招检索命中率提升了十几个点。4.3 模型输出不稳定和幻觉的处理输出不稳定的问题本质上是LLM的概率性决定的。生产环境中我要求所有需要稳定输出的接口必须做到几点temperature设0或者0.1seed固定如果推理框架支持用结构化输出约束格式最后做一次输出校验不符合格式就重试一次。这一套组合下来输出稳定性可以做到非常接近传统软件的水平。幻觉问题更麻烦因为它在格式上是完全正常的。我的处理手段是多管齐下第一Prompt里强制加“仅依据给定资料回答资料未提及请明确说明”第二系统侧对模型引用的来源编号做合法性检查如果模型回答里标注的文档编号不属于检索返回的候选集就判定为幻觉输出触发重新生成第三在业务上给用户一个“不确定”的合理出口告诉用户如果系统说“未找到”可以直接转人工。说实话要做到100%消除幻觉是不可能的工程上唯一能做的就是让幻觉“可见、可拦截、可兜底”。4.4 个人知识库管理工具Obsidian配LLM最后聊一个跟RAG相关但更轻量的玩法用Obsidian管理知识库并接上LLM。热词检索里也提到了“llm wiki obsidian使用教程”说明很多人都在这么干了。Obsidian本质是个本地Markdown笔记库所有内容都是纯文本这天然适合被LLM消费。我把做项目时积累的文档、代码片段、踩坑记录全部用Obsidian管理每个文档的frontmatter里写上tags和alias正文用标题分层。然后通过Ollama或者本地API把Obsidian库变成RAG的语料源。具体操作我用的方案是写一个Python脚本扫描Obsidian的vault目录把每个Markdown文件按标题切分后写入本地向量库比如Chroma再起一个简单的问答接口。问“上次那个项目的显存问题最后怎么解决的”系统能直接从我三个月前的笔记里找到答案。这个做法的好处是知识积累完全掌握在自己手里文档格式通用不会像某些商业知识库工具一样被绑定。我用下来最大体会是先有整理好的笔记才有高质量的RAG基础不打牢检索出来全是垃圾。Obsidian只是载体真正的知识工程还是得自己花功夫。5. 一些个人体会和工具推荐5.1 哪些“老经验”到现在仍然有效聊到这儿很多人可能会觉得BLLM时代的东西全没用了。我的看法是技术工具变了但底层思维没有变。数据清洗的能力任何时候都值钱无论是训BERT还是做RAG脏数据进去必然导致脏结果。评估闭环的意识BLLM时代你要跑测试集看F1ALLM时代一样要有测试集看答案准确率。系统工程思维模块解耦、性能监控、异常处理这些在传统软件和LLM应用里一个都不能少。我自己面试人的时候从不问会不会用LangChain而是问如果大模型答错了你怎么排查。这个排查思路才是工程师真正的核心能力。另外还有一个特别容易被忽略的老经验对业务的理解。BLLM时代我们要跟业务方聊清楚“37类工单”到底怎么分ALLM时代我们依然要聊清楚“什么是合规回答、什么话术不能出现”。大模型可以帮你写邮件但它不知道你们公司的合规红线。这个需要人来定而且永远需要人来定。所以不要觉得LLM时代产品经理和算法工程师就失业了真正理解业务的人反而更值钱。5.2 新手入坑LLM应用的最短路径如果你现在是从零开始学LLM应用我给一条最省时间的学习路径。第一周装好Ollama跑一个14B以下的模型多跟它聊天感受Prompt的作用。第二周学LangChain或LlamaIndex的基本组件重点是Retriever和Agent搭一个最简单的RAG问自己本地文档。第三周学vLLM和量化部署把本地模型包装成OpenAI兼容API理解推理端的基本概念。第四周自己写一个评估集给上面做的RAG打分然后开始迭代优化切分、召回、重排、Prompt。整个周期四周下来你已经比很多“只会在网页上玩ChatGPT”的人强太多了。工具选型上我个人目前的日常组合是模型端选Qwen或DeepSeek系开源模型推理端Ollama用于开发调试、vLLM用于生产检索用Milvus或Chroma或者直接ES混合索引编排层用LangChain但不过度依赖写完核心逻辑尽量自己手写。这套组合的好处是全链路都能本地化数据不出内网对大多数企业场景足够。5.3 从allm到“更远”后续扩展方向文章写到最后我想说一个趋势判断LLM前后之分不是一次性的而是一个持续的过程。今天很多公司做的RAG在Agent出现之后又会变一个样子。现在流行的多Agent协同、工作流编排、代码生成Agent比如Codex CLI接入LLM都在把“问答”升级为“执行”。BLLM时代的系统引擎是“规则加模型”ALLM初期的系统引擎是“检索加生成”再往后引擎很可能是“目标驱动的多步推理”每一步都可能调用工具、访问知识库、校验结果。这个方向对工程能力的要求又上了一个台阶但底层的思路还是我前面说的理解业务、设计评估、控制边界、持续迭代。从我做了这么多项目的感受来说LLM最性感的地方不在于它能取代谁而在于它让一小群工程师就能撑起过去一个团队都做不动的应用。BLLM时代做智能客服至少要五六个人分工协作ALLM时代两个人加一个靠谱的大模型API也能做到六成以上的效果。当然“能做到”和“做得稳”之间还有很长的路这里面的每一步都是值得投入时间去钻研的。如果你也正在做LLM落地欢迎把这篇文章里的坑当作你的避雷针能少走一点弯路我就没白写。