LLM从原理到落地：本地部署、微调评测与Agent容错全路线

我现在刷信息流的时候，满屏都是“LLM是什么”“大模型框架”“本地跑 GGUF”“LLM as Judge”“Agent 出错怎么排查”这类热搜词。看下来最大的感受是：想学 LLM 的人很多，但真正能一条线走通的人很少。大部分人卡在同一个路口——概念看了不少，真到自己动手做一个能用、能评、能稳定上线的应用，又不知道从哪里下手。

这个系列我就打算按一条完整的路线来写：《深入学习 LLM(一)》先解决“地基”问题——模型到底是什么、工具链怎么选、本地怎么跑、数据怎么微调、效果怎么评测、Agent 怎么做可靠。后面再逐步展开更深的内容。内容偏工程实践，适合三类人：刚入门的开发者、准备在业务里落地大模型应用的工程师、以及想搞明白“大模型项目为什么总在最后一步翻车”的产品和技术负责人。

这一篇的信息量会比较大，我会尽量少讲空话，多放可以直接抄走的判断标准、参数和踩坑记录。

1. 先把基础打对：LLM 到底是什么

1.1 从“预测下一个词”到“能力涌现”

很多人对 LLM 的第一印象是“特别聪明、什么都会”。但如果只保留一句准确的话来描述它，应当是：LLM 是一个做“下一个词预测”的概率模型。给定一段上文，它计算下一个最可能出现的词（严格来说是 token）是什么，然后不断重复这个过程，生成整段内容。

这个本质决定了它的很多脾气。比如它会一本正经地编造不存在的引用，因为对它来说“编一个像样的引用”和“说出真实引用”在概率上都是合法的延续；它也不擅长算术，因为把数字拆成 token 之后，计算路径并不稳定。理解这一点，能避免你对模型产生不切实际的期待。

支撑这一能力的基础架构是 Transformer。它最关键的设计是自注意力机制（Self-Attention），简单理解就是：模型在处理某个词的时候，会动态计算它和序列中其他词的相关程度，从而决定“该重点参考哪些上下文”。这也是为什么 LLM 能做“根据前文理解后文”，而不是像老式 n-gram 模型那样只看紧邻的几个词。

在训练流程上，主流模型基本都走“三段式”：

1. 预训练：在海量文本上做自监督学习，目标是预测下一个词。这一步让模型获得语言能力和世界知识。
2. 指令微调（SFT）：用大量“用户问题 + 标准回答”对模型做监督训练，让它学会服从指令、用对话形式回答。
3. 对齐（RLHF / DPO 等）：让模型输出更符合人类偏好，比如更有帮助、更安全、更简洁。

到了指令微调之后，模型才表现出大家熟知的指令跟随（Instruction Following）、**上下文学习（In-Context Learning）和一定程度的思维链（Chain-of-Thought）**能力。这些能力被统称为“涌现能力”，听起来很玄，但从工程视角看，你可以把它们理解为“模型在语料中见过足够多类似模式后，产生的一种复杂模式匹配”。不需要把它当成魔法，只需要知道：这是一把双刃剑——模式匹配既让它灵活，也让它容易“幻觉”。

1.2 为什么大模型这么“听话”：指令对齐与提示工程

“听话”这个词很形象。一个 Base 模型（只有预训练阶段的模型）你问它问题，它大概率会续写一段百科式文本，而不是正经回答你。真正让它“变成对话助手”的，是对齐阶段的数据和训练方式。

所以你在写 Prompt 时，本质上是在和“对齐后的默认行为”打交道。常用 Prompt 结构包括三部分：

• System 指令：定义模型角色、任务目标、输出格式。
• User 输入：具体请求。
• Assistant 输出：模型回答。

实操中我强烈建议你对任何生产级 Prompt 都显式写 System 指令，哪怕很简单。这能明显减少模型“自由发挥”的概率。举个最简单的例子，你让它“总结会议纪要”，如果只给一句原文，它可能输出一个带小标题的长篇总结；如果 System 里写明“只输出 5 条结论，每条不超过 20 字，不要解释”，输出就会稳定得多。

