1. 法律大模型选型的真实困境：为什么“法律”标签不等于法律能力

做法律 AI 选型的朋友大概率都遇到过这个场景：老板丢过来一份需求，说要给法务部门搭一个智能问答和条文检索的助手，预算有限，只能选一个模型。市面上有两类候选，一类是通用大模型的最新版本，比如 Qwen3 系列，另一类是打着“法律垂直”旗号的领域模型，比如基于 Qwen2.5 微调的 LawLLM-7B。直觉上，法律场景当然选法律模型，但真把同一批法条背诵、案例分析、罪名预测的题目丢进去跑一遍，结论往往会让人愣住——通用模型在不少任务上反超了垂直模型，而且差距不小。

这就是标题里说的“关键不在法律，而在大模型”的含义。垂直模型的价值来自基座能力加领域微调，一旦基座落后一代，微调带来的那点领域优势很容易被新基座的通用推理能力抹平。所以选型不能看名字，得看同一批任务上的实测分数。这篇内容就是把这个实测过程完整拆开：用 TaoToken 的统一 API 通道，把 Qwen3 不同尺寸和 LawLLM-7B 放在同一套请求配置、同一套评测脚本下跑，交付可复制的配置、脚本和校验步骤，你可以照着复现，也可以换成自己业务里的题目集。

适合谁看：正在做法律问答、条文检索、合同审查类产品的算法同学；需要给团队出模型选型报告的工程师；以及想搞清楚“垂直微调到底还值不值”的技术负责人。全文不涉及任何具体法律意见，只谈模型调用与评测工程。

先说清楚评测的基本盘。法律领域的公开评测集里，LawBench 是比较成体系的一个，覆盖 20 类任务、三个认知层次：法律知识记忆（法条背诵、知识问答）、法律知识理解（命名实体识别、争议焦点识别、事件检测）、法律知识应用（法条预测、罪名预测、刑期预测、案例分析、损害赔偿计算）。每类任务约 500 题，题型包括生成、单选、多选、抽取、回归。评分方式有两种，基于规则的自动判分和 LLM-as-Judge 判分，本文统一用基于规则的判分，好处是确定性高、可复现，坏处是对生成类任务的容错较严，后面排障章节会专门讲这个坑。

参评模型我选了五个：Qwen3-0.6B、1.7B、4B、8B 四个通用模型，加上 LawLLM-7B 一个垂直模型。选这个组合的目的是看两件事：一是规模效应在通用模型内部怎么走，二是 8B 这个量级的通用模型能不能打过 7B 的垂直模型。采样参数统一为 top_k=20、temperature=0.6、top_p=0.95、do_sample=True，Qwen3 系列额外区分思考模式（think）和非思考模式（no_think），因为实测下来这个开关对法律任务的影响比想象中大得多。

2. TaoToken 统一 API 通道前置准备：一个 Key 跑通多模型对比

做多模型对比最烦的事情不是写评测脚本，而是每换一个模型就要换一套 SDK、换一个 Key、换一套鉴权方式。Qwen3 走一套接口，LawLLM 如果自己部署又是另一套，对比实验还没开始，环境配置就耗掉半天。TaoToken 在这里的作用就是把这件事收敛：它提供统一的 API 入口，兼容 OpenAI 风格的请求格式，你只需要一个 Key、一个 Base URL，改请求体里的 model 字段就能切换模型，评测脚本里不用维护多套客户端。

前置准备分三步，都很轻。

第一步，注册并拿到 API Key。打开官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，完成账号注册后进入控制台，在 API Keys 页面创建一个新 Key。建议给评测单独建一个 Key，命名成 eval-lawbench 之类，方便后面看用量和排查问题。Key 只在创建时完整显示一次，复制下来存到环境变量里，别硬编码进脚本。

第二步，确认你要用的模型 ID。这一步很关键，因为不同通道对模型名的写法要求不一样。进入模型对话页面或者文档页，查一下 Qwen3 系列和 LawLLM 对应的准确 model 标识。常见写法类似 qwen3-8b、qwen3-8b-thinking 这种带模式后缀的形式，具体以文档页列出的为准。LawLLM 如果通道里没有现成的托管版本，你需要确认是否支持自定义模型接入，或者先用 Qwen3 系列把评测框架跑通，再替换模型端点。

第三步，把 Key 和 Base URL 写进环境变量。Linux/macOS 下这样操作：

export TAOTOKEN_API_KEY="sk-你的key" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

Windows PowerShell 用：

$env:TAOTOKEN_API_KEY="sk-你的key" $env:TAOTOKEN_BASE_URL="https://taotoken.net/api"

