Shivacon-Energy：0.5B能源模型如何做到零幻觉

在小型语言模型（SLM）被大量塞进智能体流水线的今天，一个尴尬的现实是：它们经常自信地编造事实，还会把工具调用依赖的 JSON 格式搞得一团糟。大多数微调版本让这个问题变得更严重——模型记住了狭窄的模式，却流畅地编造事实。GitHub 上的 Shivacon-Energy 项目给出了另一种解法：一个 0.5B 参数的能源领域 LoRA 适配器，它的卖点不是「懂得更多能源知识」，而是「宁愿说不知道，也不编造数字，并且每次都能输出合法 JSON」。

一个反常识的微调目标：校准优先于知识

Shivacon-Energy 基于 Qwen2.5-0.5B-Instruct 做 LoRA 微调，rank 16、alpha 32，可训练参数约 880 万，仅占模型的 1.75%。训练数据只有 1596 行，涵盖拒绝样本、反幻觉示例、校准配对和工具轨迹。整个训练在免费的 Google Colab T4 上完成，300 步、3 个 epoch、学习率 2e-4，训练损失 0.4018，验证损失 0.08377。

这个项目的核心洞察来自一个结构性判断：0.5B 的模型不可能装下深度能源专业知识，34MB 的适配器也改变不了这一点。但小模型在流水线中可以做的是成为一个可靠组件——在能力范围内回答问题，超出范围就拒绝，并输出机器可读的格式。作者在 README 中直言不讳：适配器的价值在于校准，而非知识。

LoRA（Low-Rank Adaptation）是一种参数高效微调技术，其核心思路是在预训练模型的权重矩阵旁注入一对低秩矩阵（A 和 B），训练时只更新这两个小矩阵，而冻结原始权重。rank（秩）和 alpha 是 LoRA 的两个关键超参数：rank 决定低秩矩阵的维度，进而控制可训练参数的数量和适配器的表达能力——rank 越高，可训练参数越多，拟合能力越强，但也越容易过拟合；alpha 则是缩放因子，用于调节 LoRA 更新量对原始权重的相对影响，通常与 rank 保持一定比例（如 alpha 为 rank 的两倍）以稳定训练。在本例中，rank 16、alpha 32 意味着新增的可训练参数仅约 880 万，占 0.5B 模型的 1.75%，这使得微调成本极低，但也从根本上限制了模型能学到的新知识量。

四道「可售卖性」关卡：9 个适配器只活了 1 个

这个仓库真正区别于普通「我微调了一个模型」帖子的地方，是它设计了一套四关评测装置（4-gate sellability harness）。9 个不同领域的适配器——能源、教育、健康、销售、营销、研究、核心、通用等——都跑了同一套测试。评测在真实 CPU 推理上运行，使用贪心解码和逐提示超时，结果如下：

关卡	得分	含义
G1 基础模型对比（6 个提示）	0胜/0负/6平	与基础模型打平，零回退
G2 领域任务	9/10	一个实际建议回答出现乱码
G3 未知诚实度	5/5	承认不知道光伏数据，并指向来源
G3 拒绝能力	5/5	拒绝预测油价或编造事实
G4 JSON/工具格式	5/5	每次输出干净、格式正确的 JSON
幻觉率	0/10	—

9 个适配器中有 8 个未能通过关卡，失败原因包括数据污染、过度拒绝、甚至有一个适配器否认一个真实存在的法院案件。只有能源领域适配器最终发布。你可能没注意到，G1 的 0胜/0负/6平结果本身就说明了一件事：能源适配器并没有比基础模型知道更多能源事实，它的优势纯粹是行为层面的——诚实校准和 JSON 可靠性。

贪心解码（Greedy Decoding）是自回归语言模型生成文本时最基础的解码策略：在每一步生成中，模型总是选择概率最高的那个 token 作为输出，而不是从概率分布中随机采样（如温度采样或 top-k 采样）。其优点是输出完全确定、可复现，同一输入多次运行结果一致，适合评测和需要稳定格式的场景；缺点是缺乏多样性，容易生成重复或保守的文本。本仓库的所有评测都采用贪心解码，配合固定随机种子，确保不同适配器之间的对比公平且可重复。此外，逐提示超时（per-prompt timeout）是为每个输入设置独立的生成时间上限，防止模型陷入无限循环或极慢推理，尤其在 CPU 这种算力受限的环境下，能保证评测装置不会因个别提示卡死而中断。

公开失败报告：8 个失败比 1 个成功更有价值

仓库中的 EVAL_REPORT.md 记录了 v1 版本的惨状：对基线 0胜/0负/6平，4/4 幻觉失败（编造国家、编造法律、编造药物并用伪造的工具调用回答），物理错误（10 kW 不等于每小时 10,000 kWh），中文 token 泄漏，伪造文件路径。

