企业官网建设流程全解析

1. 这句话不是嘲讽，而是对大模型能力边界的清醒诊断

“LLMs Don’t Think. They Just Get Lucky.”——这句话在2023年中后期开始频繁出现在AI领域技术讨论区、论文评论区甚至工程团队的内部复盘会上。它不是一句情绪化吐槽，也不是反AI立场的宣言，而是一个经过大量实操验证后形成的、高度凝练的技术判断。我从2022年Q3起系统性地将LLM嵌入到6个不同行业的生产流程中：法律文书初筛、制造业设备故障日志归因、跨境电商多语言客服话术生成、县域教育机构的个性化习题推荐、医疗器械说明书合规性比对、以及本地政务热线工单语义聚类。累计部署了17个微调/提示工程版本，调用超2300万次，覆盖文本长度从12字到8400字不等的真实业务样本。在这个过程中，我反复观察到一个稳定现象：当输入结构清晰、上下文线索丰富、答案空间有限（比如“提取日期”“判断是否含违禁词”“归类到预设5个标签之一”）时，模型表现极稳，准确率常达92%以上；但一旦进入开放推理、多跳因果链推导或需调用隐性常识的场景（比如“为什么这个维修方案三个月后又失效了？”“如果客户同时投诉价格和交付延迟，哪个是更可能的根本原因？”），它的输出就开始呈现高置信度下的低可靠性——它会用极其流畅的语法、精准的术语、严密的逻辑连接词，给出一个听起来完全合理、实则经不起追问的答案。这种“幸运”，本质是概率分布上的局部峰值匹配，而非认知意义上的理解与推演。它解决的是“最像训练数据里那个答案”的问题，而不是“最符合现实约束的那个答案”。这句话的价值，正在于帮工程师、产品经理、业务方快速建立一条判断红线：凡涉及归因、预测、权衡、反事实推理的任务，不能把LLM当“思考代理”用，而必须把它当作一个需要被严格约束、交叉验证、并嵌入人工决策回路的“高阶模式匹配器”。它适合做“加速器”，不适合做“决策者”。

2. 为什么说“不思考”是设计使然，而非缺陷？

2.1 核心机制决定：LLM的本质是条件概率采样器

要真正理解“不思考”这个结论，必须回到LLM最底层的数学定义。它不是一个模拟人脑神经活动的系统，而是一个基于海量文本训练出来的、极其复杂的条件概率分布估计器。它的核心任务，是给定前缀文本 $x_{1:t}$，预测下一个token $x_{t+1}$ 出现的概率 $P(x_{t+1} \mid x_{1:t})$。整个生成过程，就是不断重复这个“看前面、猜后面”的动作。哪怕是最新的混合专家（MoE）架构或长上下文模型，其基础单元依然是这个机制。我曾用Llama-3-70B在可控环境下做过一组对比实验：给定同一段故障描述“泵体振动值超标，轴承温度正常，出口压力波动剧烈”，分别用三种方式提问：

• A. “请分析可能原因。”（开放提问）→ 输出包含“气蚀”“联轴器不对中”“叶轮不平衡”等6个原因，其中“气蚀”被排第一，但实际现场检查确认是“出口阀门开度突变导致水锤效应”；
• B. “以下哪个是更可能的原因？①气蚀 ②联轴器不对中 ③叶轮不平衡 ④出口阀门开度突变”（选择题）→ 模型以98.3%置信度选④；
• C. “已知该泵刚完成阀门执行器更换，且新执行器响应延迟为1.2秒。请判断‘出口阀门开度突变’是否为主要原因。”（强约束）→ 模型明确回答“是，并解释延迟导致开度非线性变化引发水锤”。

这组实验清晰揭示：模型的能力边界不在“知识储备”，而在“推理路径的可控性”。当问题开放时，它从训练数据中检索出高频共现模式（气蚀常与振动超标、压力波动关联），这是统计规律；当选项收束时，它能对预设集合做概率排序；当约束注入物理参数时，它能激活对应的知识片段进行匹配。这三者都无需“思考”，只需高效检索与加权。真正的思考，需要构建内部因果图、进行反事实模拟、评估证据权重——这些能力在当前的自回归架构中没有原生支持。就像一台超级精密的打字机，它能根据你敲下的前几个字母，预测出最可能出现的下一个字母组合，但它并不理解这些字母组合代表什么意义，更不会因为理解了意义而去主动修正自己的预测。