注意 Base URL 不要带多余的路径后缀，OpenAI 兼容客户端通常会自动拼接 /v1/chat/completions，具体以文档页的接入说明为准。如果你用的是 requests 直接发请求，就按文档给的完整路径写。

这里有个容易忽略的点：评测脚本要跑几百上千次请求，务必在控制台看一下当前 Key 的速率限制和并发上限。LawBench 单任务 500 题，五个模型乘以多个任务，请求量不小。建议先拿 10 条数据做冒烟测试，确认通道稳定、计费正常，再放开全量跑。另外把每次请求的 response 原始 JSON 落盘保存，后面算分和排障都要靠它，别只存解析后的文本。

3. 可复制的请求配置与评测脚本：从单条调用到批量跑分

这一节是全文的技术核心，目标是你复制粘贴改改路径就能跑。先给单条请求的配置，再给批量评测脚本，最后给结果落盘和算分的结构。

先看单条请求的 JSON 结构。用 curl 测试通道是否通：

curl -s "$TAOTOKEN_BASE_URL/v1/chat/completions" \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3-8b", "messages": [ {"role": "user", "content": "回答以下问题，只需直接给出法条内容：民法商法个人独资企业法第十九条的内容是什么？"} ], "temperature": 0.6, "top_p": 0.95, "top_k": 20, "stream": false }'

如果你用 Python，建议把配置抽成一个 settings 片段，方便切换模型。下面是一个 config 结构，路径按你自己的项目改：

{ "base_url": "https://taotoken.net/api", "api_key_env": "TAOTOKEN_API_KEY", "default_params": { "temperature": 0.6, "top_p": 0.95, "top_k": 20, "do_sample": true, "max_tokens": 1024 }, "models": { "qwen3-8b-think": {"model_id": "qwen3-8b", "enable_thinking": true}, "qwen3-8b-no_think": {"model_id": "qwen3-8b", "enable_thinking": false}, "lawllm-7b": {"model_id": "lawllm-7b", "enable_thinking": false} } }

注意 enable_thinking 这个字段不是所有通道都认，Qwen3 的思考模式开关在不同部署下写法有差异，有的用请求体参数，有的用模型名后缀区分。以文档页说明为准，如果通道不支持该参数，就通过模型名后缀选择对应版本，别两个都写导致请求报错。

批量评测脚本的核心逻辑是：读数据集 JSONL，逐条构造 prompt，调 API，把原始响应和解析结果一起写回 JSONL。下面给一个精简但可运行的版本：

import json, os, time, requests BASE = os.environ["TAOTOKEN_BASE_URL"] KEY = os.environ["TAOTOKEN_API_KEY"] HEADERS = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"} def call_model(model_id, prompt, enable_thinking=False, retries=3): payload = { "model": model_id, "messages": [{"role": "user", "content": prompt}], "temperature": 0.6, "top_p": 0.95, "top_k": 20, "max_tokens": 1024, "stream": False, } if enable_thinking: payload["enable_thinking"] = True for i in range(retries): try: r = requests.post(f"{BASE}/v1/chat/completions", headers=HEADERS, json=payload, timeout=120) if r.status_code == 200: return r.json() print(f"HTTP {r.status_code}: {r.text[:200]}") except Exception as e: print(f"retry {i}: {e}") time.sleep(2 ** i) return None def run_eval(dataset_path, out_path, model_id, enable_thinking=False): with open(dataset_path, encoding="utf-8") as f, \ open(out_path, "w", encoding="utf-8") as out: for line in f: item = json.loads(line) resp = call_model(model_id, item["prompt"], enable_thinking) record = { "id": item.get("id"), "task": item.get("task"), "prompt": item["prompt"], "gold": item.get("gold"), "raw_response": resp, "prediction": None, } if resp and "choices" in resp: record["prediction"] = resp["choices"][0]["message"]["content"] out.write(json.dumps(record, ensure_ascii=False) + "\n") out.flush()

这个脚本有三个设计点值得说。第一，原始响应整包落盘，不丢字段，后面如果发现解析逻辑有问题，可以离线重算，不用重新花钱跑。第二，重试带指数退避，法律任务单条响应可能较长，超时和限流都会遇到，别一次失败就丢数据。第三，逐条 flush，长任务跑到一半中断也不至于全丢。

