专业级大模型落地指南：能力评估与工程实践

一、为什么专业场景需要重新审视模型选型

专业场景的任务通常有三个特征：输入信息量大，输出需要能被核对，错误成本高。合同条款审查、财务报表分析、代码评审、医疗文献整理，都属于这一类。团队在这类场景中使用大语言模型时，关注点不能停留在”回答是否流畅”上，而要转向三个问题：结论能否追溯到依据，步骤能否复现，失败能否被及时发现。

模型厂商发布新版本时，通常会给出通用基准测试成绩。这些成绩能说明模型在标准任务上的大致水平，但无法直接替代业务评测。同一个模型在通用问答上表现良好，在工单分类或合同字段抽取上却可能差距很大。因此，选型的第一步是把业务需求拆成可以测量的指标，再用自己的数据去验证。

二、选型的六个评估维度

选型需要同时考虑质量、速度和成本。下面六个维度覆盖了大多数专业场景的核心要求。

维度	测量方式	判断依据示例
任务准确率	在业务样本上计算正确率，按任务类型分开统计	字段抽取准确率不低于人工标注的既定阈值
指令遵循	检查输出是否符合格式、字段、长度和禁用词要求	连续 100 次调用中格式错误率低于 1%
长上下文处理	把关键信息放在输入的不同位置，测试能否被正确引用	文档末尾的条款也能被准确回答
工具调用能力	检查是否在合适时机调用函数，参数是否合法	参数类型错误率可控，无越权调用
延迟与吞吐	记录首字延迟、整段耗时和并发排队时间	在目标并发下，P95 延迟满足前端交互要求
综合成本	计算输入输出 token 费用，并计入重试和人工复核工时	单个任务的总成本低于人工处理成本

这里有两点需要注意。第一，标称的上下文窗口大小只说明输入上限，不说明有效利用率。实际测试中，输入接近上限时，中间位置的信息往往更容易被遗漏。第二，成本不能只看单价。如果模型输出不稳定，导致重试次数增加，综合成本可能高于单价更高但更稳定的方案。

三、搭建业务评测集

评测集是选型的基础。它应该来自真实业务数据，并由领域专家标注标准答案。一个可用的评测集通常具备以下特点。

1. 规模：每类任务至少 200 条样本，关键任务建议 500 条以上。
2. 覆盖：包含常见情况、边界情况和历史上出过错的情况。
3. 分层：按难度标记样本，便于观察模型在不同难度上的表现差异。
4. 隔离：留出一部分样本作为最终验证集，不参与提示词调优，避免过拟合。

下面是一个简化的评测框架示例。其中的 call_model 是一个占位函数，实际使用时替换为团队自己的调用封装。

from dataclasses import dataclass, field
@dataclass
class EvalCase:
    case_id: str
    category: str
    prompt: str
    expected_keywords: list[str] = field(default_factory=list)
def contains_all_keywords(answer: str, keywords: list[str]) -> bool:
    return all(keyword in answer for keyword in keywords)
def run_eval(cases: list[EvalCase], call_model) -> dict:
    results = []
    for case in cases:
        answer = call_model(case.prompt)
        passed = contains_all_keywords(answer, case.expected_keywords)
        results.append({
            "case_id": case.case_id,
            "category": case.category,
            "passed": passed,
        })
    summary = {}
    for item in results:
        bucket = summary.setdefault(item["category"], {"total": 0, "passed": 0})
        bucket["total"] += 1
        bucket["passed"] += int(item["passed"])
    for bucket in summary.values():
        bucket["accuracy"] = bucket["passed"] / bucket["total"]
    return summary

关键词匹配只是最粗糙的判定方式。对于开放式回答，可以使用更细的规则，例如要求引用特定段落编号，或由第二个模型或人工按评分细则打分。无论采用哪种方式，评分规则都应在测试前固定，避免事后调整标准。

四、用结构化输出约束结果

专业场景中，模型输出最好能被程序直接处理。常见做法是要求模型返回固定结构的数据，然后在程序侧做校验。校验失败时，把错误信息附在提示词中重试，并设置重试上限。超过上限的样本转入人工队列。

import json
REQUIRED_FIELDS = {
    "contract_id": str,
    "party_a": str,
    "party_b": str,
    "amount": (int, float),
    "risk_level": str,
}
ALLOWED_RISK_LEVELS = {"low", "medium", "high"}
def validate_output(raw_text: str) -> tuple[bool, str]:
    try:
        data = json.loads(raw_text)
    except json.JSONDecodeError as exc:
        return False, f"JSON 解析失败：{exc}"
    for name, expected_type in REQUIRED_FIELDS.items():
        if name not in data:
            return False, f"缺少字段：{name}"
        if not isinstance(data[name], expected_type):
            return False, f"字段类型错误：{name}"
    if data["risk_level"] not in ALLOWED_RISK_LEVELS:
        return False, "risk_level 取值不在允许范围内"
    return True, "ok"
def extract_with_retry(document: str, call_model, max_retries: int = 2) -> dict | None:
    prompt = f"请从以下合同中抽取字段，只返回 JSON：\n{document}"
    for _ in range(max_retries + 1):
        raw = call_model(prompt)
        ok, reason = validate_output(raw)
        if ok:
            return json.loads(raw)
        prompt = (
            f"上一次输出未通过校验，原因：{reason}。"
            f"请修正后只返回 JSON。\n合同内容：\n{document}"
        )
    return None  # 返回 None 的样本进入人工复核队列