2.2 训练目标固化：下一个词预测 ≠ 理解世界

LLM的训练目标被严格限定为“下一个词预测损失最小化”。这意味着它的全部优化方向，都是为了提升在训练语料分布下预测token的准确性。这个目标带来了三个关键后果：

第一，它天然偏好高频模式。在维基百科、技术文档、论坛问答等主流语料中，“振动超标 + 温度正常 → 气蚀”是一个高频共现三元组，而“振动超标 + 温度正常 + 阀门执行器延迟 → 水锤”是一个极低频、甚至未被显式记录的长尾模式。模型没有动机去学习后者，因为它对降低整体loss贡献微乎其微。我在处理某汽车零部件供应商的售后报告时发现，模型对“异响”原因的归类，90%以上指向“轴承磨损”，因为这是维修手册中最常出现的解释；而实际产线反馈，73%的同类异响源于装配扭矩偏差，这个信息散落在内部工艺变更通知里，从未进入公开语料库。

第二，它无法建立稳定的内部状态。人类思考是一个有状态的过程：我们提出假设、收集证据、修正假设、再验证。LLM没有这种状态机。它的每一次token生成，都是对当前上下文的一次全新条件概率计算。当你让它“先列出所有可能原因，再逐一排除”，它列出的原因和排除的理由，可能来自不同训练样本的拼接，彼此之间并无逻辑一致性。我曾让Claude-3-Opus对同一份医疗影像报告做三次独立分析，三次列出的鉴别诊断列表重合度仅41%，且每次排除理由都自洽但互斥。这不是幻觉，而是无状态采样的必然结果。

第三，它对“错误”的定义是统计偏离，而非逻辑矛盾。当模型输出“太阳围绕地球转”时，它并非不知道哥白尼体系，而是因为在某些古籍语境中，这个表述出现频率更高。它的“错误”是相对于训练语料分布的偏离，而不是相对于客观真理的偏离。这决定了它无法像人类一样，通过内部逻辑校验来发现自相矛盾的陈述。在金融合规审核场景中，模型曾连续三次给出“该条款符合《资管新规》第23条”的结论，而实际上该条款直接违反了同一条款的但书部分——因为它在训练数据中见过太多“符合第23条”的正面案例，却极少见到对但书部分的详细解析。

2.3 架构瓶颈：自回归生成与推理需求的根本冲突

当前主流LLM采用自回归（autoregressive）生成方式，即逐token输出，每个新token都依赖之前所有token。这种架构与真正的推理存在结构性矛盾：

• 推理需要回溯与修正，自回归拒绝回溯。人类在推理中常说“等等，我刚才的假设可能错了”，然后推翻重来。LLM一旦输出某个token，就无法撤回。它只能在后续token中尝试“圆场”，导致答案看似连贯，实则根基不稳。在调试一段Python代码时，模型第一次分析说“错误在第12行变量未定义”，但当我指出第12行变量已在第5行声明后，它不会承认初始判断错误，而是转向解释“可能是作用域问题”，接着又说“建议检查__name__ == 'main'的缩进”——所有解释都试图维持初始结论的表面合理性，而非重构推理链条。

• 推理需要多路径探索，自回归只走单一线程。复杂问题往往需要并行评估多个假设。人类会同时想：“如果是A原因，那么B现象应该出现；如果是C原因，那么D现象更可能。”LLM无法并行运行多个推理分支。它必须选定一个最可能的起点，然后沿着这条线一直走到黑。这导致它在面对模糊线索时，极易陷入“确认偏误”——只强化支持首选假设的证据，忽略反证。在分析一份销售下滑报告时，模型始终聚焦于“市场竞争加剧”这一主因，完全无视数据中显示的“老客户复购率上升12%”这一关键反证，因为“竞争加剧”在训练数据中是更常见的归因模板。