算分部分，基于规则的判分对抽取类、选择题类任务比较好写，比如罪名预测就是字符串匹配加同义词表，法条背诵用关键词覆盖率。生成类任务比如案例分析，规则判分容易偏低，这也是后面结果里要重点解释的地方。建议先写一个 score.py，把 prediction 和 gold 做规范化（去空格、统一标点、繁简转换）再比对，别直接字符串相等。

4. 验证请求与成功结果：从单条响应到分数矩阵

配置写完，先别急着全量跑。第一步验证是单条请求能不能通。用第 3 节的 curl 发一条法条背诵题，正常返回应该是一个 JSON，choices[0].message.content 里是模型给出的法条内容。如果返回 200 但 content 为空，先看 finish_reason 是不是 length，max_tokens 给小了会被截断。

第二步验证是思考模式开关是否生效。对同一个 prompt，分别用 qwen3-8b 的 think 和 no_think 版本各发一次，观察返回内容里是否带思考过程标记。实测下来，思考模式在法条背诵这种记忆型任务上经常“想多了”，输出一大段推理再给答案，规则判分时反而因为格式不匹配丢分；而在刑事损害赔偿计算这种多步数值推理上，思考模式能明显提分。这个分化是后面结果分析的主线。

第三步验证是小批量跑通。从 LawBench 里抽 20 条，覆盖法条背诵、罪名预测、案例分析三类，跑完检查 JSONL 里 prediction 字段的填充率。填充率低于 95% 就说明有系统性问题，先排障再放量。

全量跑完之后，你会得到一张分数矩阵。以我这边跑下来的量级为例，几个关键观察点是这样的。规模效应在通用模型内部非常明显：基于事实的法条预测任务，从 0.6B 到 8B 提升超过 380%，罪名预测提升约 95%，知识问答提升约 75%，刑事损害赔偿计算提升约 53%。这说明事实到法条的映射、罪名特征学习这类能力，跟参数量强相关，小模型再怎么调 prompt 也补不上。

但规模效应也有饱和区。事件检测从 4B 到 8B 只提升 0.1%，阅读理解提升约 5.5%，基于场景的法条预测几乎停滞。这意味着如果你的业务集中在这些任务上，上 8B 的边际收益很低，4B 可能就够用，成本能省一大截。

最值得关注的是通用 8B 和垂直 7B 的对比。Qwen3-8B 在刑事损害赔偿计算上拿到 94.0，LawLLM-7B 是 57.2，差距 64%；争议焦点识别上 8B 非思考模式 43.4 对 27.2，差距 60%；命名实体识别 85.2 对 63.1，差距 35%；刑期预测上非思考模式也全面领先。反过来，LawLLM-7B 在案例分析上 74.8 对 37.8，领先近一倍；知识问答 79.0 对 50.8，领先 56%；事件检测 89.8 对 73.3，领先 23%；法条背诵 26.2 对 19.3，领先 36%。

这组数字说明什么？垂直模型的护城河集中在“法律知识密度”和“法律文书生成”这类需要领域语料浸润的任务上，而通用模型凭借更强的基座推理和抽取能力，在数值计算、实体识别、快速判断上反超。换句话说，垂直模型不是全面更强，而是偏科；通用模型也不是全面更弱，而是领域知识密度不够。选型时要按任务拆开看，不能一刀切。

思考模式的双刃剑效应也很清楚。增益明显的任务：刑事损害赔偿计算 +25.2，触发词提取 +12.7，基于事实的法条预测 +4.5，事件检测 +4.4。受损明显的任务：案例分析 -16.4，论点挖掘 -16.0，命名实体识别 -14.9，知识问答 -14.4，争议焦点识别 -9.6，刑期预测 -7.5 到 -5.7。规律是：需要多步推理和数值计算的，开思考；需要快速匹配、精准抽取、直接给答案的，关思考。这个结论可以直接落成配置策略。

5. 本篇常见错排查：401、local proxy failed、reading choices 与 OAuth 报错

评测跑不起来，八成是下面几类错误。逐个给现象、原因和修法。

401 Unauthorized。现象是请求返回 401，body 里提示 invalid api key 或 missing authorization。原因通常是环境变量没生效、Key 复制时带了空格、或者 Key 被删了。排查顺序：先 echo $TAOTOKEN_API_KEY 看变量是否存在且长度正常；再检查请求头是不是 Bearer 加空格加 Key，少个空格也会 401；最后去控制台确认这个 Key 状态是启用。注意别把 Key 写进代码提交到仓库，用环境变量或本地 .env 文件，.env 记得进 .gitignore。

