企业官网建设流程全解析

最近后台收到不少读者的私信，问题绕来绕去其实都指向同一个方向：大模型LLM到底是怎么工作的？为什么同样的提示词，有人写出来效果惊艳，有人写出来就是一本正经地胡说八道？为什么有的应用用RAG就能解决问题，有的非要微调？为什么我部署了一个开源模型，跑起来又慢又吃显存，别人却能做到毫秒级响应？

这些问题看着零散，但根子都在LLM的基础知识上。我做了几年大模型应用开发，回头看踩过的坑、走过的弯路，十有八九都是因为早期没把基础概念吃透。基础这东西，日常写代码的时候感觉不到它在帮你有多少好处，但一旦涉及性能调优、效果优化、成本控制，有没有那层底层认知，做出来的东西完全是两个级别。

这篇文章适合谁？刚入门想系统了解大模型原理的同学，做应用开发想搞明白模型调优策略的工程师，以及那些已经在用LangChain、Dify这些框架但知其然不知其所以然的朋友。我会把LLM最核心的几个知识点拆开揉碎来讲，从模型原理到推理机制，从RAG到部署应用，再到踩坑经验，争取让你读完之后，面对市面上大多数LLM相关讨论都能接得住、听得懂、用得上。

1. 先从“接龙游戏”说起：LLM的本质和它带来的两个直接推论

想理解LLM，最先要丢掉的一个错误预期是“它是一台会思考的电脑”。真相比这个朴素得多——LLM本质上是一个极其复杂的词接龙器，它的核心任务是算出“下一个词最有可能是什么”。

1.1 一个最简单的例子

给你一句话：“今天天气真”，让你接下一个词，你大概率会说“好”。再给你一句“今天天气真”，但如果前面还有一句“同事说，我们周末去爬山，我说”，你接的词可能就变成了“好”或者“棒”。

LLM做的事情就是这个，只不过它不是在“词”的粒度上做预测，而是在“token”的粒度上做预测。一个token可能是半个词、一个词、几个字符，不同模型的token切分策略不一样。模型从左到右一个一个地预测接下来的token，每预测出一个就拼到原句后面，然后再预测下一个，这样循环下去，一整段话就生成出来了。

这个过程叫自回归生成。GPT的全称里面，Generative Pre-trained Transformer，那个G就是Generate，T是Transformer，拆开来看其实就是“用Transformer结构做的预训练生成模型”。

这里有个非常关键的推论：模型从出生那天起，就不是为了“回答问题”而设计的，而是为了“让句子接得通顺自然”而训练的。你平时看到的对话、文章、代码、分析，本质上都是“接龙接得足够好”的产物。

1.2 预训练、指令微调、人类偏好对齐

既然模型只会接龙，为什么我们用它的时候感觉它是在对答如流？这就得说到训练的三个阶段了。

第一阶段是预训练。模型被喂入海量的互联网文本，任务只有一个：预测下一个token。这个阶段模型学到的是语言的统计规律、知识的事实分布、逻辑的常见模式。你可以把它理解为一个人读了很多书，但只是默默记在心里，你问他什么他不会答，因为他只学会了“顺着句子往下说”。

第二阶段是指令微调，也叫SFT。这个阶段用大量“指令-回答”对让模型学会服从指令的格式：用户问一句，模型接一个像样回答。这个阶段让模型从一个“接龙机器”变成了一个“会答题的工具人”。

第三阶段叫对齐，最典型的是RLHF人类反馈强化学习以及它的各种变体。简单说，就是让模型输出的答案符合人类的偏好和价值观，不胡说八道得太离谱，不生成有害内容。

所以你今天拿到的一个LLM，是“预训练学语言规律+指令微调学回答问题+对齐学人类偏好”的三合一产物。明白这个之后，很多现象就解释得通了。

1.3 幻觉从哪来

幻觉问题几乎每个用LLM的人都会碰到。模型一本正经地告诉你某本书的观点、某条法律条文、某个历史事件的结果，但实际上是编的。为什么？

因为模型在生成的时候，永远在“语言上最通顺”和“事实上最正确”之间做权衡。预训练阶段它看到的文本里，有大量事实矛盾的说法（互联网上什么都有），它学到的是“这些说法经常以某种形式出现”，而不是“这些说法哪个在现实世界中是对的”。

再加上很多微调数据本身也是人写的，人写的东西里同样有错误。模型没有渠道去验证事实，它唯一的事实来源就是训练数据里的统计规律。所以幻觉不是bug，是统计学习方法的固有副产品。

