从BLLM到ALLM：大模型如何重塑NLP应用开发

BLLM / ALLM – before and after LLM。这个标题我想了很久，最后还是决定用最直白的方式聊。作为一个从2018年就开始做文本处理、最近三年又一头扎进大模型落地项目的开发者，我太有资格说这个话题了。LLM不是突然冒出来的，它是前面十几年NLP技术积累到一定程度之后的质变。很多人现在只看到LLM的“神”，却不太了解LLM之前那个“人”的时代，也不太清楚这个分水岭到底切在了哪里。

这篇文章我想把BLLM（Before LLM）和ALLM（After 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，同一条输入，两次请求的结果可能不一样。这对上层应用是非常棘手的，你没法用“精确匹配”去做自动化测试。所以现在工程上普遍引入了temperature=0、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模型，一个是直接上RAG+LLM。对比了一圈，考虑到模型端我们内部有A100，推理端追求快速迭代，最终决定先做一个小范围POC（概念验证）。POC的目标很朴素：挑十类高频问题，每类找20条真实用户问法，一共200条测试集，看RAG方案能不能在“答对率”和“答案可读性”上双杀老系统。为了控制变量，检索引擎还是用ES，但加了向量检索分支，也就是说走“稀疏检索+稠密检索混合召回”的路子。模型端选了Qwen系列的中文开源模型，推理端先用Ollama快速验证，跑通了再切vLLM。这套POC我用了一个周末加两个晚上，效率比当年调BERT快太多了。

3.2 从传统方案迁移到RAG+LLM的关键步骤

整个迁移过程可以拆成六个步骤，每一步都有坑，我一个个说。

第一步是知识库清洗。三千多篇制度文档，格式乱七八糟，有PDF、Word、Excel扫描件，还有从内部OA导出的HTML。我全部转成纯文本，统一编码为UTF-8，然后按章节结构切分。这里有一个特别重要的经验：切分策略直接决定检索质量，千万不要无脑按固定字数切。制度文档的语义边界通常在条款级别，比如“报销标准”“报销流程”“发票要求”各是一条独立信息。我用的方案是：先按一级标题分块，再按二级标题和条款号继续细分，每一块的chunk_size控制在200到500个中文字符之间，重叠50个字符防止上下文断裂。实测下来，这个策略比固定512字符切分的命中率高出十五个百分点左右。

第二步是混合检索选型。我在ES里同时建了BM25索引和向量索引，向量用的是当时中文embedding表现比较稳的bge-large-zh，维度1024。查询时两路各自召回top20，再用Reciprocal Rank Fusion（RRF）做一个简单融合，取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）

部署这块我踩过的坑最多，值得单独拿出来讲。先说结论：不同场景有不同选型，没有一个万金油方案。

如果只是个人学习、本地跑个demo，Ollama是最省心的。它把模型下载、量化、运行、API服务一条龙全包了，装完扔一条ollama run qwen2.5:7b就能聊起来。Ollama的model library里也直接列好各种GGUF量化版，不用自己操心怎么转格式。我本地这台4090机器上就跑着Ollama，24G显存刚好塞下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做完之后，我做了详细的对比表，放在这里供参考：

答案准确率从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甚至2048，KV cache占用会大幅下降；三是升级推理框架，vLLM的PagedAttention能按需分配KV cache，而不是一次性预留最大空间，这对长对话场景帮助非常大。

模型加载慢的根源一般是磁盘IO和量化格式。HuggingFace的原始模型是分片bin格式，加载时要全部读一遍再做反量化，动辄一分钟起步。换成GGUF格式后，因为量化过程已经预先做好，直接mmap映射到内存，加载速度能缩短到十几秒。所以本地玩模型，强烈建议直接用GGUF，配合llama.cpp或Ollama都是这个思路。

输出乱码的坑多数出在中文编码和tokenizer不匹配。之前我用一个老模型的时候，生成的回答中间总是冒出“[UNK]”标记，后来发现是这个模型的词表里中文覆盖太少。解决办法就是换中文语料预训练充分的新模型，Qwen系列和DeepSeek系列在这块都做得不错。另外还要注意终端和API的编码设置，我见过有人用Ollama服务一切正常，但用Python requests去调时没设置encoding="utf-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.1；seed固定（如果推理框架支持）；用结构化输出约束格式；最后做一次输出校验，不符合格式就重试一次。这一套组合下来，输出稳定性可以做到非常接近传统软件的水平。

幻觉问题更麻烦，因为它在格式上是完全正常的。我的处理手段是多管齐下：第一，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时代你要跑测试集看F1，ALLM时代一样要有测试集看答案准确率。系统工程思维，模块解耦、性能监控、异常处理，这些在传统软件和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落地，欢迎把这篇文章里的坑当作你的避雷针，能少走一点弯路，我就没白写。