几个经常被忽略但很重要的参数意识：

• Temperature：控制随机性。做抽取、分类、代码生成时建议调到 0~0.2；做创意写作、头脑风暴可以 0.7~1.0。
• 上下文窗口：窗口越大不等于效果越好。模型对中间内容的关注度往往弱于开头和结尾，这在技术上称为“lost in the middle”。需要长上下文时，把关键指令放在 System 或末尾，比堆在中间更有效。
• 输出长度：限制 max_tokens 能显著避免模型啰嗦，也可以降低成本。

提示：入门阶段做一个“温度对比实验”特别有帮助。用同一个高质量 Prompt，temperature 分别设为 0.2 和 0.9，各生成 10 次，观察输出的稳定程度。你会发现不少业务场景里，低 temperature 的稳定性远比你想象的重要。

2. 学习路线与工具链选型：框架不是万能的

2.1 先跑通 API，再碰本地模型

我发现很多新人一上来就想本地部署大模型，理由通常是“不想花钱”“有隐私需求”或“听起来很酷”。这些理由可以理解，但从学习效率看，第一条路径应该是调用 API。原因很简单：API 让你把精力集中在 Prompt、逻辑、评估这些真正重要的工程问题上，而不是被 CUDA 版本、内存不足、量化效果这些环境问题劝退。

等你用 API 跑通一个完整小应用（比如“文档问答”或“角色扮演机器人”）之后，再回到本地部署，你会更明白本地模型该调什么、不该调什么。否则你会在模型下载和依赖安装上花掉一周，却连“这个模型的效果到底好不好”都判断不了。

什么时候需要用 LangChain 这类框架？我认为有清晰判断标准：

• 需要串联多个模型调用或工具调用时：比如“先判断意图 → 再查数据库 → 再生成回答”的工作流，框架的 Chain / Graph 能力确实省事。
• 需要多种模型切换时：LiteLLM 这类工具能统一 API 格式，切换到不同供应商不修代码。
• 需要成熟组件时：比如文档切分、向量检索的封装，LlamaIndex 比你自己写更稳。

什么时候不适合用框架？当你的逻辑只有“一个 Prompt 进去，一个输出出来”时，别用框架。直接调用 SDK 更简单、更好排查、依赖更少。框架的优势在抽象和编排，但代价是隐藏细节。一旦输出不符合预期，你得先判断是模型的问题、Prompt 的问题、还是框架内部做了你不知道的变换。这会浪费大量时间。

我自己的项目里，大概 70% 的调用是直接写 SDK 完成的，只有 30% 涉及多步编排才引入框架。这个比例供你参考。

2.2 主流框架和个人“LLM Wiki”

给还没接触过框架的读者列一个快速对比：

这里多提一句热词里的“LLM Wiki”。我认识不少高质量从业者，几乎每个人都有自己的“LLM 笔记库”，内容不是概念抄录，而是项目记录：模型名字和版本、Prompt 版本、参数配置、评测结果、失败样例、成本记录。这种做法非常重要，因为 LLM 应用的调试是高度实验性的，没有记录，你等于没有积累。

我建议你也建一个个人 LLM Wiki，核心字段至少包括：任务目标、数据来源、模型与参数、Prompt 全文、评测指标、失败案例。每次实验都记录，一个月后回看，你会发现自己避开了大量重复的坑。

3. 本地部署实战：GGUF 量化和安卓手机运行

3.1 为什么选 GGUF 格式

本地部署绕不开一件事：怎么把动辄几十 GB 的模型塞进你的显卡或者内存里。这时候 GGUF 格式就派上用场了。

GGUF 是 llama.cpp 项目推出的模型格式，核心特点是把所有东西打包成一个文件：模型的权重、tokenizer 配置、特殊 token、元信息都包含在内。相比传统的 safetensors 格式，GGUF 更适合 CPU 推理和边缘设备，因为它对权重的编码方式做了量化优化。