这段代码体现了三个原则。第一，校验逻辑独立于模型，程序不依赖模型”自觉遵守格式”。第二，重试时把具体失败原因告诉模型，修正成功率通常高于盲目重试。第三，重试次数有上限，失败样本有明确去向，不会无限消耗调用额度。

五、工具调用与工作流编排

当模型需要查询数据或执行操作时，工具调用能力就变得重要。设计工具接口时，应遵循下面几条原则。

1. 最小权限：每个工具只做一件事，默认只读。
2. 白名单：模型只能调用注册过的工具，未注册的名称一律拒绝。
3. 参数校验：在工具入口检查参数类型和取值范围，不信任模型生成的参数。
4. 写操作确认：涉及修改、删除或发送的动作，必须经过用户或审批流程确认。
5. 全量记录：每次调用的名称、参数、返回值和耗时都写入审计日志。

ALLOWED_TOOLS = {
    "query_order_status": {"read_only": True},
    "create_refund_request": {"read_only": False},
}
def dispatch_tool_call(name: str, args: dict, user_confirmed: bool, handlers: dict):
    if name not in ALLOWED_TOOLS:
        return {"error": f"工具未注册：{name}"}
    policy = ALLOWED_TOOLS[name]
    if not policy["read_only"] and not user_confirmed:
        return {"error": "写操作需要用户确认", "requires_confirmation": True}
    handler = handlers[name]
    try:
        return {"result": handler(**args)}
    except TypeError as exc:
        return {"error": f"参数错误：{exc}"}

这里的白名单和确认机制是程序层面的硬约束。提示词可以告诉模型”不要删除数据”，但真正阻止误操作的是程序逻辑。两者都需要，且程序逻辑应当优先。

六、检索增强：让回答有据可查

专业问答通常依赖企业内部文档，而这些文档不会出现在模型的训练数据中。检索增强生成是常见方案，即先从文档库中找出相关段落，再把段落连同问题一起交给模型。落地时需要关注以下环节。

• 切分：按章节或语义切分文档，避免把一条完整条款拆到两个片段中。
• 检索：同时使用关键词检索和向量检索，两者结果合并后去重排序。
• 引用：要求模型在每个结论后标注来源片段编号，程序检查编号是否真实存在。
• 更新：文档变更后，相关片段要及时重建索引，并记录版本号。

引用检查是低成本、高收益的环节。模型偶尔会编造不存在的编号，程序只需比对编号列表即可发现，无需人工逐条核对。

七、调用层的稳定性设计

模型服务会出现超时、限流和临时故障。调用层应当把这些情况处理好，否则业务表现会随着网络波动而起伏。

import random
import time
def call_with_backoff(call_model, prompt: str, max_attempts: int = 4, timeout_s: float = 30.0):
    for attempt in range(1, max_attempts + 1):
        try:
            return call_model(prompt, timeout=timeout_s)
        except TimeoutError:
            if attempt == max_attempts:
                raise
        except RuntimeError as exc:  # 此处可按实际错误类型细分
            if attempt == max_attempts:
                raise
            print(f"第 {attempt} 次调用失败：{exc}")
        delay = min(2 ** attempt, 16) + random.uniform(0, 1)
        time.sleep(delay)

除重试外，还有几项设计值得考虑。

• 超时：为每次调用设定明确的超时时间，避免线程长期挂起。
• 幂等：对写操作的重试要结合唯一请求编号，防止重复执行。
• 降级：主模型不可用时，切换到备用模型或返回”请稍后再试”，而不是给出空结果。
• 预算：按日或按项目设置调用额度，超出后告警并暂停非关键任务。
• 流式输出：面向人的交互场景采用流式返回，能明显降低用户感知的等待时间。

八、安全与合规

专业场景通常涉及个人信息、商业秘密和受监管的数据，安全要求应当在设计阶段确定，而不是上线前补救。

第一，数据最小化。只把完成任务必需的字段发送给模型，身份证号、银行卡号等敏感信息在发送前脱敏。

第二，权限隔离。模型只能访问当前用户有权限的文档。检索层要在返回结果前过滤权限，不能依赖模型自行判断。

第三，提示词注入防护。检索到的文档内容属于数据，不属于指令。如果文档中写有”忽略之前的要求”之类的文字，系统应当将其视为普通文本处理，并在日志中标记。工具调用的白名单与确认机制，也能限制注入攻击造成的影响。

第四，人工复核。涉及金额、法律责任和医疗判断的结论，应当经过人工审核后再生效。模型输出在这些环节中只起辅助作用。

第五，审计留存。输入、输出、模型版本和工具调用记录要按合规要求保存，便于事后追溯。

九、上线路线图

稳妥的上线过程通常分为四个阶段。

1. 离线评测：在评测集上完成各维度测试，确定候选模型和提示词版本。
2. 影子运行：模型与现有流程并行处理真实请求，只记录结果，不影响业务。对比两者的差异，找出典型错误。
3. 小范围灰度：选择一个部门或一类任务开放使用，所有输出先经过人工确认。
4. 全量上线与持续监控：扩大范围后，监控准确率抽样、格式错误率、延迟和成本，设定告警阈值。

模型版本发生变化时，应当重新运行完整评测集。即使新版本