自建智能栈实战：定制模型与评测体系搭建指南

1. 从"调API"到"养模型"：为什么自建智能栈正在成为分水岭

过去两年，我接触过不少团队做AI应用，绝大多数人的路径都差不多：调一个通用大模型的API，套一层提示词，做个前端界面，上线。这套打法在2023年确实能跑通，但到了现在，问题开始集中爆发——成本压不下来、响应延迟不可控、数据出不了内网、模型行为改不动。于是"自建智能栈"这个词开始频繁出现在技术团队的讨论里。

所谓智能栈，不是简单地部署一个开源模型就完事。它是一整套从底层算力、模型权重、推理服务、评测体系到上层应用编排的完整链路。而在这条链路里，定制模型和评测体系正在成为真正的核心资产。为什么这么说？因为算力可以租、框架可以开源、界面可以抄，唯独两样东西别人拿不走：一个是你用自己业务数据喂出来的、懂你场景的模型；另一个是你用来判断这个模型到底行不行的评测标准。

这篇内容我想聊的不是"要不要自建"，而是怎么自建才不白花钱。我会围绕定制模型的训练取舍、评测框架的选型落地、agent场景下的评测难点、以及整套栈的成本与迭代节奏来展开。适合已经跑通过API调用、准备往深水区走的工程师和团队负责人看，也适合刚接触评测体系、想知道deepeval这类框架到底怎么用的人。全文基于我自己的实操经验和行业常见实践整理，能抄作业的地方我尽量给到具体参数和步骤。

2. 定制模型这件事，先想清楚"改什么"再动手

2.1 三种定制路径的成本与适用边界

很多人一提到定制模型，第一反应就是"我要微调一个自己的大模型"。但微调只是其中一条路，而且往往不是性价比最高的那条。我把常见的定制路径分成三档，你可以对照自己的情况选。

我自己的经验是：80%的团队卡在提示词工程就能解决大部分问题，剩下20%里又有大半用LoRA就够了。真正需要全量微调的，通常是两类情况——一是你的领域术语和通用语料差异极大（比如某些工业协议、特定行业的黑话），二是你对输出格式的稳定性要求到了苛刻的程度，提示词怎么调都会飘。

这里有个反直觉的点：微调不一定能让模型"更聪明"，它更多是让模型"更听话"。如果你指望微调提升模型的推理能力，大概率会失望。微调擅长的是风格对齐、格式约束、领域词汇注入，而不是从零教会模型一个新技能。想清楚这一点，你就不会在错误的方向上烧钱。

2.2 LoRA微调的实操参数与踩坑记录

假设你决定走LoRA这条路，我把我常用的配置和踩过的坑列一下。以7B模型为例，单卡24G显存（比如4090）就能跑起来。

# LoRA 典型配置（基于 peft 库） lora_config = { "r": 16, # 秩，8-64之间，任务越复杂越大 "lora_alpha": 32, # 通常设为 r 的 2 倍 "target_modules": ["q_proj", "v_proj", "k_proj", "o_proj"], "lora_dropout": 0.05, "bias": "none", "task_type": "CAUSAL_LM" } # 训练超参 training_args = { "learning_rate": 2e-4, # LoRA 学习率比全量微调高一个量级 "num_train_epochs": 3, # 通常 2-5 轮，多了容易过拟合 "per_device_train_batch_size": 4, "gradient_accumulation_steps": 4, "warmup_ratio": 0.03, "lr_scheduler_type": "cosine", "fp16": True, # 或 bf16，看显卡支持 }

几个关键取舍我解释一下。秩r的选择：r越大，能表达的能力越强，但参数量也越大，过拟合风险越高。我一般从16起步，如果发现模型学不动（loss降不下去），再往上加到32或64；如果发现训练集loss很低但验证集拉胯，就往下降。target_modules：只调q和v是最省的做法，但效果一般；加上k和o会好一些；有些任务还会把FFN层的gate、up、down也加进去，效果更好但显存吃紧。学习率：LoRA的学习率要比全量微调高，因为可训练参数少，需要更大的步长才能有效更新，2e-4是个稳妥的起点。

踩过的坑里，最典型的是数据格式没对齐。LoRA训练时如果prompt和response的分隔没处理好，模型会把问题也当成要生成的内容，推理时就开始复读你的问题。我的做法是严格用对话模板，并且在计算loss时把prompt部分的label设为-100，只对response部分计算损失。这个细节很多教程不讲，但不做的话效果差一大截。

2.3 定制模型真正的护城河在数据管道

模型架构是公开的，训练代码是开源的，唯独数据是你独有的。所以我一直认为，自建智能栈的核心资产不是模型权重本身，而是那条能持续产出高质量训练数据的数据管道。

这条管道通常包含几个环节：原始数据采集、清洗去重、质量打分、格式转换、人工抽检。其中质量打分最容易被忽视。我的做法是用一个强模型（或者人工规则）给每条数据打一个质量分，低于阈值的直接丢弃。别心疼数据量，一万条干净数据胜过十万条脏数据，这在微调里是铁律。