量化这个词如果你第一次见，可以用图片来类比：一张 4K 照片原图很大，压成 JPEG 后变很小，肉眼看差别不大。模型的量化也类似，把原本用 16 位浮点数表示的权重，转成 4 位或 8 位表示，模型体积大幅缩小，推理时占用的内存或显存也降低很多，质量略有损失但通常可接受。

常见的量化等级和取舍我放在表里：

选型口诀：显存/内存决定上限，质量敏感度决定档位。8GB 显存跑 7B 模型，选 Q4_K_M 是最稳的；如果你确定模型质量下降明显，再考虑降低模型规模（比如换成 3B 或 1.5B）而不是硬上高量化。

3.2 在电脑上快速跑起来

本地推理我建议从 Ollama 开始，它是我试过对新手最友好的工具。安装后拉模型即可：

# 拉取一个量化好的 7B 模型 ollama pull qwen2.5:7b-instruct-q4_K_M # 运行并进入交互式对话 ollama run qwen2.5:7b-instruct-q4_K_M

Ollama 支持通过 Modelfile 自定义参数，例如设置 temperature：

FROM qwen2.5:7b-instruct-q4_K_M PARAMETER temperature 0.2

如果你更愿意用底层一点的 llama.cpp，流程也简单：从 GitHub 克隆源码，编译后直接用命令行推理。编译前确认架构，N 卡用 CUDA 加速，纯 CPU 则用原生版本：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON cmake --build build --config Release -j 4

实测下来，影响推理速度的最大因素是内存带宽，而不只是 CPU 算力。笔记本在纯 CPU 情况下跑 7B Q4，大约能到 5~8 token/秒，能接受但不算流畅；桌面高性能 CPU 能到 10+ token/秒。如果你的预期是“像 ChatGPT 一样秒回”，本地小模型目前很难满足，这一点务必提前想清楚。

提示：跑本地模型时，一定要确认你使用的是量化版模型文件。很多人下载了一个 14GB 的原版 7B 模型，还在抱怨内存爆掉——量化和非量化的差别，跑之前先看清楚。

3.3 安卓本地运行：支持 Android 8 的方案

热词里有“安卓本地运行 GGUF 格式 LLM，支持安卓 8”，这个我专门验证过，答案是可行，但需要管理预期。

最稳的方案是 Termux。Termux 是安卓上的终端模拟器，可以把它理解成手机上的一台 Linux 小机器。在 Termux 里编译 llama.cpp 的 Android 版本，然后加载你下载好的 GGUF 模型文件。步骤大致如下：

# 在 Termux 中 pkg update && pkg install git cmake build-essential git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 在安卓上编译 CPU 版本即可，不需要 CUDA cmake -B build cmake --build build --config Release -j 4

之后把 GGUF 文件放到手机存储中，运行：

./build/bin/llama-cli -m /sdcard/Download/your-model.Q4_K_M.gguf -p "你好，介绍一下你自己"

针对 Android 8 的兼容性，有几点实测经验：

• 尽量选择aarch64 体系的手机（也就是近几年的主流 arm64 机型），不要用老旧的 32 位系统。
• 模型体积控制在2GB 以内，推荐 1.5B~3B 的 Q4 量化版本。7B 在手机上体验很差，每生成一个 token 都要等很久。
• 手机内存至少4GB 起步，低于这个值建议放弃本地运行的念头。
• 使用过程中手机会明显发热，这是 CPU 满载导致的正常现象，长时间运行注意散热。

这类方案适合你“在通勤时研究一下 prompt 逻辑”，但把手机当成正经推理服务器，目前还不太现实。

4. 用聊天记录精调 LLM：从数据到 LoRA 的一条线

4.1 为什么聊天记录是好数据

如果你想做一个特定风格的对话机器人，比如客服助手、特定人设的聊天机器人，拿真实聊天记录做微调是性价比很高的方案。理由很直接：聊天记录就是用户和助手互动的真实样本，里面包含你想要的语气、问题类型、回答风格，比人工编造的数据要自然得多。

但聊天记录不能直接用，原因有三：