local proxy failed 或 connection refused。现象是请求发不出去，报连接失败。这类错误多半是本机网络配置或客户端代理设置导致的。检查你的 HTTP_PROXY、HTTPS_PROXY 环境变量是否指向了一个不可用的地址，评测脚本里显式把 proxies 设为空或者按文档要求配置。另外确认 Base URL 拼写正确，多一个斜杠少一个 /v1 都会导致 404 或连接异常。用 curl -v 看实际请求的完整 URL，比猜快得多。

reading choices 报错，典型信息是 KeyError: 'choices' 或 TypeError: 'NoneType' object is not subscriptable。现象是脚本在解析响应时崩了。原因有两个：一是请求失败返回了错误 JSON，里面没有 choices 字段，你的代码却直接取 resp["choices"]；二是模型返回了空内容但结构正常。修法是解析前先判断 "choices" in resp and resp["choices"]，失败时把原始响应打到日志里。第 3 节脚本里 record["raw_response"] 整包落盘就是为了这个，出问题直接翻原始 JSON，别靠回忆。

OAuth 相关报错，比如 invalid_grant 或 token expired。如果你用的是带 OAuth 流程的客户端工具接入，token 过期是常见原因，重新走一遍授权拿新 token 即可。注意 OAuth 拿到的 token 和 API Key 是两套东西，别混用。用 API Key 直连的场景不会遇到这个错，遇到说明你的客户端配置走了 OAuth 模式，检查客户端的鉴权配置项。

还有一个高频坑是模型名写错。现象是 404 model not found 或者返回的模型跟你预期的不一致。Qwen3 的思考和非思考版本在不同通道下命名规则不同，有的用后缀 -thinking，有的用请求参数控制。以文档页列出的 model 列表为准，别照抄博客里的旧名字。LawLLM 如果通道里没有托管版本，请求会直接报模型不存在，这时候要么换用支持的模型，要么按文档走自定义模型接入流程。

最后提醒一个评测层面的坑：规则判分对生成类任务偏严。案例分析这类任务，模型输出一段分析，gold 是一段参考答案，字符串匹配几乎必然低分，但这不代表模型能力差。如果你的业务以生成类任务为主，建议补一套 LLM-as-Judge 的判分做交叉验证，或者人工抽检 50 条看质量。别拿单一规则分数直接下结论。

6. 按任务选模型：把评测结论落成可执行的配置策略

跑完分不是终点，把结论变成团队能执行的选型规则才有价值。基于上面的结果，我给一个按任务类型分流的配置思路，你可以直接拿去改。

需要开思考模式的任务：刑事损害赔偿计算、基于事实的法条预测、触发词提取、事件检测。这几类要么涉及多步数值推理，要么需要深度语义理解，思考链能带来正增益。配置上选 Qwen3-8B 的思考版本，max_tokens 给足，别让推理过程被截断。

必须关思考模式的任务：命名实体识别、论点挖掘、争议焦点识别、刑期预测、知识问答、案例分析。这几类要么是精准抽取，要么是直接给答案，思考模式引入的冗余和发散会拉低分数。配置上选非思考版本，temperature 可以适当调低到 0.3 左右提升确定性。

垂直模型仍然优先的场景：法律文书生成、深度法律咨询、知识密集型问答。LawLLM-7B 在这些任务上的领域知识密度优势还在，尤其是案例分析和知识问答，领先幅度不小。但要注意，这个优势是相对当前基座而言的，一旦基座换代，优势可能缩水一半，所以垂直模型需要持续微调迭代，不能一劳永逸。

通用模型优先的场景：实体抽取、数值计算、快速焦点判断、刑期预测。Qwen3-8B 非思考模式在这些任务上已经反超，而且通用模型的迭代节奏更快，长期看性价比更高。

如果你要把这套评测固化成团队流程，建议把第 3 节的脚本包成一个 CLI，参数化 dataset、model、output 三个字段，每次新模型发布就跑一遍回归。数据集别只用公开的 LawBench，掺入你自己业务里的真实题目，公开集存在被针对性优化的可能，自建集才能反映真实分布。

需要长期跑编码类 Agent 做评测流水线自动化的，可以看 Coding Plan 页面了解额度方案；只是验证模型对话效果的，直接进模型对话页手动试几条最快；要批量调 API 的，去 API Keys 页面建专用 Key，接入细节看文档页。三个入口按需选，别一上来就上重方案。

实测下来最省事的路径是：先用模型对话页手动对比几条典型题目，确认模型行为符合预期，再用统一 Key 跑批量脚本，最后把分数矩阵和业务抽检结合着看。评测这件事没有一劳永逸的答案，基座在迭代，你的题目集也得跟着迭代。