• 推理需要抽象与泛化，自回归依赖具体模式匹配。真正的推理能从“苹果落地”抽象出“万有引力”，再泛化到“月球绕地”。LLM的泛化，是基于n-gram相似度的模式迁移。它能把“手机没电关机”类比到“电动车电池耗尽停驶”，是因为两者在语料中共享大量修饰词（“电量低”“自动关机”“需要充电”）；但它很难把“供应链中断导致芯片短缺”类比到“物流瘫痪导致药品断供”，因为这两个事件在语料中的共现特征太少，且涉及不同领域的实体与关系。这种泛化能力的局限，正是它无法进行跨领域深度推理的根源。

3. “幸运”从何而来？拆解LLM高置信度输出的四大支撑点

3.1 语料密度优势：在高频场景中，它比人类更“懂行”

LLM的“幸运”，首先源于它对人类知识库的暴力覆盖。一个经过万亿token训练的模型，相当于读完了人类公开出版物的绝大部分。这种规模带来一种独特优势：在那些被充分记录、反复讨论、模式高度固化的领域，它的表现远超单个专家。我负责过一个电力调度指令生成项目，要求模型根据实时负荷曲线、机组状态、检修计划，生成符合《电网调度规程》的指令文本。初期我们担心模型会编造规程条款，结果发现：它对规程原文的记忆精度极高，能准确引用“国调中心[2021]12号文附件3第5.2.1条”，甚至能指出不同版本间的细微差异。这不是理解，而是超高密度的模式存储。在调度员日常工作中，90%以上的指令场景都属于“标准操作”——负荷突增→调用备用机组→调整AGC设定值。这些场景在培训教材、事故汇编、调度日志中被反复书写，形成了极其稠密的语料簇。模型只需匹配当前输入与这些稠密簇的相似度，就能输出高度合规、专业、流畅的指令。此时它的“幸运”，是统计学上的必然。相比之下，一个刚入职的调度员，需要数月实践才能建立起这种条件反射式的响应能力。LLM把这个过程压缩到了毫秒级。但这恰恰印证了“不思考”：它不需要理解“为什么调用备用机组”，只需要知道“当负荷突增时，99.7%的规范文本都紧接着写‘立即调用备用机组’”。

3.2 提示工程杠杆：用结构化输入撬动结构化输出

“幸运”并非随机，而是可以通过精巧的输入设计大幅提高。提示工程（Prompt Engineering）的本质，是为LLM的统计引擎提供最清晰的“搜索指令”。我总结出四类最有效的提示结构：

• 角色锚定法：明确指定模型在本次交互中的身份与权限。例如，在法律咨询场景，不用“请解释合同违约责任”，而用“你是一名有15年经验的商事律师，仅依据《民法典》第五百七十七条及最高人民法院关于买卖合同司法解释第二十一条，向客户解释违约金调整的法定条件。禁止推测、禁止使用‘可能’‘大概’等模糊表述。” 这种提示将模型的输出范围，从整个法律语料库，精准收缩到特定法条及其权威解读的子集，显著降低“幸运”的随机性。

• 思维链（CoT）显式化：强制模型暴露其“推理”步骤，实则是引导它调用更多相关语料片段。例如，在计算“某工厂月度能耗成本”时，提示：“请分三步回答：第一步，列出计算所需的所有原始数据（如电价、各车间用电量、峰谷平时段划分）；第二步，写出成本计算公式；第三步，代入数值计算结果。” 这并非教会模型算术，而是利用其对“分步解答”这一格式的熟悉度，触发它从训练数据中检索出大量类似结构的解题范例，从而拼接出正确答案。我在制造业能源审计项目中测试过，加入CoT提示后，计算类问题的准确率从68%提升至94%。

• 少样本（Few-shot）示范：提供2-3个高质量的输入-输出对，相当于给模型一个微型的、任务专属的“微调数据集”。关键在于示范必须真实、典型、无歧义。例如，在识别设备故障代码时，我提供的示范是：“输入：‘ALARM 007’，输出：‘主轴编码器信号丢失，检查CN2接口接线’；输入：‘ERR 221’，输出：‘冷却液液位低于下限，检查储液罐及浮球开关’”。这比单纯说“请翻译故障代码”有效得多，因为它直接告诉模型：“你要匹配的，是这种‘代码→具体部件+具体动作’的映射模式”。

