1. 从“人工肉眼”到“模型打分”AI质检师到底在检什么很多人第一次听到“AI质检师”这个词脑子里浮现的画面是戴着工牌坐在流水线旁边盯着屏幕。其实这个副业跟工厂没半点关系它检的是AI系统自己产出的内容质量——大模型写的文案有没有事实错误、代码助手补全的函数有没有逻辑漏洞、客服机器人回复用户时有没有答非所问、RAG检索增强系统召回的文档片段跟问题到底相不相关。这些活儿以前靠人一条条看现在靠一套评测框架批量跑跑完还得有人判断“这个分数合不合理”“这条badcase该归到哪一类”。判断的人就是AI质检师。我接触这个方向是从去年帮一个做智能客服的朋友做badcase归因开始的。当时他们上线了一个基于大模型的问答机器人用户投诉率一直降不下来但研发团队看后台日志觉得“模型回答得挺好啊”。问题出在他们只看准确率一个指标而准确率是用一个过时的测试集算出来的跟真实线上分布完全对不上。我帮他们重新设计了一套评测流程用deepeval框架搭了自动化打分管线再配合人工抽检做校准两周之内把线上投诉率压下去将近四成。那次之后我就意识到AI质量检测这件事本身就是一个可以独立接单的技能包而且门槛没有想象中那么高。这个副业的核心工作内容可以拆成三块。第一块是评测集构建也就是从真实业务场景里采样、清洗、标注出一批有代表性的测试用例这批用例的质量直接决定了后续所有评测结论可不可信。第二块是自动化评测执行用deepeval这类框架把评测指标代码化批量跑分输出结构化的评测报告。第三块是人工复核与归因对自动打分结果做抽样校验把低分case归类到具体的问题模式里比如“事实性错误”“指令遵循失败”“格式不符合要求”“安全边界模糊”等等最终给客户一份能直接指导模型迭代的质检报告。为什么这个活儿能月入8000因为大部分中小团队养不起专职的评测工程师。一个稍微像样的AI产品团队算法工程师忙着调模型、做微调、搞部署产品经理忙着画原型、对需求没有人有精力去系统性地做评测集和badcase归因。但模型上线之后质量问题又实实在在存在不解决就会持续流失用户。这个供需缺口就是AI质检师的生存空间。你不需要会训练模型不需要懂分布式推理只需要掌握Python基础语法、理解测试理论、会用deepeval框架再加上一套严谨的归因方法论就能接单。适合什么人来做我观察下来有三类人上手最快。第一类是有测试背景的QA工程师他们本来就懂等价类划分、边界值分析这些测试理论迁移到AI评测上只是把被测对象从传统软件换成了模型输出。第二类是有Python基础的数据分析人员他们熟悉pandas处理数据、熟悉用代码做批量操作缺的只是AI评测领域的业务知识。第三类是产品经理或运营出身、但对技术有基本理解力的人他们最大的优势是知道“什么样的回答对用户来说是好回答”这在设计评测维度和做人工复核时非常关键。三类人各有短板但都能通过针对性补课在两周内达到接单水平。2. 接单之前必须想清楚的三个问题评测对象、交付物、定价逻辑在正式去接单之前有三个问题如果你没想清楚大概率会在第一个项目上翻车。这三个问题不是技术问题而是业务定位问题但它们决定了你后面所有技术工作往哪个方向使劲。2.1 你评测的到底是什么形态的AI系统AI系统的形态不同评测方法差异巨大。我按接单频率从高到低排一下。最常见的是纯文本生成类包括文案生成、摘要生成、翻译、改写、问答机器人。这类系统的评测相对成熟deepeval框架原生支持的指标基本够用比如答案相关性、忠实度、上下文精确率这些。第二常见的是RAG系统也就是检索增强生成用户提问之后先从知识库里检索相关文档再把文档和问题一起喂给大模型生成回答。这类系统的评测要拆成两段检索质量评测和生成质量评测前者看召回率和排序质量后者看回答有没有忠实于检索到的文档。第三类是Agent类系统也就是能调用工具、执行多步任务的多智能体协作框架比如clawswarm这类多智能体AI协作框架。这类系统的评测最复杂因为一次任务执行可能涉及十几个步骤中间任何一步出错都会导致最终结果失败评测维度要覆盖任务完成度、步骤合理性、工具调用准确性、异常恢复能力等等。我建议新手从纯文本生成类接起跑通三五个项目之后再往RAG和Agent方向延伸。原因很简单纯文本生成的评测指标最标准化客户预期也最明确你交付一份包含 faithfulness、answer relevancy、contextual precision 等指标的评测报告客户一看就懂。RAG和Agent的评测报告需要更多解释成本如果你自己没有足够的项目经验很难让客户信服你的结论。2.2 客户真正想要的交付物是什么很多新手以为交付物就是一份PDF报告写清楚“模型A得分0.82模型B得分0.79建议选A”。这种报告客户看一眼就扔了因为没有可操作性。客户真正想要的是三样东西。第一是可复现的评测代码包括评测集文件、评测脚本、运行环境说明客户拿到之后能自己跑一遍验证你的结论。第二是badcase分类清单把低分case按问题类型归类每一类给出典型案例和出现频率让客户的算法团队知道优先修哪类问题。第三是评测维度设计说明解释你为什么选这些指标、每个指标的阈值是怎么定的、阈值调整会对结论产生什么影响。这三样东西加起来才构成一份合格的交付物。我自己的习惯是交付一个压缩包里面包含四个目录eval_dataset/放评测集eval_scripts/放评测脚本reports/放评测报告和badcase清单docs/放评测维度设计说明和运行指南。客户拿到之后解压就能跑跑完就能看到跟我一样的结论。这种交付方式让我的复购率非常高因为客户觉得“这个人做事靠谱东西给得全”。2.3 定价怎么定才不亏定价这件事我踩过坑。最开始我按项目一口价报结果遇到一个客户中途改了三次评测需求最后一次几乎把评测维度全换了我等于做了三遍活只收了一遍钱。后来我改成基础包增量包的报价方式。基础包包含固定数量的评测用例比如200条、固定数量的评测维度比如5个、一份标准评测报告报价3000到5000元。增量包按需加购增加评测用例按条计费增加评测维度按维度计费需要人工复核按小时计费需要定制评测脚本按功能点计费。这样客户改需求的时候我会明确告诉他“这个改动属于增量范围需要补差价”避免了自己吃亏。按我自己的接单节奏一个基础包项目从沟通需求到交付大概需要5到8个工作日如果同时接两三个项目月入8000是比较稳的。如果接到RAG或Agent类项目单价可以翻倍甚至更高因为技术门槛确实更高。但我不建议新手一上来就报高价先用两三个低价项目攒案例和口碑后面再逐步提价。3. 用deepeval搭一条能跑的评测管线从安装到出报告这一节是纯实操。我会把从零搭一条评测管线的完整过程写出来包括环境配置、评测集准备、指标选择、脚本编写、报告生成。你跟着走一遍就能得到一个能跑通的评测流程。3.1 Python环境与deepeval安装的避坑细节环境配置这一步看起来简单但新手最容易在这里卡住。我见过太多人因为Python版本不对或者依赖冲突装deepeval装了整整一个下午。先说Python版本deepeval目前要求Python 3.9及以上我实测3.10和3.11最稳3.12偶尔会有依赖包不兼容的情况。如果你电脑上还没有Python去官网下载安装包的时候记得勾选“Add Python to PATH”这个选项不勾后面在命令行里调python会报“command not found”。安装deepeval本身只有一行命令pip install deepeval但这里有个坑如果你之前装过其他AI相关的包可能会有依赖版本冲突。我的习惯是给每个项目建一个独立的虚拟环境用venv或者conda都行。用venv的话操作如下python -m venv eval_env source eval_env/bin/activate # Linux/Mac eval_env\Scripts\activate # Windows pip install deepeval装完之后验证一下deepeval --version能输出版本号就说明装好了。如果报错说找不到命令大概率是虚拟环境没激活或者pip安装的路径不在系统PATH里。这种情况你可以用python -m deepeval --version来替代效果一样。还有一个细节deepeval跑评测的时候需要调用大模型来做打分所以你需要配置一个模型API的key。deepeval支持多种模型后端我常用的是OpenAI兼容接口。配置方式是在项目根目录建一个.env文件写入OPENAI_API_KEYyour_key_here OPENAI_BASE_URLyour_base_url_here然后在评测脚本开头用load_dotenv()加载。这个key的获取渠道你自己解决我不在这里展开。如果你用的是其他模型后端deepeval的文档里有对应的配置说明照着改就行。3.2 评测集怎么造从真实日志到标准化测试用例评测集是整个评测工作的地基。地基不牢后面跑出来的分数全是空中楼阁。我见过一些团队直接用公开的评测集跑分跑出来的结果跟线上表现完全对不上原因就是公开评测集的分布跟他们的真实业务场景差太远。我的做法是从真实线上日志里采样。具体步骤是这样的先从日志系统里导出最近一到两周的用户请求和模型回复通常几千到几万条不等。然后做分层抽样按照请求类型、用户群体、时间段等维度分层保证抽出来的样本能覆盖主要场景。一般抽200到500条就够了太多的话人工复核成本太高太少的话统计显著性不够。抽完之后要做清洗。清洗包括去掉重复请求、去掉包含敏感信息的请求、去掉模型回复明显被截断的请求。清洗完之后进入标注环节。标注的核心是给每条用例打上期望输出的关键特征标签而不是写一个标准答案。为什么因为大模型的输出是开放的同一个问题可以有多种正确回答方式你写一个标准答案然后做字符串匹配会把很多正确答案判成错误。正确的做法是标注“这条回答必须包含哪些关键信息”“必须不包含哪些错误信息”“格式上必须满足什么要求”然后用deepeval的指标去检验这些约束有没有被满足。我举个例子。假设评测集里有一条用例是用户问“帮我写一段Python代码读取CSV文件并计算某列的平均值”。这条用例的标注不是一段标准代码而是几个关键特征必须使用pandas或csv库、必须包含读取文件的步骤、必须包含计算平均值的步骤、代码必须能直接运行不报错。评测的时候用deepeval的代码正确性指标去检验这些特征而不是做字符串比对。评测集的文件格式我习惯用JSONL每行一个JSON对象包含input、actual_output、expected_output、context、tags这几个字段。tags字段用来标记这条用例属于哪个场景方便后续做分场景统计。3.3 指标选择不是越多越好而是要跟业务目标对齐deepeval内置了几十个评测指标新手容易犯的错是“全选”觉得指标越多报告越专业。实际上指标选多了有两个坏处一是跑评测的成本成倍增加因为每个指标都要调一次模型打分二是报告变得臃肿客户抓不住重点。我的选指标原则是跟业务目标对齐。如果客户的核心诉求是“回答不能瞎编”那我就重点用忠实度指标和幻觉检测指标。如果客户的核心诉求是“回答要切题”那我就重点用答案相关性指标。如果客户的核心诉求是“格式要规范”那我就用格式合规性指标。一般一个项目选3到5个核心指标就够了再搭配一两个辅助指标做交叉验证。对于RAG系统我会额外加检索质量指标包括上下文精确率和上下文召回率。上下文精确率衡量的是检索到的文档片段里有多少是真正跟问题相关的上下文召回率衡量的是所有相关文档片段里有多少被检索到了。这两个指标配合看能定位出问题是出在检索环节还是生成环节。对于Agent系统我会加任务完成度指标和步骤合理性指标。任务完成度看最终目标有没有达成步骤合理性看中间的工具调用和决策逻辑有没有问题。这两个指标需要自定义评测逻辑deepeval支持自定义指标你继承基类实现measure方法就行。3.4 跑评测与生成报告一条命令背后的完整流程评测脚本写完之后跑评测就是一条命令的事。但这条命令背后有几个关键配置需要你理解。第一个是并发数deepeval默认是串行跑评测速度很慢。你可以在配置里设置并发数我一般设5到10再高的话容易触发模型API的限流。第二个是重试策略模型API偶尔会超时或返回错误deepeval支持配置重试次数和重试间隔我一般设3次重试、间隔2秒。第三个是结果缓存deepeval会把已经跑过的评测结果缓存下来下次跑同样的用例时直接读缓存能省不少钱。缓存文件默认在.deepeval目录下你可以在配置里改缓存路径。跑完评测之后deepeval会输出一个结构化的结果对象包含每条用例的每个指标得分、总体平均分、分场景平均分。我一般会把这个结果对象转成DataFrame然后用pandas做进一步分析比如按tags分组统计、按分数段统计badcase分布、生成可视化图表。最后用Jinja2模板把分析结果渲染成HTML报告客户打开浏览器就能看。报告的结构我固定为四部分第一部分是评测概览包括评测集规模、评测指标、总体得分。第二部分是分维度得分每个指标一个章节展示得分分布和典型case。第三部分是badcase分析按问题类型归类每类给出典型案例和出现频率。第四部分是结论与建议明确指出模型在哪些维度表现好、哪些维度需要改进、改进的优先级排序。4. 人工复核与badcase归因自动打分之外的真功夫自动评测跑出来的分数只是起点真正体现AI质检师价值的环节是人工复核与badcase归因。这个环节做得好不好直接决定了你的报告是“一份数据”还是“一份洞察”。4.1 为什么自动打分必须配人工复核自动打分有三个固有缺陷。第一是指标本身的局限性。任何自动指标都是对“质量”这个模糊概念的近似它不可能覆盖所有质量维度。比如“回答的语气是否得体”这种维度自动指标很难准确衡量。第二是模型打分的偏差。deepeval用大模型来做打分裁判而大模型本身是有偏好的它可能对某些表达风格更宽容对某些表达风格更苛刻。第三是阈值设定的主观性。什么分数算“合格”、什么分数算“不合格”这个阈值是人定的不同项目、不同场景下阈值应该不同。人工复核的作用就是校准自动打分的偏差。我的做法是从自动打分结果里分层抽样高分、中分、低分各抽一批人工逐条看判断自动打分跟人工判断的一致性。如果一致性低于80%说明自动指标或阈值需要调整。调整完之后再跑一轮直到一致性达标。这个过程一般需要一到两天但非常值得因为它保证了后续所有结论的可信度。4.2 badcase归因的完整排查链路badcase归因是AI质检师的核心技能。我把我自己的归因流程拆成五步你可以直接照着用。第一步是现象描述。把badcase的具体表现写清楚比如“用户问退款流程模型回答成了换货流程”。描述要具体到能让人一眼看懂问题是什么。第二步是问题定位。判断这个问题出在哪个环节。如果是RAG系统先看检索到的文档片段里有没有正确的退款流程文档。如果没有问题出在检索环节如果有但模型没用问题出在生成环节。如果是Agent系统看任务执行轨迹里哪一步开始偏离预期。第三步是根因分析。定位到环节之后进一步分析根本原因。检索环节的问题可能是embedding模型对“退款”和“换货”的语义区分度不够也可能是知识库里退款文档的切分粒度不合理。生成环节的问题可能是prompt里没有强调“必须严格依据检索到的文档回答”也可能是模型本身对这类问题的指令遵循能力不足。第四步是影响评估。评估这个问题的影响范围。是偶发case还是高频问题影响的是所有用户还是特定用户群体严重程度是高还是低影响评估的结果决定了修复的优先级。第五步是修复建议。给出具体的、可操作的修复建议。比如“在prompt里增加一条约束如果检索到的文档不包含用户问题的直接答案必须回复‘根据现有资料无法回答’不得自行推断”。修复建议要具体到能让算法工程师直接动手改的程度。这五步走下来一条badcase就被彻底解剖了。我把所有badcase的归因结果汇总成一张表按问题类型和影响程度排序客户拿到之后一目了然。4.3 把归因结果翻译成客户能听懂的话归因结果如果直接用技术语言写客户的产品经理和业务方看不懂。我一般会做一层“翻译”把技术问题映射到业务影响上。比如“检索环节的embedding模型对近义业务术语区分度不足”翻译成“用户问退款时系统有时会错误地推荐换货政策可能导致用户操作失误”。“生成环节的prompt缺少事实性约束”翻译成“模型有时会编造不存在的政策条款可能引发用户投诉”。这种翻译看起来简单但需要你对客户的业务有足够理解。我接项目的时候会花至少半天时间跟客户的产品经理聊了解他们的用户是谁、核心业务流程是什么、哪些错误是致命的、哪些错误可以容忍。这些信息直接影响我归因时的优先级判断和修复建议的措辞。5. 接单渠道与实战心得从第一单到稳定复购技术能力到位之后接单渠道和客户沟通就是决定收入的关键了。这一节我分享一些自己踩过坑之后总结出来的经验。5.1 去哪里找第一批客户我试过几个渠道按效果排序说一下。最有效的是技术社区的输出。我在几个开发者社区持续发AI评测相关的技术文章文章末尾留一个联系方式陆陆续续有客户主动找过来。这种渠道来的客户质量最高因为他们看了你的文章对你的专业能力有基本信任沟通成本低。第二种是同行推荐。我认识几个做AI产品开发的独立开发者他们自己不接评测的活但客户有时候会问他们“能不能帮忙做评测”他们就把我推荐过去。这种渠道来的客户成交率很高因为中间有信任背书。第三种是外包平台。这类平台上AI评测的需求不少但竞争也激烈而且平台抽成高。我早期在上面接过两单后来就不太用了因为客户质量参差不齐沟通成本太高。我的建议是前期花一个月时间在技术社区持续输出不用写太长每篇一两千字讲清楚一个具体的评测问题怎么解决就行。坚持输出一个月大概率能接到第一单。5.2 第一次跟客户沟通必须问清楚的五件事第一次沟通如果没问清楚后面大概率要返工。我整理了一个必问清单。第一评测对象是什么是纯文本生成、RAG还是Agent第二核心业务目标是什么客户最在意的是准确性、相关性、格式合规还是安全边界第三有没有现成的评测集如果没有评测集构建是否包含在项目范围内第四交付物具体包含什么只要报告还是要代码和评测集第五时间节点和预算范围什么时候要交付预算大概多少这五个问题问完你基本能判断这个项目能不能接、报价多少合适、需要投入多少时间。如果客户对某些问题也说不清楚那你要帮他理清楚这本身就是你专业价值的体现。5.3 几个让我少走弯路的实操心得第一个心得永远先跑一个小规模试点。不要一上来就跑全量评测集先用20条用例跑一遍验证评测脚本没问题、指标选择合理、报告格式客户满意然后再跑全量。这样能避免跑了几千条之后发现方向错了要重跑。第二个心得评测报告里一定要有“局限性说明”。明确告诉客户这次评测覆盖了什么、没覆盖什么、结论在什么条件下成立。比如“本次评测基于200条抽样用例覆盖了退款、换货、物流查询三个场景未覆盖投诉和售后场景结论仅在这三个场景下有效”。这种说明看起来是在给自己设限实际上是在建立专业信任客户会觉得你严谨。第三个心得保留所有中间产物。评测集、评测脚本、原始打分结果、人工复核记录、归因分析表全部保留。一方面是为了交付另一方面是后续客户如果问“为什么这条case得分这么低”你能快速翻出当时的记录来解释。第四个心得报价的时候把“沟通成本”算进去。AI评测项目跟客户沟通的时间往往比写代码的时间还长因为客户对评测指标不熟悉需要反复解释。我现在的报价里会明确包含“两次需求沟通会议”和“一次交付讲解会议”超出部分按小时计费。这样既保护了自己也让客户有预期。5.4 从单次项目到长期合作怎么让客户持续找你单次项目的收入是有限的真正稳定的收入来自长期合作。我现在的客户里有三个是长期合作每个月固定给我一批评测需求收入稳定在8000以上。怎么把单次客户转化成长期客户我的经验是在交付物之外多给一点。比如交付报告的时候额外附一份“下阶段评测建议”告诉客户下一轮评测可以关注哪些维度、评测集可以怎么扩充、模型迭代后怎么对比评测结果。这份建议不额外收费但客户会觉得你是在帮他长期解决问题而不是做完一单就走。另外我会在每次交付后一周主动回访问客户“报告里的建议有没有落地”“模型迭代后效果有没有改善”。这种回访不推销就是单纯关心项目进展。但往往回访的时候客户会说“正好我们下个月要上新版本你再帮我们评一次”。长期合作就是这么来的。6. 评测之外AI质检师这个角色的长期价值做了一段时间之后我慢慢意识到AI质检师这个角色不只是“跑评测出报告”它实际上处在模型能力与业务需求之间的翻译层。算法团队关心的是loss降了多少、benchmark涨了多少业务团队关心的是用户投诉有没有减少、转化率有没有提升。这两套语言之间需要一个翻译而AI质检师就是做这个翻译的人。你跑出来的评测数据如果只是“faithfulness 0.82”算法团队看了没感觉业务团队看了看不懂。但如果你说“模型在退款场景下的回答有18%的概率包含不存在的政策条款这些条款如果被用户当真可能导致客诉”两边就都听懂了。这种翻译能力是AI质检师最核心的竞争力也是为什么这个角色不容易被自动化替代的原因。从技能成长路径来看我建议新手按这个顺序进阶先掌握纯文本生成的评测把deepeval的常用指标跑熟然后学RAG评测理解检索质量和生成质量的拆解方法再往后学Agent评测掌握多步任务执行轨迹的分析方法最后学评测体系设计能根据业务目标从零设计一套完整的评测方案。走到最后一步你就不只是接单做评测了你可以帮客户搭建内部的评测体系这种项目的单价和长期价值都远高于单次评测。我自己现在的时间分配大概是40%做评测项目交付30%做评测体系咨询20%写技术文章和社区输出10%学新东西。这个分配让我的收入比较稳定同时保持了技术敏感度。如果你也想做这个方向我的建议是不要只盯着“接单”这一个收入来源把技术输出和体系咨询也做起来长期来看回报更高。最后分享一个我最近在用的技巧每次做完一个项目我会把项目里遇到的典型badcase和归因过程脱敏之后整理成一个案例库。这个案例库现在有几十个案例下次遇到类似问题时可以直接参考大大提高了归因效率。而且这个案例库本身也成了我接单时的“作品集”客户看到我处理过这么多类型的badcase对我的信任度会明显提升。这个习惯我从第三个项目开始坚持到现在觉得是投入产出比最高的一件事。