这也解释了为什么当你问模型一个冷门问题、一个超出它知识范围的问题时，它宁可编一个像模像样的答案，也不愿意说“我不知道”——因为在它的“接龙经验”里，“用户问问题”后面跟一个“自信的回答”的概率，远大于跟一个“坦诚的不知道”的概率。

明白了这个本质，你就知道为什么做严肃应用时不能裸用模型直接回答那些对事实要求极高的业务问题，你需要RAG、需要工具调用、需要人工审核。这不是模型不够聪明，而是我们对它的期望定位一开始就偏了。

2. 一次推理的完整链路：Token、注意力机制和采样策略

聊完训练的本质，接下来看推理过程。你输入一段话，模型内部到底发生了什么？我按照执行顺序拆开讲，每一环都能对应到你日常调参和排障时看到的现象。

2.1 Tokenizer：模型看到的世界和你的不一样

模型不认字，它只认数字。第一步就是把你输入的文本切分成token序列，再映射成对应的id。这一步由tokenizer完成。

不同模型用的分词策略不同，早期喜欢按词切，但按词切会导致词表太大而且处理不了没见过的词。现在主流基本都用BPE这类子词算法，它把常见词保留为整体，不常见词拆成更小的片段。“unhappy”可能被切成“un”和“happy”两个token，“我爱你”在中文模型里可能一个字一个token也可能两个字一个token，取决于词表训练时的统计结果。

这个细节直接关系到两件事。

第一件事是成本。现在主流模型按token计费，你发一段中文，中文字符切出来的token数量通常比英文要多。一段千字中文大概烧掉七八百个token，长对话和长文档处理时，token消耗会很快。

第二件事是理解边界。模型对拼写错误的容忍度、对不同语言的表达能力差异，都跟tokenizer的分词效果有关。有时候你发现某段文本怎么调提示词效果都不好，去看一眼tokenizer把它切成了什么鬼样子，心里就明白了。用一些在线工具查看实际的分词结果，是调试LLM应用的第一步。

2.2 Transformer如何理解上下文

token序列变成了id列表之后，会进入embedding层变成向量，再进入几十上百层Transformer模块。Transformer的核心机制是自注意力，这里我用一个生活化的类比来解释。

想象你在公司开会，听到一句话“它坏了，需要换新的”。如果你不知道“它”指什么，这句话等于白说。自注意力机制做的事情，就是当模型处理到“它”这个字的时候，它会自动回看这句话前后的所有词，计算每个词跟“它”的关联程度。如果前面提到“打印机”，且跟“它”距离很近、语法关系很强，那么“它”在模型内部的表示中就会带上“打印机”的信息。

Transformer里面那套Query、Key、Value的运算，本质就是在做“匹配度打分+信息提取”：Query是当前词想问的问题，Key是被关注词展示的名片，两者算一个点积就能得到匹配分数，然后按匹配度加权提取Value里的信息。整个过程把每个token和上下文其他token两两配对，这就是“自注意力”里“自”的含义。

这套机制让Transformer能有效捕获长距离依赖关系。这也是为什么它能碾压LSTM那个时代靠门控机制做语言模型的方案——LSTM要按顺序一个一个读，距离太远前面的信息早就被遗忘了。Transformer天然能“隔空取物”，只要上下文里出现过相关信息，注意力就能把它找出来。

当然，这里说的是推理时行为。训练时Transformer还有一个关键不同：它会把整句话的所有token一次性丢进去做并行计算，靠mask机制保证每个位置只看到它前面的token，这样既能并行训练，又不破坏自回归属性。

2.3 采样策略与“如何让模型不输出思考过程”

模型最后一层输出的其实不是“答案”，而是整个词表里每个token的得分。这个得分经过softmax转换就变成概率分布：下一个token是“好”的概率是37%，“棒”的概率是22%，等等。

问题来了：你选哪个作为实际输出的token？这就是采样策略。

最稳妥的方案是贪心解码——永远选概率最高的那个。这个方案的好处是稳定、可复现，坏处是容易陷入重复和呆板。实际上生成时普遍会加入一定的随机性，让模型更灵动。关键控制参数就是Temperature和Top-p。

Temperature是缩放概率分布的参数。温度越低，概率分布越尖锐，高概率token被选中几率越大，输出越确定。温度越高，分布越平坦，低概率token也有机会冒头，输出越发散。