• 隐私风险大：聊天记录可能包含姓名、手机号、地址等敏感信息，必须先脱敏。
• 噪声多：大量消息是“嗯”“好的”“收到”这类无效内容，需要过滤。
• 格式不统一：不同来源的记录字段都不一样，要整理成模型训练需要的结构。

一个简单的数据转换思路是把原始记录格式化成统一的 JSONL。假设原始聊天日志长这样：

[ {"from": "user", "text": "你们发货用哪家快递？"}, {"from": "assistant", "text": "默认用顺丰，您下单后我会把单号发给您。"} ]

转换成训练格式后，每行是一条完整对话样本，符合 System/User/Assistant 结构：

{"messages": [{"role": "system", "content": "你是某店铺的售后客服，回答简短友好。"}, {"role": "user", "content": "你们发货用哪家快递？"}, {"role": "assistant", "content": "默认用顺丰，您下单后我会把单号发给您。"}]}

做数据清洗时，我建议按这四步走：

1. 去重：同一条消息反复出现会放大模型对该内容的过拟合。
2. 过滤：删除过短的、无意义的、纯表情的对话。
3. 脱敏：用规则或正则把手机号、邮箱、地址替换为占位符。
4. 重组：把多轮对话切成不超过目标上下文长度的独立样本。

注意：任何来源的聊天记录，只要不是你自己生产的，都要确认数据合规性。清洗完数据再拿给模型训练，是个人和团队都应该养成的习惯。

4.2 LoRA 微调实操注意点

全量微调一个大模型对于个人开发者来说不现实，显存不够是一个方面，另一个方面是你也不需要。用LoRA（Low-Rank Adaptation）是目前的主流做法。它的思路是冻结原有模型参数，只额外训练一小部分“旁路”参数。你可以把它想象成给模型加了一个“可拆卸的适配器”，效果只影响你训练过的领域，还会保留原有模型的通用能力。

实际操作中我会优先用这两个训练方案：

• LLaMA-Factory：界面友好，内置了大量数据集格式支持，适合快速实验。
• HuggingFace PEFT + TRL：更底层，适合需要定制训练逻辑的团队。

LoRA 的几个关键参数，直接给结论：

• rank（秩）：通常 8~32 之间。rank 越大，可学习的参数越多，但也更容易过拟合。对话风格类任务，8~16 够用。
• alpha：一般为 rank 的 2 倍，是 LoRA 输出的缩放因子。
• 学习率：1e-4 到 2e-4 是常见区间，不要太大，否则容易崩。
• epochs：对话数据量几千到几万条时，2~3 轮即可；更多的轮次很容易过拟合。

另外一个特别容易被忽略的细节是：训练数据的对话格式必须与模型自带的 chat template 完全一致。很多模型微调后出现“回答前言不搭后语”的诡异现象，原因不是模型没学会，而是训练时用的格式和模型原本的格式不一致，导致模型在推理时不知道该按什么规则生成。训练前先确认对应模型的 chat template 长什么样，再把你的数据传成同样的格式。

验证阶段，我强烈建议单独留出一批“模型在训练时没见过的聊天记录”做测试。微调前后的同一个问题各跑一遍，对比回答风格、信息准确性、是否产生“记忆错乱”。如果在测试集上回答质量明显提升、但常识能力下降，说明过拟合了；这时候可以混入 20%~30% 的通用指令数据一起训练，能有效缓解。

5. 评测、LLM as Judge 和基于 LLM 的自动化单元测试

5.1 怎么客观评估一个 LLM 应用

大多数团队在大模型项目上翻车，不是模型选错了，而是没有一套评测方法。大家往往靠“肉眼看看回答怎么样”来判断效果，这种感性判断在 Demo 阶段可以，但一旦要上线，会变得非常不可靠——因为同一个 Prompt 换一次输入，输出质量波动可能非常大。

我建议哪怕是小项目，也先建一个基础评测集，包含三类样本：

• 标准正确样本：输入明确了预期答案，可以用字符串匹配或模型判断对错。
• 边界样本：比如空输入、超长输入、包含错误信息的输入。
• 对抗样本：故意诱导模型输出不安全内容、幻觉内容。

评测指标可以分成四类：