• 输出约束法：用格式、长度、关键词等硬性规则框定输出空间。例如，在生成安全巡检报告时，要求：“输出必须为Markdown表格，包含‘检查项’‘标准值’‘实测值’‘状态（合格/不合格）’‘处置建议’五列，且‘处置建议’必须以‘立即’‘24小时内’‘本周内’开头。” 这种约束极大压缩了模型的采样空间，使其几乎只能从训练数据中那些高度结构化的巡检报告模板中进行匹配，从而保证了格式统一与内容相关性。

3.3 概率校准技巧：如何让“幸运”变得可预期、可管理

LLM的输出自带概率分数（logits），但原始分数往往未经校准，不能直接反映真实置信度。我开发了一套轻量级校准方法，让“幸运”变得可量化：

• 自我一致性检验（Self-Consistency）：对同一问题，让模型生成5-7个独立答案，统计最高频答案的出现比例。在我们的设备故障诊断系统中，我们将此比例作为“模型置信度”。当比例≥80%时，系统自动采纳；50%-79%时，标记为“需人工复核”；<50%时，触发“扩大上下文”或“切换提示模板”流程。这比单纯看模型返回的“置信度分数”可靠得多，因为它基于模型自身行为的统计稳定性。

• 对抗性扰动测试：对输入进行微小但语义相关的扰动，观察输出变化。例如，在输入中加入“根据最新版维护手册”，或改为“假设设备已服役8年”，看关键结论是否改变。如果结论随无关扰动剧烈波动，说明其“幸运”基础脆弱。我们在为某地铁公司做信号系统故障预案生成时，发现模型对“最新版手册”的响应非常敏感，而对“服役年限”的扰动不敏感，这提示我们应优先强化手册版本信息的提取与应用。

• 外部知识源交叉验证：绝不让LLM的输出成为唯一信源。我们建立了三层验证机制：第一层，用规则引擎（如Drools）校验输出是否违反硬性约束（如“处置建议”中不能出现未授权的备件型号）；第二层，用向量数据库检索相似历史案例，比对处置方案一致性；第三层，对高风险结论（如“建议停机检修”），强制调用设备传感器实时数据API进行佐证。只有三层验证均通过，才允许输出。这套机制将LLM的“幸运”转化为了一个可审计、可追溯的决策节点。

3.4 微调（Fine-tuning）的真相：不是赋予思考能力，而是定制幸运模式

很多人认为微调能让LLM“学会思考”，这是巨大误解。微调的本质，是在原始大模型的庞大参数空间上，雕刻出一个更贴合特定任务分布的小型概率子空间。它不改变模型“不思考”的底层逻辑，只是让它的“幸运”更集中于你的业务场景。

我主导过两个典型的微调项目：

• 法律文书要素抽取微调：原始Qwen2-7B在抽取“当事人名称”“案由”“诉讼请求”时F1值为72%。我们用500份真实判决书做LoRA微调，仅训练0.3%的参数。微调后F1升至89%。分析错误样本发现，提升主要来自两点：一是模型对“原告”“被告”等关键词的敏感度大幅提升，减少了漏抽；二是对长句中嵌套的当事人信息（如“原告：张三，系XX公司法定代表人”）的切分更准确。这并非模型理解了法律主体概念，而是它在微调数据中，反复看到“原告：”后紧跟姓名的模式，从而强化了这一局部关联。

• 工业设备维修知识图谱补全微调：目标是让模型能根据故障现象，补全缺失的“根本原因→失效模式→检测方法”三元组。我们用2000条专家标注的三元组，构造了“现象描述→[原因, 模式, 方法]”的微调数据。微调后，模型在补全任务上准确率达76%，远超零样本的31%。但深入分析发现，它补全的76%中，有61%是直接从微调数据中复制粘贴的完整三元组，其余15%是微调数据中三元组的变体组合（如将“轴承磨损→振动增大→频谱分析”与“齿轮断裂→异响→声发射检测”组合成“轴承磨损→异响→声发射检测”）。它依然没有构建出新的因果链，只是在微调数据定义的“幸运池”里，捞到了更匹配的鱼。