Top-p又被称为核采样，它把累计概率到某个阈值的那批候选token圈出来，在这个圈子内部重新分配概率。Top-p=0.9意味着只从累计概率90%的token集合里采样，把长尾的离谱候选直接排除。

这两个参数调起来有口诀：代码生成、数据提取这种要精确的任务，Temperature设低一些，0.1到0.3比较合适。文案创作、头脑风暴可以调高到0.7到0.9。但别用太高，超过1.2之后输出基本就开始语无伦次了。

有一个问题很多人专门问过：怎么让模型不输出思考过程？这得分情况。

如果你用的是OpenAI o系列或Gemini这类推理模型，模型内部会先产生一段思维链再给出答案，有些API会把这部分思考内容也返回。OpenAI的API里有一个reasoning_effort参数，可以设置为low减少思考内容，部分接口也支持关闭思考模式（比如Responses API里的reasoning: {"effort": "low"}）。如果是DeepSeek R1这类模型，API里通常有thinking开关，可以关闭输出思维链内容。

如果你用的是普通模型，但它仍然输出“我的思考过程如下”，那是提示词把它带偏了。解决办法是在system prompt里加一条硬性约束，比如“直接给出答案，不要输出任何推理过程、解释或思考步骤”，必要时配合低Temperature让约束更稳定。

还有个容易被忽略的细节：如果API支持schema或结构化输出，把它配上，让模型直接用JSON格式回答核心字段，也能从形式上逼它跳过碎碎念的过程。

3. 上下文窗口、RAG和微调：三种补知识的手段该怎么选

应用开发中最高频的决策之一，是怎样让模型“知道”它训练之后出现的、或者它不知道的知识。共有三种主流手段：把知识塞进上下文窗口、用RAG检索并动态拼入上下文、用微调改模型本身的权重。三种手段各有利弊，但很多人一上来就选微调，这个思路通常是最费钱也最不划算的。

3.1 上下文窗口并没有想象中那么大

上下文窗口指模型一次能处理的最大token数。几百token的年代已经过去了，现在百万级上下文窗口也不稀奇。但“窗口有这么大”和“窗口里的东西都能有效用上”是两回事。

你做过长文档问答就会有体会：把一个几十万字的产品手册全塞给模型，它确实不会报错，但问细节问题时经常漏掉藏在文档深处的关键信息。注意力分布是“有限注意力资源”在分配，上下文越长，真正被重点关注的信息密度反而越低，医学上叫“注意力稀释”，放到LLM里叫“lost in the middle”。

更深一层的是算力问题。Transformer自注意力是O(n²)复杂度，上下文长度翻一倍，计算量涨四倍。即使模型支持长上下文，系统在这些长文本上的处理速度也明显下降、成本大幅上升。

所以，上下文窗口的正确用法是“刚需再上”。日常业务里，把几万字的文档全文塞进去对话，往往既烧钱又效果不佳。这时候就该考虑RAG了。

3.2 RAG的完整链路和关键细节

RAG的核心思路很简单：模型不知道的知识，你从外部资料库里面先检索出来，连同问题一起塞给模型，让模型基于给定的资料作答。它把“模型本身知道什么”和“模型回答问题时能参考什么”解耦了。

标准的RAG链路大概是这个流程：

• 离线阶段：把知识文档切成小块，每块做embedding变成向量，存入向量数据库。
• 在线阶段：用户提一个问题，先对问题做embedding，再到向量库里做相似度检索，取出排名靠前的知识块。
• 最后：把检索结果和用户问题放入提示词模板，交给LLM组织最终答案。

听起来简单，实际坑不少。

切块大小是第一个坑。块太小，上下文信息不完整；块太大，检索精度下降而且浪费token。常见的做法是256到512个token一块，同时设置少量重叠，避免一句话在切缝处被砍断。实际效果得靠实验，没有一劳永逸的通用值。

第二个坑是embedding模型的选择。中文场景如果用通用英文embedding模型，语义召回效果会非常拉胯。建议测试专门的或中英双语的embedding模型，用你自己的领域数据做召回准确率验证。

第三个坑是检索完的“融合”。很多系统把这个环节省成一个粗暴拼接：把top5的块按顺序贴进提示词，这容易导致模型读了一堆无关信息，反而干扰回答。更稳妥的做法是，让模型明确感知到哪些是参考资料、哪些是用户问题，在提示词里给出边界；更复杂的做法是加上rerank环节，先用向量检索粗召回50条，再用一个rerank模型精排到5条。