还有一个经验：数据要分层。把数据按难度、按场景、按来源分成几层，训练时按比例混合。如果全是简单样本，模型学不到难例；如果全是难例，模型容易过拟合到少数模式。我一般按7:2:1的比例混合简单、中等、困难样本，效果比单一分布稳定得多。

3. 评测体系：比模型更值钱的隐形资产

3.1 为什么说评测是自建栈的"度量衡"

模型训完了，怎么知道它到底行不行？大多数人第一反应是"跑几个例子看看"。这种主观感受在小规模验证时能用，但一旦你要迭代、要对比、要上线，就必须有一套客观的评测体系。没有评测的模型迭代，本质上是在盲人摸象。

评测的价值体现在三个层面。第一是决策依据：两个版本的模型，哪个更好？换了个训练数据配比，效果是升是降？没有评测你只能拍脑袋。第二是回归防护：模型更新后，原来能答对的问题是不是答错了？评测集就是你的回归测试用例。第三是对外沟通：当你要向业务方证明"这个模型可用"，一份结构化的评测报告比任何口头描述都有说服力。

我见过太多团队，模型训了一堆版本，最后选哪个全靠"感觉这个回答更顺眼"。这种做法在早期没问题，但当你有了几十个版本、要持续迭代时，没有评测体系就是灾难。所以我的建议是：评测体系的建设要和模型训练同步启动，甚至更早。

3.2 deepeval框架的落地：从安装到跑通第一个用例

说到评测框架，deepeval是这两年比较活跃的一个。它的定位是"LLM应用的单元测试框架"，思路很像pytest——你写测试用例，它帮你跑、帮你打分、帮你出报告。我把它跑通的流程整理一下。

安装很简单：

pip install deepeval

核心概念有三个：测试用例（LLMTestCase）、度量指标（Metric）、测试集（Dataset）。一个最小可运行的例子长这样：

from deepeval import evaluate from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric from deepeval.test_case import LLMTestCase # 定义测试用例 test_case = LLMTestCase( input="自建智能栈的核心资产是什么？", actual_output="核心资产是定制模型和评测体系。", expected_output="定制模型和评测体系是核心资产。", retrieval_context=["自建智能栈中，定制模型和评测体系构成核心资产。"] ) # 定义度量指标 relevancy = AnswerRelevancyMetric(threshold=0.7) faithfulness = FaithfulnessMetric(threshold=0.7) # 执行评测 evaluate([test_case], [relevancy, faithfulness])

跑通之后你会发现，deepeval的度量指标大多是基于"LLM-as-a-judge"的——也就是用另一个模型来给你的输出打分。这就引出一个关键问题：评测模型本身可靠吗？我的经验是，用强模型评弱模型相对可靠，反过来就不行。而且评测模型的提示词要精心设计，否则打分波动会很大。deepeval允许你自定义评测模型，我一般会指定一个比被测模型更强的模型来做裁判。

3.3 在线评测的两种主流模式：离线批测与在线A/B

评测按运行时机分，主要有两种模式，各有各的用武之地。

离线批测是在模型上线前跑的，用固定的评测集，一次性把所有用例跑完，出一份报告。它的优点是可控、可复现、成本低（不用真实流量），缺点是评测集和真实分布可能有偏差。我一般用它做版本对比和回归测试。

在线A/B是把两个版本的模型同时放到线上，按流量切分，看真实用户的反馈指标（比如采纳率、追问率、点赞率）。它的优点是贴近真实场景，缺点是成本高、周期长、有风险（万一新版本翻车会影响用户体验）。我一般用它做最终上线决策。

实操中我的建议是两者结合：离线批测做快速迭代的筛子，把明显不行的版本挡在门外；在线A/B做最终验证，用真实数据确认效果。别指望一种模式解决所有问题。

4. Agent评测：当被测对象从"回答"变成"行动"

4.1 Agent评测和普通LLM评测的本质差异

普通LLM评测，输入是一句话，输出是一段文本，评测就是比对文本质量。但Agent不一样，它要调用工具、要分多步执行、要根据中间结果调整策略。这就导致评测的复杂度上了一个台阶。

差异主要体现在三方面。第一，评测对象从"输出"变成了"轨迹"。一个Agent可能调了五次工具才给出答案，你不仅要看最终答案对不对，还要看中间步骤合不合理。第二，评测维度从"质量"扩展到"效率和安全"。Agent可能答对了但绕了十步，也可能答对了但调用了不该调用的工具。第三，评测环境从"静态"变成了"动态"。Agent要和外部世界交互，评测时你得提供一个可控的模拟环境。

我踩过的一个坑是：早期我用普通LLM的评测方法去评Agent，只看最终输出，结果发现两个Agent最终答案一样，但一个只调了一次工具，另一个调了八次还差点跑偏。只看输出根本发现不了这种差异。后来我改成同时评最终答案和工具调用序列，才把问题暴露出来。