因此，微调的价值，在于将LLM的“幸运”从“大海捞针”，变成“在你指定的鱼塘里精准撒网”。它降低了不确定性，但没有消除不确定性。一个经过完美微调的模型，依然会在它从未见过的、超出微调数据分布的新颖故障上“失手”。这才是我们必须时刻牢记的边界。

4. 实操指南：如何在真实项目中与“不思考”的LLM共舞

4.1 项目启动前：用“思考能力清单”做可行性预筛

在立项任何LLM应用前，我坚持用一张简单的“思考能力清单”进行预筛。这张清单不评估技术难度，而评估任务本身是否与LLM的底层能力错配。清单包含5个核心问题，每个问题只需回答“是”或“否”：

我曾用这张清单否决了一个“用LLM预测客户流失”的项目。尽管销售总监非常期待，但清单第2条（预测）和第5条（高失败代价）同时亮红灯。我们转而构建了一个基于RFM模型和行为序列的规则引擎，准确率稳定在81%，且所有预测均可追溯到具体行为指标，上线后客户经理反馈“终于知道该找谁、问什么了”。LLM的“幸运”在这里不是解决方案，而是干扰项。

4.2 系统架构设计：构建“LLM+”的稳健工作流

成功的LLM应用，从来不是“把LLM塞进去”，而是设计一个让LLM在其能力边界内发挥最大价值的系统。我推荐一种经过6个项目验证的“LLM+”四层架构：

• 第一层：输入净化与增强层
  这是整个系统的基石。它不信任原始输入。例如，在处理客服工单时，原始文本“机器老是卡，重启也不行，急！”会被送入此层：首先用正则和NER模型提取设备型号、软件版本、错误代码（如有）；其次，用向量检索从知识库中召回3个最相关的已解决案例摘要；最后，将“原始文本+提取字段+召回摘要”组装成结构化提示。这层工作将LLM的输入，从“模糊抱怨”变成了“带上下文线索的结构化问题”，直接将其“幸运”的起点，从随机海洋拉回到了高概率陆地。

• 第二层：LLM核心处理层
  这一层只做一件事：在净化后的输入上，执行单一、明确、可验证的子任务。例如，不是让LLM“解决客户问题”，而是让它“从召回的3个案例中，选出最匹配当前症状的一个，并输出匹配理由”。任务越窄，LLM越稳。我们严格限制此层的输出格式（如必须是JSON，包含"selected_case_id"和"match_reason"两个字段），并设置超时（通常≤3秒），防止其陷入无意义的长思考。

• 第三层：多源交叉验证层
  此层是“幸运”的质检员。它接收LLM的输出，并行启动三路验证：1) 规则校验：检查输出是否违反预设业务规则（如“匹配理由”中不能出现未授权的维修步骤）；2) 数据验证：调用设备API，检查LLM提到的“重启无效”是否与实时状态一致；3) 知识图谱验证：查询图谱中该设备型号与所选案例的关联强度。只有三路验证均通过，结果才进入下一层。任一失败，即触发降级策略（如返回“请提供设备序列号以便进一步诊断”）。

• 第四层：人机协同输出层
  这是最终面向用户的界面。它不直接展示LLM的原始输出，而是将其作为“智能草稿”。例如，对客服坐席，系统显示：“【AI建议】匹配案例#A782（硬盘固件BUG），建议执行固件升级。（点击查看详细步骤与风险提示）”。坐席可以一键采纳、编辑、或完全忽略。所有采纳操作都被记录，用于持续优化LLM的提示模板和验证规则。这个设计，将LLM从“决策者”降级为“高级助理”，既发挥了其信息整合与表达优势，又牢牢守住了人的最终决策权。

4.3 提示工程实战：从“试错”到“可复用”的工程化沉淀

提示工程常被神化，其实它是一门可工程化的手艺。我的团队已将提示开发流程标准化为“四步法”，并沉淀为内部可复用的提示模板库：