所以你在热搜里看到“RAG增强LLM”这么热门，是因为RAG是当前企业落地LLM应用最性价比高的路线。它不需要重新训练任何模型权重，数据可以随时更新，改一条文档马上生效，而且可以精确追溯到模型使用了哪些上下文，对合规审计也友好。

3.3 RAG与微调的选型对比

微调是在模型原有权重上做进一步训练，让模型自身的能力偏向某种风格或某种知识体系。它适合的场景是：培养稳定的输出风格、让模型学会特定格式（比如固定输出JSON结构）、强化某个领域的推理套路。

但微调有几个不好的面。一是一次性成本不低，哪怕用LoRA这类低秩适配方案，也得准备训练数据和调参算力。二是更新不灵活，知识变了得重新训练。三是微调并不能彻底解决事实不准确，模型可能把你给的数据学了个表面模式，遇到新问题还是容易编。

我个人的选型经验是这张表：

这里多提一句：提示词里的few-shot示例有时能解决很多你以为需要微调的问题。先试提示词，再试RAG，最后才考虑微调，这个顺序能让你的钱和时间花在刀刃上。

4. 模型端和推理端：部署LLM的基本盘

热门搜索里有“llm agi 模型端 推理端”，这两个词确实跟LLM使用的两个阶段对应。模型端指的是你选的基座模型本身，比如Llama、Qwen、GPT这些。推理端指的是模型运行起来做推理计算的那一套系统。不管你用API还是本地部署，都绕不开这两端的知识。

4.1 权重、参数量和显存的粗略估算

选模型时会看到参数量的说法，7B、13B、70B，B就是Billion，十亿参数。参数越多，模型容量越大，能学到的模式越复杂，但代价是推理时需要更多的显存。

怎么估算一个模型推理要多少显存？原则很简单：参数占用的显存 + 推理过程的中间状态占用。

单精度FP32一个参数占4字节，半精度FP16/BF16一个参数占2字节，INT8量化一个参数占1字节，INT4量化大概0.5字节。所以一个7B模型在FP16下，光权重就有大约14GB。加载到显卡上，还要加上KV cache和中间激活值，实际占用比这个数字高不少。

这也是为什么24GB显存的显卡跑7B模型比较舒服，跑13B就要用到量化了。70B的模型在FP16下光权重就140GB，必须多卡并行加量化才能玩得动。推理框架如果支持量化，7B模型在消费级显卡上也能起飞，但注意量化会带来轻微的效果损失，关键任务上建议量化后做一轮效果验证。

4.2 推理框架在解决什么问题

光有模型权重文件还不能对外提供服务。推理时有一系列工程问题：如何管理KV cache、如何做连续批处理、如何把并发请求组织成高效的batch推理、如何加速算子计算。这些问题超出了模型文件本身，需要专门的推理框架来兜底。

这也是为什么你直接从Hugging Face拉一个模型用它的model.generate()方法跑，速度往往慢得让人绝望——那是给研究用的路径，没做工程优化。

生产环境里比较常见的推理优化方案有：

• 批处理调度：把多个请求拼成一个batch同时前向计算，GPU利用率大幅提升。请求越多，单位成本越低，这就是为什么大厂API那么便宜。
• KV cache管理：注意力计算时把历史token的Key、Value缓存下来，避免每次重新计算。框架负责管理和复用这些缓存，是长对话能跑得快的关键。
• 量化压缩：把权重从FP16压到INT8或INT4，显存占用和计算量一起下降。常用的有GPTQ、AWQ、GGUF这类方案。
• 投机采样：用一个小模型先草拟一批token，大模型只花很少的计算量批量验证，通过大模型的验证结果来决定接受哪些预测，比每一步都让大模型慢慢推理快不少。

自己做部署的时候，本地小规模试用，Ollama一条命令就能把量化过的模型跑起来，适合体验。生产环境的并发服务，vLLM是目前比较成熟的框架，吞吐量优势明显，支持OpenAI兼容的API协议，配好一行启动参数就能对接下游应用。如果要用多模态模型、对部署形态做深度定制，可以考虑SGLang或TensorRT-LLM。

4.3 从本地到服务：OpenAI兼容API

实际做应用的时候，大多数人不是自己部署模型，而是调用云厂商API。无论你用的是哪个厂家的模型，今天几乎都提供了OpenAI兼容的接口。好处是应用端只需要写一套访问代码，换模型时改一下base_url和model名就行。

