本地化信息甄别流水线：检索增强、置信度分级与批量复核

信息甄别这件事过去靠人盯现在可以用本地模型加检索链路做成一条可复跑的流水线。这个周期9.7—9.13我打算把上一轮临时拼凑的脚本全部推倒重新排一遍秩序统一目录、统一接口、统一置信度分级让“查一条信息是否可信”从手工动作变成可批量的工程动作。核心做法不复杂——本地跑一个开源大模型做语义判断前面接检索与清洗后面接人工复核队列中间用 FastAPI 暴露接口批量任务走目录加队列。它最值得关注的几个点先摆出来一是可以完全本地运行素材不出内网二是支持 CPU 兜底、GPU 加速显存门槛取决于所选模型规模需要按实际版本测试三是提供 HTTP 接口能接进自己的工具链四是支持目录级批量任务带失败重试五是有明确的置信度分级输出不是简单的“真/假”而是“可直接采用 / 需人工确认 / 建议弃用”。这五点决定了它能不能真的用在日常核对工作里而不是演示完就吃灰。硬件门槛方面从常见实践看7B 级别的量化模型在 8G 显存上能跑起来但上下文要给得克制13B 以上建议 16G 起步纯 CPU 推理可行但吞吐会明显下降具体数字必须以本机实测为准本文不会编造任何显存占用数值。真正决定体验的往往不是模型多大而是检索质量、分段策略和提示词约束这三件事。下面按“能力速览—边界—环境—部署—测试—接口—性能—排错—排期”的顺序展开读者可以照着把一条最小可运行的甄别链路搭起来再根据自己的数据特点逐周迭代。适合做技术文档校对、产品参数核对、公开资料一致性检查、内部知识库清洗的读者以及想把大模型接进现有审核流程的工程同学。1. 核心能力速览先把规格摆在前面方便快速判断要不要往下看。需要说明的是这套方案不是某一个固定开源项目的开箱即用包而是基于开源模型与开源框架自行编排的一条流水线因此下表里所有涉及具体数值的项都标注了“需实测”不给虚假承诺。能力项说明方案类型本地化信息甄别流水线检索增强 大模型判定 人工复核来源基于开源推理框架、开源向量检索组件与开源模型自行搭建不绑定单一厂商主要功能文本清洗、分段、检索召回、声明抽取、交叉比对、置信度分级、复核队列导出推荐硬件GPU 8G 起可跑量化小模型16G 以上更从容纯 CPU 可运行但吞吐低显存占用不确定需按实际模型版本、量化等级、上下文长度本机测试支持平台Linux 首选Windows 建议 WSL2 或 DockermacOS 可跑 CPU/MPS启动方式命令行启动推理服务 命令行启动甄别服务或用 Docker Compose 编排是否支持 API是HTTP 接口支持同步单条与异步批量是否支持批量任务是输入目录 任务队列 失败重试 结果落盘输出形式JSON 结构化结果 Markdown 复核报告 CSV 汇总表适合场景技术文档校对、参数一致性核对、公开资料交叉验证、知识库清洗1.1 这条流水线到底解决什么问题单点问答式的用法有个天然缺陷模型只知道它训练时见过的东西遇到你手上的内部文档、产品手册、最新参数表它要么答不上来要么一本正经地编。甄别任务的容错率比闲聊低得多编一次就等于整条结论作废。所以这条流水线的第一原则是“先给证据再下判断”所有判定必须能追溯到具体的检索片段模型不允许脱离证据自由发挥。第二个原则是“分级而不是二分”。真实的核对工作里绝大多数情况不是非黑即白而是“这条说法在现有材料里找不到支撑”“这条说法和另一份材料冲突”“这条说法表述模糊但不算错”。把这些状态区分开人工复核才有意义否则复核员面对一堆“不通过”照样得从头看一遍等于白做。第三个原则是“可复跑”。同一个批次昨天跑出什么结果、今天为什么变了必须有日志可查。这就要求把模型版本、提示词版本、检索参数、输入文件哈希都记录下来形成一份可对比的运行档案。这套东西听起来啰嗦但它是把一次性演示变成生产工具的分水岭。1.2 和直接开个聊天窗口有什么区别直接用聊天窗口也能问“这句话对不对”但三个环节缺失没有检索模型无法引用你的材料没有结构化输出结果没法进表格没有批量能力十条以上就开始复制粘贴。流水线把这些补齐之后人的角色从“逐条判断”变成“抽检和裁决”效率差别很大。另一个区别是可审计。聊天窗口的输出是一次性的出了问题只能重问流水线每一步都有中间产物——清洗后的文本、切分后的片段、召回的 top-k、模型的原始响应、解析后的结构化字段。哪一步出错看对应的中间文件就知道不用靠猜。2. 适用场景与使用边界工具的价值和风险往往同源。甄别类工具最大的风险不是跑不起来而是被当成“判决器”——输出什么就信什么。所以在动手之前先把边界划清楚。2.1 适合的四类场景第一类是内部技术文档校对。同一份产品参数在手册、官网文案、FAQ 里出现三次数值不一致是常态。把三份材料喂进去让它逐条比对并标出冲突位置比人肉翻页快得多。第二类是公开资料一致性核对。做行业研究或者竞品整理时从多个公开渠道收集到的信息经常互相矛盾尤其是版本号、发布时间、规格参数这类硬字段。流水线可以把这些字段抽出来做交叉比对把明显冲突的挑出来优先看。第三类是知识库入库前的清洗。企业知识库最大的问题是历史遗留内容里混着过期信息和错误表述直接入库会污染检索结果。入库前跑一遍甄别把低置信度条目打上待确认标签能显著降低后续的误导。第四类是内容发布前的自查。写完之后逐条核对引用来源是否真实存在、表述是否与原始材料一致属于比较务实的用法。这里要强调自查是为了减少笔误和引用错误不是用来规避内容责任。2.2 不适合的场景不适合做实时性极强的判断。检索库没更新的情况下模型对最新变化的感知为零这时候它的“结论”参考价值很低。不适合做需要专业资质的判断。医疗、法律、金融合规这类领域的结论必须由具备资质的人给出模型只能做材料整理和一致性比对不能替代专业意见。不适合处理来源不明的抓取内容。如果输入材料本身来路不清、授权不明整条链路的输出都没有意义还可能有版权风险。素材来源必须可追溯、使用必须获授权这是前置条件而不是可选项。2.3 使用边界与合规要求三条硬线必须记住。第一素材授权。处理他人文档、图片、音频前要确认你有权处理涉及个人信息的部分要做脱敏能不落盘就不落盘。第二隐私保护。本地部署的意义就在这里敏感材料不出本机、不出内网日志和中间产物也要设置保留期限和访问控制。第三人工终审。任何对外发布的结论、任何影响他人权益的判断都必须有人复核并签字模型输出只作为参考材料。还有一条容易被忽略不要把甄别能力用在操纵信息上。这套工具的设计目标是减少错误信息流通不是制造更精致的错误信息。技术中立不等于使用中立用在哪里、怎么用使用者自己要清楚。3. 环境准备与前置条件3.1 硬件与系统的最低要求系统层面LinuxUbuntu 22.04 一类的长期支持版本最省心驱动和依赖都好处理Windows 建议走 WSL2直接用原生环境容易在编译依赖上卡住macOS 可以跑但只能用 CPU 或 MPS吞吐别期待太高。硬件层面分三档考虑。只有 CPU 的话选 3B 以下的量化模型做分类和抽取把生成式判断降级成规则匹配也能用就是慢。有 8G 显存的话7B 量化模型加短上下文可以跑注意并发要压到 1 到 2。16G 以上显存会舒服很多可以同时挂推理服务和向量检索服务上下文也能放宽。磁盘空间要提前算。模型权重、向量库、输入素材、中间产物、输出报告分五个目录一个中等规模的批次跑下来中间文件可能比原始素材大好几倍。建议预留至少 50G 可用空间如果要做多版本模型对比再往上加。3.2 软件依赖清单按通用实践需要准备这些Python 3.10 或 3.11部分依赖对 3.12 支持还不完整、推理框架命令行推理工具或带 OpenAI 兼容接口的服务端、向量检索组件、文本处理库、Web 服务框架。具体版本以你选定的推理框架官方说明为准本文不写死版本号避免过期。依赖管理建议用虚拟环境隔离别往系统 Python 里装。这一点在同时维护多个模型版本的时候尤其重要不同模型对依赖版本的要求经常打架。# 创建并激活虚拟环境路径按实际项目调整 python3.11 -m venv .venv source .venv/bin/activate # 安装基础依赖版本请以所选框架官方文档为准 pip install --upgrade pip pip install fastapi uvicorn requests pydantic pip install sentence-transformers faiss-cpu # 验证关键依赖是否可用 python -c import fastapi, faiss; print(deps ok)3.3 目录结构约定目录结构看起来是小事实际上是“重启秩序”里最见效的一步。上一轮最大的痛点就是输入输出混在一起跑完不知道哪个文件是哪次生成的。这一轮统一成下面这套所有路径写进配置文件代码里不允许出现硬编码路径。info-audit/ ├── configs/ │ ├── pipeline.yaml # 全局配置模型地址、检索参数、阈值 │ └── prompts/ │ ├── extract_v1.txt # 声明抽取提示词 │ └── judge_v2.txt # 判定提示词 ├── models/ # 模型权重只读 ├── data/ │ ├── raw/ # 原始素材只读按来源分目录 │ ├── clean/ # 清洗后文本 │ └── index/ # 向量库文件 ├── tasks/ │ ├── pending/ # 待处理任务清单 │ └── done/ # 已完成任务清单 ├── outputs/ │ ├── 2025-09-07/ # 按日期分目录 │ └── 2025-09-08/ └── logs/ ├── service.log └── batch.log约定三条规矩raw 目录只读任何处理结果都写到 clean 或 outputs每次运行生成一个运行 ID写进所有输出文件名日志按天切分超过保留期限自动清理。这三条落地之后回溯问题的成本会降一大截。4. 本地部署与启动方式整个链路需要两个服务一个是推理服务负责把文本变成判断一个是甄别服务负责调度检索、拼装提示词、解析输出、落盘结果。两个服务分开的好处是推理服务可以换模型而不动业务代码。4.1 启动推理服务如果你用的是带 OpenAI 兼容接口的本地推理工具启动命令大致如下。端口冲突是这个环节最常见的坑习惯上先检查 8000 和 11434 两个常用端口有没有被占。# 启动本地推理服务模型名与端口按实际情况替换 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name audit-model \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 # 如果使用轻量级命令行推理工具启动方式类似 # ollama serve # ollama pull model-name # 验证服务是否就绪 curl -s http://127.0.0.1:8000/v1/models | head -c 500--max-model-len和--gpu-memory-utilization这两个参数是显存占用的主要开关。上下文开太大长文档是舒服了显存也吃满了利用率设太高容易在并发上来时直接爆掉。稳妥的做法是先按 0.8 左右跑观察一段时间再微调。4.2 启动甄别服务业务侧用 FastAPI 包一层核心逻辑是“接收请求—检索证据—拼提示词—调模型—解析结果—落盘”。下面给一个可运行的最小骨架实际项目里要补上异常处理和重试。# app/main.py import json import time import uuid from pathlib import Path import requests from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleInfo Audit Service) MODEL_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME audit-model OUTPUT_DIR Path(./outputs) OUTPUT_DIR.mkdir(parentsTrue, exist_okTrue) class ClaimRequest(BaseModel): claim: str evidence: list[str] [] workspace: str default def build_prompt(claim: str, evidence: list[str]) - str: joined \n.join(f[{i 1}] {e} for i, e in enumerate(evidence)) or [无检索结果] return ( 你是资料一致性核对助手。只能依据下方证据判断不得引入外部知识。\n 输出 JSON字段为 verdictsupported/conflicted/insufficient、 confidence0-1、reason不超过80字、cited引用证据编号数组。\n\n f待核对声明{claim}\n\n证据\n{joined} ) app.post(/api/audit) def audit(req: ClaimRequest): run_id uuid.uuid4().hex[:12] started time.time() payload { model: MODEL_NAME, messages: [{role: user, content: build_prompt(req.claim, req.evidence)}], temperature: 0.0, max_tokens: 512, } resp requests.post(MODEL_URL, jsonpayload, timeout120) resp.raise_for_status() raw resp.json()[choices][0][message][content] result {run_id: run_id, claim: req.claim, raw: raw, elapsed: round(time.time() - started, 2)} (OUTPUT_DIR / f{run_id}.json).write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8) return result启动方式很直接--workers不要设太大本地推理服务扛不住高并发设成 1 到 2 更稳。uvicorn app.main:app --host 127.0.0.1 --port 7860 --workers 14.3 用 Docker Compose 编排如果要在多台机器上复现同一套环境Docker 更省事。注意 Docker 内访问宿主机推理服务时127.0.0.1指向的是容器自己需要换成宿主机地址或者用host.docker.internal。# docker-compose.yaml services: audit-api: build: . ports: - 7860:7860 volumes: - ./data:/app/data - ./outputs:/app/outputs - ./logs:/app/logs environment: - MODEL_URLhttp://host.docker.internal:8000/v1/chat/completions - MODEL_NAMEaudit-model - LOG_LEVELINFO extra_hosts: - host.docker.internal:host-gateway restart: unless-stopped4.4 判断启动成功的三个标准不要看到日志里出现 “Uvicorn running” 就以为成了。三个验收点一是推理服务的模型列表接口能返回目标模型名二是甄别服务的单条接口能用一条简单声明跑通并返回结构化 JSON三是outputs目录里确实生成了对应 run_id 的文件。三个都过了才算环境就绪。5. 功能测试与效果验证验证顺序建议从单条到批量、从短文本到长文档。一上来就丢一堆长文档出问题时根本分不清是检索坏了、分段坏了还是模型不行。5.1 单条声明核验测试目的是确认最基础的通路是否正常。准备一条可以从证据里直接判断的声明比如“某型号设备的接口数量为 4 个”证据里放一段明确写着“4 个千兆网口”的文本。预期输出verdictsupportedcited里包含证据编号 1。判断成功的标准不只看结论对不对还要看reason是否引用了证据里的具体表述。如果模型给出的理由是空泛的“根据资料显示”说明提示词约束不够需要把“必须引用证据编号”这条要求强化。常见失败原因有三个提示词里没写“不得引入外部知识”模型自由发挥证据拼接时没加编号模型无法回指temperature设得太高同一条声明跑两次结果不同。核对类任务的温度建议直接设 0。5.2 多源交叉比对这个测试模拟真实冲突场景。准备两份材料一份写“支持 8 路输入”另一份写“最大 16 路输入”让流水线判断同一声明在不同来源下是否一致。预期输出verdictconflicted并在理由里指出两份材料的差异。这一步最容易出现的偏差是模型“自作聪明”地解释冲突比如编一个“不同版本硬件规格不同”的说法把矛盾圆过去。如果发现这种情况要在提示词里明确禁止推测性解释只描述冲突本身。5.3 长文档分段核验长文档不能整篇塞进上下文一是超长会截断二是关键信息淹没在中间模型容易漏。正确做法是先按语义切分成 300 到 500 字的片段带重叠窗口再逐段检索和判定。这里有组参数需要反复调片段长度太短会切断语义太长会让检索命中率下降重叠窗口太小会在边界丢信息太大会让重复内容变多。经验值是从 400 字加 80 字重叠开始试观察召回结果的完整性再调整。验证方法很实在故意在两段之间放一条跨段的声明看流水线能不能把两部分证据同时召回。召回不全就是切分策略有问题别急着怪模型。5.4 批量任务验证准备一个包含 20 到 50 条任务的小批次跑完整个流程。重点观察三件事任务是否有遗漏输入条数等于输出条数、失败任务是否被记录不是静默跳过、断点重跑是否只处理未完成的。这三条是批量能力的基本盘任何一条不达标规模上去之后就是灾难。5.5 置信度分级与人工复核这是整条链路的价值出口。建议把输出分成三档置信度 0.8 以上且证据明确的标记为“可直接采用”0.5 到 0.8 之间或者证据单薄的进入人工复核队列0.5 以下或返回insufficient的标记为“建议弃用或补充材料”。阈值不要拍脑袋定拿一批人工已判定过的样本做校准看看不同阈值下误判率怎么变。阈值定得太松复核队列会堆成山定得太紧错误结论会溜进下游。这个平衡点每个团队都不一样必须自己调。6. 接口 API 与批量任务6.1 接口设计要点接口保持小而清晰。单条核验一个接口批量提交一个接口查询任务状态一个接口拉取报告一个接口。请求体里带工作区标识方便不同项目的数据隔离。响应里必须包含 run_id这是后续追查的唯一凭据。批量接口不要在请求里传几万条数据改成传任务清单路径服务端从目录读取异步执行客户端轮询状态。这样既避免请求超时也方便失败重试。6.2 curl 调用示例# 单条核验 curl -X POST http://127.0.0.1:7860/api/audit \ -H Content-Type: application/json \ -d { claim: 该设备支持 4 个千兆网口, evidence: [规格书第 3 页网络接口为 4 个 10/100/1000M 自适应以太网口], workspace: product-doc } # 批量提交 curl -X POST http://127.0.0.1:7860/api/batch \ -H Content-Type: application/json \ -d {task_file: ./tasks/pending/0907_batch01.jsonl, workspace: product-doc}6.3 Python 批量调用与重试批量脚本的重点不是并发而是幂等和重试。每条任务带唯一键跑之前先查结果目录里有没有同键的产物有就跳过失败的记录到失败清单单独重跑不要整个批次推倒重来。import json import time from pathlib import Path import requests API http://127.0.0.1:7860/api/audit FAILED Path(./tasks/failed.jsonl) DONE_DIR Path(./outputs/today) def run_one(item: dict, retries: int 3) - bool: for attempt in range(retries): try: resp requests.post(API, jsonitem, timeout180) resp.raise_for_status() data resp.json() (DONE_DIR / f{item[task_id]}.json).write_text( json.dumps(data, ensure_asciiFalse, indent2), encodingutf-8) return True except Exception as exc: wait 2 ** attempt print(f[retry {attempt 1}] {item[task_id]} err{exc} wait{wait}s) time.sleep(wait) with FAILED.open(a, encodingutf-8) as f: f.write(json.dumps(item, ensure_asciiFalse) \n) return False if __name__ __main__: DONE_DIR.mkdir(parentsTrue, exist_okTrue) todo [json.loads(line) for line in Path(./tasks/pending/0907_batch01.jsonl).read_text(encodingutf-8).splitlines() if line.strip()] ok sum(run_one(item) for item in todo) print(ffinished {ok}/{len(todo)})6.4 批量任务配置配置项统一放一个文件别散落在代码各处。下面这份配置里并发数、超时、重试次数是最常改的三个。{ input_dir: ./tasks/pending, output_dir: ./outputs/2025-09-07, workspace: product-doc, concurrency: 2, request_timeout: 180, max_retries: 3, top_k: 5, chunk_size: 400, chunk_overlap: 80, confidence_accept: 0.8, confidence_review: 0.5, fail_fast: false }concurrency千万别贪。本地单卡推理服务的并发能力有限设成 4 以上经常出现请求排队、超时、显存抖动最后整体耗时反而更长。2 是一个比较稳的起点观察显存和响应时间再决定要不要往上加。7. 资源占用与性能观察7.1 怎么看显存和内存观察显存最直接的方式是盯着 nvidia-smi 的动态输出跑批的时候另开一个终端看着比事后看日志有效得多。同时用系统监控看内存和 swap很多时候推理没爆显存文本处理环节先把内存吃满了。# 每 2 秒刷新一次显存占用 watch -n 2 nvidia-smi # 记录一段时间内的显存峰值到文件便于事后分析 nvidia-smi --query-gputimestamp,memory.used,utilization.gpu \ --formatcsv -l 2 logs/gpu_0907.csv7.2 影响耗时的四个变量第一是上下文长度。这是最容易被低估的因素输入从 2K 涨到 8K耗时可能是三四倍的增长不是线性关系。第二是输出长度。让模型写长篇理由和只写一句话差别很大核对任务里理由控制在 80 字以内完全够用。第三是检索 top-k。召回 10 条和召回 3 条拼出来的提示词长度差一倍多。第四是并发数。并发不是越高越快超过推理服务的处理能力之后就是纯粹的排队。调试期的建议是先把 top-k 降到 3、理由限长、并发设 1确认逻辑没问题再逐项放开观察性能变化。这样每一步的变量都可控。7.3 降低资源占用的手段模型量化是最有效的一招从 FP16 降到 INT8 或 INT4显存需求下降明显对判断类任务的准确率影响相对可控。上下文裁剪也很管用只把最相关的三条证据送进去比塞十条效果好还省资源。分批处理同样重要把大批次拆成小批避免一次性加载大量文本。还有一招是分级调用先用轻量模型或者规则做粗筛只把那些明显冲突、证据不足的条目送进大模型。在任务量大、冲突比例低的场景里这一招能把调用量降一半以上。7.4 端口与进程残留服务跑久了最容易遇到的不是报错而是端口被上一次没退干净的进程占着新服务起不来日志里只写一句“address already in use”。养成习惯启动前先查端口停止时用正常信号不要直接关终端窗口。# 查端口占用 lsof -i :7860 lsof -i :8000 # 确认是自己启动的进程后再结束不要误杀其他服务 kill -15 PID # 如果进程卡死不响应再用强制结束之后手动清理临时文件 # kill -9 PID8. 常见问题与排查方法排错的核心思路是分段定位先用 curl 直接打推理服务确认模型侧正常再打甄别服务确认业务侧正常最后跑单条任务确认链路正常。跳过任何一步都可能把时间浪费在错误的方向上。问题现象可能原因排查方式解决方案服务启动报端口占用上次进程未退出lsof -i :端口结束旧进程或更换端口推理接口 404模型名不匹配查/v1/models返回配置里的模型名与服务端一致依赖安装失败Python 版本或编译工具缺失看完整报错首行换 3.10/3.11装编译依赖显存不足 OOM上下文过长或并发过高看显存峰值曲线降 max-model-len并发设 1模型返回非 JSON提示词约束不足看原始响应加格式约束温度设 0结果全是 insufficient检索没命中检查向量库条数与 top-k重建索引调分段参数批量任务中途卡住单条请求超时无重试看 failed.jsonl加超时与指数退避重试输出结论前后不一致温度过高或提示词不稳同一条跑三次对比温度归零固定提示词版本中文乱码编码未指定检查文件头统一 UTF-8写文件显式指定Docker 内连不上模型容器网络隔离容器内 curl 测试用 host-gateway 或宿主 IP几个高频问题展开说一下。第一个是“结果全是 insufficient”八成不是模型不行而是向量检索没召回。先把 top-k 调大试试如果还是不命中检查分段是不是把关键句切碎了。第二个是“结论前后不一致”先确认温度是不是 0再确认提示词版本有没有变最后看证据顺序是否随机打乱导致模型注意力偏移。第三个是“批量跑到一半卡住”通常是某条超长文本把上下文撑爆了加了超时和重试之后至少不会整个批次挂死。9. 一周迭代排期与最佳实践9.1 9.7 到 9.13 的排期建议把一周拆成可交付的小块比列一堆宏大目标有用。日期目标交付物验收标准9.7环境重置与目录统一目录结构、配置文件模板单条接口跑通产物落盘9.8推理服务稳定化启动脚本、端口检查脚本连续运行 4 小时无异常9.9清洗与分段调参分段参数记录、召回抽样跨段声明能正确召回9.10提示词定版extract_v1、judge_v2同输入三次结果一致9.11批量链路与重试批量脚本、失败清单50 条批次零遗漏9.12阈值校准校准样本集、阈值报告复核队列量在可承受范围9.13复盘与归档运行档案、问题清单下周可直接复用排期里特意留了 9.12 做阈值校准这一步最容易被跳过但它直接决定人工复核的工作量。没有校准的阈值就是拍脑袋跑两天就会因为复核队列爆炸而放弃。9.2 工程化建议第一条永远先跑最小样例。新增任何功能先用三到五条数据验证通路再上规模。第二条保留一套最小可运行配置出问题时能快速退回上一个可用状态别在唯一环境上做实验。第三条输入、输出、模型、日志四个目录严格分开任何跨目录写入都要在代码里显式声明。第四条批量任务必须有日志和失败重试日志里至少记录任务 ID、耗时、模型版本、提示词版本四个字段。第五条接口服务只监听本地或内网地址不要直接暴露到公网。需要跨机器调用的话加一层鉴权限制调用来源。第六条涉及个人信息、未公开材料、他人版权内容时先确认授权范围处理过程做脱敏产物设置保留期限。第七条发布或对外使用前必须做效果复核。抽检比例建议不低于 10%重点抽查高置信度的那一档——因为这一档最容易被人直接采信一旦出错影响最大。9.3 提示词维护的两点经验提示词一定要版本化。文件名带版本号配置文件里写死引用哪个版本改了就新建文件而不是原地覆盖。这样出问题能回滚做 A/B 对比也有依据。提示词里要把“禁止推测”写死。核对类任务最怕模型自作主张补全信息一句“不得引入证据之外的知识无法判断时输出 insufficient”能挡掉大部分幻觉。再加上“必须引用证据编号”可追溯性就有了。10. 后续可以扩展的方向这套链路跑通之后能扩展的地方不少但建议按优先级来不要一次全上。优先级最高的是把复核环节做成一个轻量界面。现在复核靠看 JSON 和 CSV效率低。做一个列表页左边显示声明右边显示召回的证据原文并高亮关键句复核员点三个按钮就能完成裁决。这个投入产出比最高。其次是补上版本对比能力。同一批数据用两版提示词或两个模型各跑一遍自动生成差异报告只列出结论不同的条目。这样调参的时候不用人肉比对几千条结果。第三是加一层规则前置。像“数字不一致”“日期格式异常”“型号拼写差异”这类问题正则和规则引擎处理起来又快又准没必要全丢给模型。规则先筛一遍模型只处理需要语义判断的部分整体成本能降不少。最后是输出格式的标准化。现在输出是自定义 JSON如果要接进其他系统最好对齐一种通用的结构化格式把结论、置信度、证据位置、处理时间、模型版本都带出去。格式统一了后面接 BI 或者工单系统都方便。这套东西真正的价值不在模型多强而在于把“核对”这个动作从靠记忆和责任心变成有记录、可复跑、能分工的流程。秩序重建的意义就在这里——不是让机器替你做判断而是让每一条判断都有据可查让人的精力集中在真正需要裁决的那一小部分上。