• 第一步：任务原子化分解
  拒绝“写一篇报告”这类模糊指令。必须拆解为原子任务。例如，“生成设备年度维护报告”被分解为：①从数据库提取本年度所有维修工单；②按设备类型、故障类别、维修等级聚合统计；③识别出TOP3高频故障；④为每个TOP故障，从知识库召回标准处置流程；⑤将统计数据与流程描述，按公司报告模板组织成文。每个原子任务，对应一个独立的提示模板。

• 第二步：模板参数化设计
  每个提示模板都定义清晰的参数占位符。例如，故障统计模板的结构是：

  你是一名资深设备管理工程师。请基于以下数据，完成统计： 【设备类型】: {device_type} 【时间范围】: {start_date} 至 {end_date} 【原始数据】: {raw_data_json} 要求：输出为纯JSON，包含字段"total_repairs"、"top3_failures"(数组，每项含"failure_code"、"count"、"percentage")。

  这样，前端只需填充{device_type}等参数，即可调用，彻底告别手工拼接提示。

• 第三步：效果AB测试与迭代
  对每个新提示，我们强制进行AB测试：用同一组100个真实样本，对比新旧提示的准确率、响应时长、token消耗。只有新提示在准确率上提升≥5%且token消耗不增，才被采纳。我们曾为“维修建议生成”模板迭代了11版，最终版将“建议”从开放式描述，收敛为“立即/24h/72h/计划内”四档，并强制要求每条建议后跟一个“依据来源”（如“依据《XX设备维护手册》第3.2.1条”），准确率从63%提升至88%，且人工审核时间减少40%。

• 第四步：模板版本化与灰度发布
  所有提示模板纳入Git管理，每次修改都有commit message说明优化点与测试结果。上线采用灰度：先对5%的流量启用新模板，监控错误率、用户采纳率、坐席编辑率等指标。若指标异常，则自动回滚。这套流程让我们在两年内沉淀了47个高复用提示模板，平均每个新项目可复用60%以上的模板，将提示开发周期从平均3天缩短至4小时。

4.4 部署与监控：让“幸运”的波动变得可见、可管、可控

LLM不是部署完就一劳永逸的黑盒。它的“幸运”会随时间漂移，必须建立持续监控体系。我们监控的不是传统服务的CPU、内存，而是LLM特有的“健康度”指标：

• 漂移监测（Drift Monitoring）：每周对线上流量的1%采样，用同一组黄金测试集（50个覆盖核心场景的样本）跑模型，计算准确率、输出长度、token消耗的周环比变化。当准确率下降>3%或token消耗上升>15%时，触发告警。这通常预示着业务数据分布发生了变化（如新设备上线带来新故障代码），或模型本身出现了性能退化。

• 幻觉热力图（Hallucination Heatmap）：不只统计“有没有幻觉”，而是定位“在哪些字段、哪些场景下幻觉高发”。我们开发了一个轻量级解析器，扫描所有LLM输出，标记出：1) 未在输入或知识库中出现的专有名词；2) 无法被规则引擎验证的数值结论；3) 自相矛盾的陈述。然后按“任务类型-输入来源-时间段”三维聚合，生成热力图。例如，热力图曾显示“在处理来自APP端的工单时，‘建议维修步骤’字段的幻觉率高达37%”，追查发现是APP端录入的故障描述过于口语化（如“屏幕花屏”），而知识库术语是“LCD面板像素异常”，中间缺少了标准化映射。这直接驱动了我们在输入净化层增加了“口语化术语→标准术语”的映射模块。

• 人工反馈闭环（Human-in-the-loop Feedback）：在所有LLM输出旁，添加“👍/👎”按钮。用户点击“👎”时，强制填写一个3选项原因：“答案错误”“答案不相关”“答案不完整”。所有反馈实时进入一个待办队列，由提示工程师每日处理。一个“答案不相关”的反馈，意味着提示模板需要优化；一个“答案不完整”的反馈，往往指向知识库更新滞后。这个闭环让我们在3个月内，将用户对LLM输出的满意度从68%提升至89%。

5. 常见问题与避坑指南：那些只有踩过才知道的“幸运”陷阱

5.1 问题：为什么模型在测试集上表现完美，上线后就“变笨”了？