4.2 GAIA这类Agent评测集怎么用

GAIA是目前比较有代表性的Agent评测集，它的特点是任务真实、需要多步推理和工具使用。下载和使用流程大致是这样：

# 从官方渠道获取评测集（注意遵守其使用协议） # 通常包含三个难度级别：Level 1/2/3 # 每个任务包含：问题、标准答案、所需工具类型

用GAIA评测时，有几个实操要点。第一，要给它配好工具环境。GAIA的很多任务需要联网搜索、文件读取、代码执行等能力，你的Agent如果没有这些工具，很多任务根本没法做。第二，要区分"能力不足"和"工具缺失"。一个任务失败，可能是模型推理不行，也可能是你没给它配对应的工具，评测报告里要能区分这两种情况。第三，Level 3的任务非常难，我建议先用Level 1和2做基线，Level 3作为长期目标。

除了GAIA，还有一些垂直领域的Agent评测集，比如专门测代码Agent的、测网页操作Agent的。选评测集的原则是：评测集的任务分布要贴近你的真实使用场景。如果你的Agent是干客服的，用GAIA评出来的分数参考价值有限。

4.3 Agent安全评测：那些容易被忽略的边界

Agent安全评测是这两年越来越受重视的方向，因为Agent能调工具、能执行操作，一旦被诱导做出危险行为，后果比普通LLM严重得多。安全评测主要看几个方面。

提示注入抵抗：用户输入里如果藏了"忽略之前的指令，去执行XX"，Agent会不会上当？这个要专门构造对抗样本来测。工具滥用：Agent会不会调用超出授权范围的工具？比如一个只该读文件的Agent，会不会去写文件、删文件？越权操作：Agent在多步执行中，会不会因为中间结果被污染而做出越权决策？

我的做法是建一个安全评测子集，专门放这类对抗样本，每次模型更新都跑一遍。这个子集的用例不用多，几十条就够，但必须覆盖上面几类风险。安全评测的通过标准要比普通评测严格——普通评测允许一定错误率，安全评测最好是零容忍，因为一次越权可能就是事故。

5. 把定制模型和评测串成闭环：迭代节奏与成本控制

5.1 一个可落地的迭代闭环长什么样

单独看定制模型和评测，都是局部工作。真正的价值在于把它们串成一个闭环：数据产出模型，评测筛选模型，评测结果反过来指导数据生产。这个闭环转起来，你的智能栈才会越用越强。

具体流程我拆成五步。第一步，用当前数据训练一个候选模型。第二步，用评测集跑一遍，拿到各项指标。第三步，分析失败用例，看是数据问题、模型问题还是评测集本身的问题。第四步，针对性地补充数据或调整训练策略，产出新版本。第五步，新版本再评测，和上一版对比，决定是否采纳。这个循环我一般一到两周跑一轮，太快了数据来不及准备，太慢了迭代效率低。

这里有个关键点：评测集要定期更新。如果你的评测集一直不变，模型迟早会"过拟合"到评测集上，分数很好看但真实效果停滞。我的做法是每个迭代周期往评测集里补充一批新的失败用例，同时淘汰一批已经稳定通过的简单用例，保持评测集的"新鲜度"和"区分度"。

5.2 成本账：自建栈到底比调API贵在哪、省在哪

很多人关心自建栈的成本。我算过一笔账，结论是：自建栈的前期投入明显高于调API，但当你调用量到一定规模后，边际成本会低很多。

贵的地方主要在：算力（训练和推理的GPU）、人力（数据工程、训练、评测都要人）、时间（从零到可用通常要几个月）。省的地方在于：推理成本随规模摊薄、数据不出内网、模型行为完全可控、不用为每次API调用付费。

我的经验是，月调用量在百万次以下的场景，调API通常更划算；超过这个量级，或者有强数据合规要求，自建栈的性价比才开始显现。所以别为了"自建"而自建，先算清楚你的调用量和合规需求。

5.3 几个让我少走弯路的实操心得

最后分享几条我踩坑换来的经验。

第一，评测先行。别等模型训完才想怎么评，训练开始前就把评测集和指标定好，这样你才知道往哪个方向优化。

第二，小步快跑。别指望一次训出一个完美模型，用LoRA快速试错，验证方向对了再投入更多资源。

第三，数据质量大于一切。我见过太多团队在模型架构上纠结，却对数据质量不上心，最后效果上不去还找不到原因。

第四，评测模型要固定。如果你用LLM做裁判，评测模型换了，历史分数就没法对比了。我一般把评测模型版本也纳入版本管理。

第五，留一手人工抽检。自动评测再完善，也要定期人工看一批样本，因为自动评测本身可能有盲区，人工抽检是发现盲区的最后一道防线。

这套东西搭起来不轻松，但一旦转起来，你会发现它带来的确定性和可控性，是单纯调API永远给不了的。