其中“稳定性”我特别想强调：很多项目的 Prompt 在评测集上效果不错，但日志显示用户反馈时好时坏。原因通常就是 temperature 偏高且没有做多轮抽样测试。稳定性测试方法很简单：固定输入和参数，重复调用 10 次，计算输出的差异程度。

5.2 LLM as Judge 的正确用法

人工评测样本量一大就吃不消，于是“用强模型评价弱模型输出”的思路被广泛应用，这就是 LLM as Judge。它在主观任务上很有用，比如摘要质量、文案吸引度、代码风格，这类没有唯一正确答案的场景，人工打分又贵又慢，LLM 反而能给出相对一致的评分。

但 LLM as Judge 有三个已知偏差，使用前务必了解：

• 自偏好偏差：它对“和自己风格相似的输出”打分会偏高。
• 长度偏差：更长的回答往往得到更高分，哪怕内容啰嗦。
• 位置偏差：两个回答放在前还是放后，会影响裁判的判断。

缓解手段也很明确：

1. 用Rubric 评分细则，在 Prompt 里写清楚每个分数档位对应的标准。
2. 多次交换候选回答顺序，取平均分。
3. 使用多个不同模型交叉打分，消除单一模型偏好。
4. 引入少量人类标注做校准，发现 Judge 偏移时及时调整 Prompt。

实际用的时候，比如评价一个摘要模型，Judge 的 Prompt 可以长这样：

请根据以下评分标准为摘要打分（1-5分）： - 5分：信息完整、语言流畅、没有冗余 - 3分：核心信息保留，但有明显冗余或遗漏 - 1分：关键信息丢失或内容错误 【原文】 {original_text} 【候选摘要】 {candidate_summary} 只输出分数和一句简短理由。

注意，Judge 本身也会受到温度影响，建议 temperature 设为 0，并且同一对输出跑多次取均值。

5.3 用 LLM 生成单元测试

编程方向的读者应该对“基于 LLM 的单元测试”这个热搜词很感兴趣。思路是用 LLM 自动生成测试用例，辅助工程师提升覆盖率。比如你写了一个函数，自己懒得枚举边界条件，可以让模型先看代码，再生成测试计划和用例。

我的实践是先让模型做两步输出，而不是直接让它写完整测试文件：

第一步，生成测试计划：

下面是函数代码，请列出 5 个最有价值的测试场景，包含正常输入、空输入、边界值、异常输入，并说明每个场景的预期行为。 {code}

第二步，再根据测试计划生成测试代码。这样生成出来的代码可理解性远高于一步到位生成。

如果你用的是 Python + pytest，生成的测试大致长这样：

import pytest def test_normal_input(): assert my_function(10) == 20 def test_empty_input(): with pytest.raises(ValueError): my_function("") def test_boundary_value(): assert my_function(0) == 0

但 LLM 生成单测有几个绕不开的坑，我踩过之后总结如下：

• 幻觉断言：模型会生成“看起来很有道理但实际是编的”预期值。这种用例跑起来可能因为断言错误而失败，反而误导你去改正确的代码。
• 边界遗漏：模型更习惯生成常见输入，对极端类型（比如超大整数、None、嵌套结构）经常漏掉。
• 代码与测试不匹配：如果函数签名或行为发生变化，旧测试不会自动更新，容易累积成问题。

排查这类问题的方法就是：先审测试计划，再生成测试代码，最后跑测试看失败原因。不要让 LLM 生成的测试用例直接进入 CI，一旦出现“红了一片”，先判断是测试错了还是代码错了。

另外一个很常见的工程报错是：

LLM request failed: provider rejected the request schema or tool payload.

这个报错通常出现在给函数传入工具定义时。原因是工具调用（function calling）的 JSON Schema 不符合模型 API 的要求，比如缺少 required 字段、参数类型写错、或者附加了 API 不支持的字段。排查思路很简单：把发送给 API 的完整工具定义打出来，用 JSON Schema 的校验器查一圈，再对照 API 文档逐一核对字段名。大多数情况下问题出在“你以为的字段名”和“API 真正要求的字段名”不一致。