现象还原：我们在实验室用1000条标注数据测试一个合同审查模型，准确率95%。上线后，首批处理200份真实合同，准确率骤降至62%。坐席反馈：“它总把‘不可抗力’条款标为高风险，但这份合同里明明写了‘包括但不限于地震、洪水、政府行为’，这很标准啊。”

根因分析：这是典型的分布外泛化（Out-of-Distribution Generalization）失败。测试集的1000条数据，全部来自某大型律所的标准化模板库，条款措辞高度一致。而真实合同来自数百家中小企业，用语随意：“不可抗力”写成“天灾人祸”，“政府行为”写成“上面不让干了”。模型在训练和测试中，学到的不是“不可抗力”的法律内涵，而是“不可抗力”这个词在标准文本中的固定搭配模式。一旦遇到变体，匹配失败。

独家避坑技巧：

• 测试集必须包含“噪声”：在构建测试集时，主动混入15%-20%的“非标准”样本：用同义词替换（“违约”→“毁约”）、添加口语化表达（“甲方必须付钱”→“甲方得把钱打过来”）、引入OCR识别错误（“不可抗力”→“不可坑力”）。这能提前暴露模型的鲁棒性短板。
• 上线前做“压力测试”：不只用真实数据跑，还要用“对抗样本”测试。例如，对“不可抗力”条款，生成一批变体：“天灾人祸（含地震、洪水、政策调整）”、“上级部门突然叫停”、“因国家法律法规变化导致无法履约”。只有模型能稳定识别这些变体，才算过关。
• 建立“术语映射表”：在输入净化层，内置一个可配置的术语映射表，将常见口语化、错误写法，映射到标准法律术语。这个表由法务人员维护，比让LLM自己学习更可靠、更可控。

5.2 问题：为什么给模型更多上下文（比如上传整本手册），它反而答得更差？

现象还原：为提升设备维修问答准确率，我们将整本《XX设备维修手册》（PDF，287页）切片后存入向量库。用户提问时，系统检索出最相关的5个片段喂给LLM。结果发现，当检索出3个片段时，回答准确率85%；当强制检索10个片段时，准确率跌至52%。模型开始在回答中混入无关手册章节的内容，如用户问“如何更换滤芯”，它却大段描述“电机拆卸步骤”。

根因分析：这是上下文污染（Context Pollution）。LLM的注意力机制，并非精准聚焦于“最相关”的片段，而是对所有输入token进行全局加权。当无关片段（如电机拆卸）与相关片段（滤芯更换）同时存在时，模型会从无关片段中提取出高频词汇（“螺丝”“扳手”“拆卸”），并将其与相关片段中的“滤芯”强行组合，生成看似专业、实则荒谬的“更换滤芯需先拆卸电机”的答案。上下文不是越多越好，而是越精准越好。

独家避坑技巧：

• RAG不是“扔进去”，而是“挑出来”：放弃“检索Top-K”，改用“检索+重排序（Rerank）”。先用向量检索初筛20个候选，再用一个轻量级交叉编码器（Cross-Encoder）对这20个做精细打分，只取Top-3。我们用bge-reranker-base做重排序后，相关片段召回准确率提升31%，上下文污染率下降至5%以下。
• 为每个检索片段打“可信度分”：在向量库中，不仅存储文本，还存储其来源章节的权威性得分（如“官方维修指南”=1.0，“用户经验分享”=0.3）。检索时，将文本相似度与权威性得分加权融合，确保高权威性但稍低相似度的片段，也能被选中。
• LLM提示中明确“聚焦指令”：在提示中加入：“你只能依据以下【检索片段】作答，严禁引入【检索片段】之外的任何知识。如果【检索片段】中未提及某信息，请回答‘未提及’。” 这虽不能杜绝幻觉，但能大幅降低其发生概率。

5.3 问题：为什么微调后模型在训练数据上过拟合，但在新样本上还不如微调前？

现象还原：我们用300条“电力调度指令”微调Qwen2-1.5B，微调后在300条训练数据上准确率99%，但在100条新采集的指令上，准确率仅61%，而原始未微调模型在新