这么说吧，OpenAI兼容API已经成了大模型界的HDMI接口。你的电脑有大DP口，电视大HDMI口，中间配一个转换线就能接上。模型服务方提供OpenAI兼容协议，框架生态（LangChain、Dify这些）天然认这个协议，你在里面填一个base_url和一个key，模型就接进来了。

选择接入方式时先算一笔账：频繁做原型迭代、并发不高、不想管运维，用托管API最划算；有数据隐私要求、拥有GPU机器、并发量稳定，本地部署VLLM才值得考虑。我见过团队一开始就买了四张卡部署70B模型做内部工具，结果月活不到二十人，GPU利用率不到百分之三，运维复杂度还很感人——这种场景就该老老实实用API。

5. LangChain和Dify：应用层框架到底帮你做了什么

网上关于LangChain和Dify的讨论非常多，有人在喷框架过度封装，有人在吹效率提升。我的观点是：框架的定位是“把LLM应用开发的常见模式固化下来”，用得好能省大量时间，用不好就会变成debug负担。

5.1 LangChain的Tool Selector与函数调用

LangChain最核心的启发是它抽象出了Chain、Agent、Tool这些概念。实际开发中最常用的一个能力是Tool Selector——让LLM自主决定调用哪个工具并提取参数。

底层机制其实是函数调用。你把工具定义成一段JSON Schema，描述清楚函数名、参数名、参数类型、参数含义，然后放进请求里发给模型。模型读完用户问题后，会判断“这个问题应该调用哪个工具、参数填什么”，然后返回一个结构化的工具调用指令，而不是直接写自然语言让你去解析。

自己做一个Tool Selector的步骤大致是：

• 定义好工具列表与每个工具的详细描述，描述写得好坏直接影响路由准确率。
• 给每个工具Design一个清晰的参数Schema。
• 在提示词里说清楚路由逻辑：当用户意图匹配哪个工具时就调用哪个工具。
• 对返回结果做校验，工具不存在或者参数不合法时需要兜底策略。

踩过的坑是：工具说明写得含糊，导致模型好几个工具描述看着都像，它就会随机调用。给工具起名和写描述的时候要尽量具体，最好附上典型触发语和反例。比如一个查天气的工具，描述里明确写“当用户问明天上海温度时调用，而不是讨论天气预报节目的场景”。

LangChain里还有LangGraph这层状态编排能力，适合做复杂多智能体流程。但对大多数项目，我建议不要一上来就上重量级编排，简单的思维链就够用了。框架降低的是开发时间，不是思考成本。

5.2 Dify里LLM设置的实际操作

讨论Dify时，“dify里的llm怎么设置”这个问题出现的频率很高。Dify作为一个可视化LLM应用平台，把模型管理、知识库、工作流、Agent编排都做成了可视化的界面。它的应用大概逻辑是：先配置模型供应商，再在应用里引用模型。

模型供应商设置的关键是选对入口。进入设置-模型供应商，找到你要用的服务商，填入API Key。各个厂家现在都做了兼容接入，OpenAI格式的接口可以直接填一个自定义的base URL和API Key。

模型设置界面上比较核心的几个参数：

• 模型名称：必须填对模型的精确名称，填错会直接报错或者默认到别的模型。
• Temperature：根据任务类型设置，对话聊天可以高一点，知识库问答建议低一点。
• Top-P：一般跟Temperature配合使用，固定0.85到0.95之间比较稳妥。
• Max Tokens：限制模型单次回答的最长长度，知识库问答这个值可以给到2000。
• System Prompt：Dify里有独立的系统提示词位置，这里放角色设定和回答规则。

另外提醒一点，在Dify里接知识库的时候，记得在“检索设置”里选好检索模式和召回数量。默认参数不一定适合你的文档，先跑一个测试问句看检索结果是否符合预期，再决定要不要开Rerank。

5.3 什么时候不需要框架

框架虽然是效率工具，但它也有成本。隐藏了很多实现细节，出了问题排查链路长；抽象层多，性能损耗不小；版本更新频繁，接口变动是家常便饭。

所以我个人的判断标准是这样的：如果应用逻辑就是一层“提问-检索-回答”，或者只是封装API做一层prompt模板，直接用Python写个几十行的函数可能比包一层框架更快更可控。如果要做多轮对话、计划能力、多工具调度、知识库+Rerank+结构化输出一套组合拳，再考虑上LangChain或者直接上Dify这种生产平台。