6. LLM 智能体、容错控制与安全红线

6.1 从“聊”到“做”：Agent 的基本骨架

LLM 本身只能“说”，不能“做”。Agent 的出现，本质上是把 LLM 放到一个循环里，让它能调用外部工具、观察结果、再决定下一步动作。

目前业界最常见的一种骨架是 ReAct 模式，流程如下：

1. 思考（Thought）：模型分析当前状态，决定该做什么。
2. 行动（Action）：模型输出一个工具调用请求，比如“查询天气 API，参数 city=北京”。
3. 观察（Observation）：系统执行工具，把结果返回给模型。
4. 循环：模型根据观察结果继续思考，直到达到终止条件。

工程实现时，你需要维护一个“工具集”和一个“循环控制器”。工具集是 JSON Schema 描述的函数列表，循环控制器负责调用模型、解析输出、执行工具、拼接历史。

这个看似简单的循环，实际在生产环境里会遇到大量问题。最常见的几类包括：

• 模型输出了格式错误的工具参数，导致解析失败。
• 模型陷入了循环，反复调用同一个工具而不推进任务。
• 工具执行超时，但模型还在等待结果。
• 模型给出的下一步动作明显不合理，但系统没有拦截机制。

6.2 构建可靠的容错控制系统

要构建真正可用的 Agent，关键是容错控制。我看热词里那篇论文标题讲的就是“LLM 智能体自主容错控制：构建可靠 AI 系统的工程实践”，这一类问题在真实业务里非常值得重视。

我的建议是给 Agent 加上五道防护：

• 超时与重试：每次工具调用设置超时时间（建议根据工具平均耗时动态调整），超时后重试一次，再失败则让模型换路径。
• 最大步数限制：防止模型失控地无限循环。一般任务不要超过 10 步。
• 循环检测：记录最近的工具调用序列，如果同一工具、同一参数重复出现多次，直接终止或切入人工提示。
• 格式校验：在模型输出传给工具之前，用 JSON Schema 做一次校验，格式不对就返回错误信息让模型自己修正。
• 输出护栏：对模型最终输出做敏感词过滤或规则校验，避免错误信息直接给用户。

这里特别想提一下“记忆与知识库投毒”的安全风险。业界已经出现类似 AgentPoison 的研究：攻击者通过在 Agent 的记忆库或知识库中注入恶意内容，诱导 Agent 在后续决策时输出攻击者想要的结果。通俗来说，Agent 会“读什么信什么”，如果你直接让它检索外部知识库或长期记忆，而没做来源可信度校验，它很可能把注入的假信息当成事实用于决策。

防御思路不是不用知识库，而是做几件事：

• 检索结果白名单：只允许 Agent 读取可信来源的内容。
• 来源标注：让检索结果带上来源 ID，Agent 输出时标注引用。
• 最小权限：Agent 调用的工具只给完成任务所需的最小权限，不要把数据库写权限也交付给模型。
• 输入输出过滤：对写入记忆库的内容先做一遍敏感词和格式审查。

注意：安全不是上线前才考虑的事。只要你的 Agent 涉及外部数据或用户数据，就应该在架构设计阶段把这些防护加进去。后期补防护，成本会高很多。

最后再分享一个我的经验

这个系列的第一篇，我从模型原理写到了工具链、本地部署、微调、评测和 Agent 容错，内容跨度很大。但我最想让你带走的一句话是：大模型项目真正的难点，从来不是模型本身，而是模型之外的数据、评测和工程边界。

我自己早期做项目时，把大量时间花在“换更强的模型”上，结果效果不稳定，问题根本不是模型不够强，而是评测集太随意、Prompt 没版本管理、Agent 没有容错设计。后来一点点把“LLM Wiki”建起来，每一个实验都记录、每一次失败都归因，项目的进展反而变快了。

建议你从今天开始做一件很小的事：建一个文档，把你下一个 LLM 实验的任务目标、数据、模型、参数、测评结果和失败案例记录下来。等这个系列写到后面几篇，你再回头看这份记录，会发现它比任何教程都有价值。