v2 数据集正是围绕这些失败模式重建的——拒绝行、反幻觉配对、校准示例（「我不知道」作为正确答案）、工具轨迹。同一天后的报告显示，同样的基础模型、同样的 LoRA rank、同样的 300 步，唯一的变量是数据组成。v2 在同样的评测装置上拿到了 9/10 领域任务、5/5 诚实度、5/5 拒绝能力、0/10 幻觉率。

这个 v1 到 v2 的对比是最有教学价值的部分。对于小型微调来说，数据集对失败模式的覆盖比数据量本身更重要。作者把 8 个失败适配器的报告也一并公开，这些失败精确地映射了哪些训练数据错误会导致小型 LoRA 出现哪种病理行为。

数据污染（Data Contamination）是评测语言模型时的一类严重陷阱，指模型的训练数据中意外包含了评测基准的题目、答案或高度相似的样本，导致模型在评测中表现虚高，并非真正具备泛化能力。在小型微调中，数据污染可能源于多种原因：训练数据抓取自公开网络时混入了评测集、人工构造的校准样本与评测提示高度重合、或不同适配器的训练数据相互泄漏。一旦发生污染，评测分数便无法反映真实能力，模型在实际部署中会迅速暴露缺陷。本仓库的 8 个失败适配器中，部分正是因为训练数据与评测提示存在重叠或模式泄漏而被判定不合格，这凸显了在微调流程中严格划分训练集与评测集、并人工审查数据来源的必要性。

技术细节：如何复现和使用

仓库结构清晰，包含 LoRA 权重文件（35MB）、完整适配器打包（34MB）、adapter_config.json、tokenizer 文件、chat_template.jinja 以及完整的模型卡和评测报告。使用方式也非常直接：

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-0.5B-Instruct")
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-0.5B-Instruct")
model = PeftModel.from_pretrained(base, "./shivacon-energy")

评测方法论也值得一提：所有关卡都在真实 CPU 推理上运行，而非 API 采样。使用贪心解码，max_new_tokens=100，Qwen 聊天模板，带有抗挂起和逐提示硬超时的评测装置。energy-eval.md 中的每个失败都经过人工裁定，转录文本已发布在仓库中，任何人都可以对评分提出异议。对于「0/10 幻觉率」这样的声明，关键词评分加人工审核每个失败案例是正确的标准，而发布转录文本才让这个声明变得可验证。

PEFT（Parameter-Efficient Fine-Tuning）是 Hugging Face 提供的一个参数高效微调库，它统一封装了 LoRA、Prefix Tuning、Prompt Tuning、IA3 等多种方法，使得用户只需加载基础模型并附加少量适配器权重即可完成定制。在代码示例中，PeftModel.from_pretrained(base, "./shivacon-energy") 的作用就是将本地保存的 LoRA 适配器权重动态注入到基础模型上，推理时适配器与基础模型共同参与计算，但基础模型权重保持不变。这种设计带来几个实际优势：适配器文件极小（本例仅 34MB 左右），便于分发和版本管理；同一个基础模型可以挂载多个不同领域的适配器，按需切换；部署时只需保留一份基础模型，显存和存储开销远低于全量微调。对于边缘设备或移动端，这种「基础模型 + 轻量适配器」的组合是目前最可行的落地路径之一。

诚实的局限与路线图

模型卡中最诚实的部分是局限性说明：

• 对基础模型没有可测量的知识提升（G1 的 0胜/0负/6平已经证明）
• 仅限能源领域，分布外问题就是分布外问题
• 0.5B 参数，不能替代工程分析或专业能源审计
• 一个已知的实际家庭节电建议乱码回答
• 严格的「仅输出 JSON」措辞偶尔会泄漏一行 Thought: 而不是纯 JSON（观察到一次，关卡提示仍得 5/5）

路线图显示 v3 正在为 8 个失败领域重新训练，能源领域下一轮数据将针对薄弱点——更多实际建议行和更深的领域覆盖，目标是让未来版本能获得知识提升，而不仅仅是校准。

为什么小模型需要的是校准，而不是知识

在智能体系统中，编排器持有知识（检索、工具、更大的模型），小模型处理的是高容量、低延迟、范围明确的回合。一个幻觉率 40% 的 0.5B 适配器在这个位置上是负债。一个幻觉率 0%、JSON 格式化 100% 正确的适配器是基础设施。

Shivacon-Energy 的评测装置——领域任务、未知诚实度、拒绝能力、JSON 格式、基础模型对比——实际上就是为这个基础设施角色设计的一场面试，能源领域是唯一通过面试的候选人。这个项目在 GitHub 上公开，作者的建议是：先读 EVAL_REPORT.md，再读 MODEL_CARD.md。对于任何正在构建智能体流水线、需要可靠小模型组件的人来说，这个仓库提供的不仅是可用的模型，更是一套可复制的失败修复配方。