有一个现象值得注意：现在不少新项目开始往回走，用更薄的封装层代替重框架。如果你的团队对LLM原理掌握得比较扎实，自己写编排逻辑反而更容易定位问题。框架是帮助，不是信仰。

6. 给入门者的一条LLM学习路线和五个高频坑

最后一部分，回应一下“llm学习路线”这个高频搜索。我不打算给你列一份十几本书的书单，而是给条从零到能干活的最短路径，顺带讲几个我亲眼见过无数次的高频踩坑事件。

6.1 从零到能干活的学习路线

第一个阶段是使用体验期。这是上手最快的一环，直接用ChatGPT、Claude、Kimi这类产品，大量地聊、大量地尝试。重点感受不同模型的输出差异、Temperature对结果的影响、System Prompt的作用。顺手了解一下Tokenizer和API调用方式，写几个脚本把API跑通。

第二个阶段是关键，做原理补课。去读Karpathy的系列公开课，他的讲解风格特别适合工程背景的人。不必一开始就去啃Attention Is All You Need原文，先看讲解视频，理解Self-Attention、Multi-Head Attention、Positional Encoding是怎么回事。这一阶段的目的不是让你能复现模型，而是别人讨论模型机制时你不再是局外人。

第三个阶段是做应用项目。选一个真实的业务小场景，用LangChain或Dify搭一个RAG知识库问答应用。把文档加载、切块、Embedding、向量检索、Rerank、Prompt模板走一遍。这个项目做完，你对整个链路就有了完整的肌肉记忆。

第四个阶段往深处走，做部署调优。用vLLM在自己机器上跑一个7B模型，做量化、配置批量推理参数、对比不同框架的性能。有余力再看一些KV Cache、PagedAttention这类偏底层的技术资料。走到这里，LLM相关的日常讨论你基本都能参与。

6.2 五个高频坑

第一个坑：上下文溢出。我见过不少团队做知识库问答，为了省事把整篇二十页的PDF塞进上下文，结果模型回答质量反而下降。上下文不是内存条，插满不意味着能用好，建议先用RAG做检索裁剪，再考虑塞入。

第二个坑：Temperature不做任务区分。有人一套参数打天下，写代码用默认温度，客服机器也用默认温度，然后抱怨代码里有神秘输出。要根据任务类型调整温度，这个前面讲过，但它值得反复强调。

第三个坑：忽略System Prompt的作用。很多人把精力全花在优化User Prompt上，System Prompt一句话都没写。结果应用一换场景就翻车。System Prompt是给模型设定角色和规则的“站立起点”，它决定了模型以什么姿态处理你的问题。

第四个坑：盲目微调。很多问题提示词就能解决，偏要花钱微调。微调一个月后线上知识变了，还得重新训练。微调应该是最后的手段而不是第一选择。

第五个坑：不做评估就上线。改动一个Prompt之后不确定实际效果究竟怎么样，全凭肉眼感觉。这个坑最隐蔽，也最伤。改动模型配置后必须回到固定的评估集上，统一跑一遍看效果分，否则就是靠运气做产品。

6.3 一个容易忽略的好习惯：先做评估集

这里分享一个做LLM应用最重要的习惯：任何项目开始之前，先花一天时间把评估集建好。

评估集就是一批覆盖主要业务场景的测试样例，每个样例包含输入问题和期望输出标准。有了评估集，你才能客观判断提示词改动是好是坏、RAG召回是否准确、新模型是否值得切换。

我第一次带团队做知识库项目时，全组对着一堆Prompt调了快两周，每天感觉“好像比昨天好一点”。后来花了半天本来觉得是浪费时间的评估集，把样例跑完对比之后，发现上一周的很多“优化”其实都在原地打转，有些改动甚至把原本对的问答改错了。有了评估集之后，每一次迭代都有据可依，类似退化问题很快能发现。

评估集不需要很庞大，五六十条覆盖主要场景的就很不错了。维护成本很低，带来的效果却是指数级的。这是整个LLM应用开发里长期最值得投入的一笔时间。

我个人的经验是，LLM入门最大的门槛不是技术，而是概念转变。你没法把它当成传统软件那样用逻辑框图来设计，得先理解它的统计本质，再用工程手段去约束它的不确定性。把这些基础知识打牢了，后面学LangChain、学RAG、学微调，就都是在同一个框架里填细节的事。