Files

caoxiaozhu 52d57c3be7 test(flywheel): 补 few-shot 飞轮单测并沉淀开发文档

- embedding_provider：GLM/Ollama 分支、维度缓存、HTTP 错误降级
- few_shot_ingestion：confirmed/false_positive 入库、ignored 跳过、幂等去重、
  create_feedback hook 触发、feature flag、吞异常
- few_shot_retrieval：去重、token 预算、超长截断；prompt 注入合并 examples + 向后兼容
- 容器内新增测试 20 passed；回归测试 35 passed（RAG/risk_observations/rule_generation）
- 沉淀 document/development/2026-07-03/feature/ai-data-flywheel 概念文档与 TODO，
  飞轮 1 已勾选证据，飞轮 2-6 待后续迭代

2026-07-03 13:56:21 +08:00

12 KiB

Raw Blame History

AI 数据飞轮概念文档

更新时间：2026-07-03

文档路径：document/development/2026-07-03/feature/ai-data-flywheel/CONCEPT.md

功能一句话

把用户反馈、人工修正、风险样本、评测结果自动沉淀并回流到下一次 LLM 推理与规则生成，让费控系统在不停机的情况下持续提升准确率、降低误报率和人工干预率。

背景与问题

当前现状：项目已具备"聪明"的骨架——RAG（knowledge_rag_runtime.py + Qdrant）、风险规则自动生成（risk_rule_generation*.py）、反馈样本沉淀（skills/domain/false-positive-sample-accumulator 等 3 个 accumulator）、规则回放评测（risk-algorithm-replay-evaluator）、行为画像（employee_behavior_profile*）、用户反馈表（agent_feedback.py + AgentOperationFeedback）。
用户痛点：样本在往 accumulator 池子里堆，但下一次 LLM 推理时并没有把这些样本检索出来当 few-shot 喂进去；prompt 散落在各 *_prompt.py，没有版本号、没有在线 A/B、没有回归门禁；OCR 抽取的人工修正值没有回流成评测/训练数据；低分反馈只汇总不归因。
业务影响：系统每次推理都从"初始水平"出发，无法把历史踩过的坑转化成下一次的能力；改 prompt / 改规则无法证明是否变好，存在隐性回归风险；运营和算法同事看不到"系统在进步"的证据。
为什么现在需要做：飞轮骨架已齐，缺的是把"样本池 → 检索注入 + 评测门禁 → prompt/规则版本"这段断开的箭头接上。补上后整张图就转起来，且改动集中在 prompt 构造层 + 新增 eval 目录，不动业务主链路，风险低。

目标与非目标

目标

[G1] few-shot 在线检索注入：推理前从样本池按 case 特征做向量检索，取 top-k 历史样本（含人工结论）拼进 system prompt。
[G2] 黄金评测集 + 自动回归门禁：版本化 golden set，prompt/规则变更后在 golden set 上自动跑分，分数不达标禁止发布。
[G3] Prompt 版本化 + Canary A/B：prompt 进表带版本号，支持 stable / canary 流量切分，反馈分数对比。
[G4] 抽取修正回流：附件/明细字段的人工修正值记录为 diff，沉淀为抽取评测集与 few-shot 样本。
[G5] 低分反馈自动归因：低分反馈触发归因 agent，拉 trace 诊断错误环节并生成改进任务。
[G6] AI 智商看板：每周自动跑 golden set，输出准确率/召回率/误报率/人工干预率随时间的曲线。

非目标

[NG1] 本轮不做模型微调 / 自训练：只走 prompt 侧的 in-context learning + 规则学习。
[NG2] 本轮不改变现有业务主链路（申请单、报销、审批）的接口契约。
[NG3] 本轮不替换 Qdrant / LightRAG 底座，复用现有向量存储与 embedding 配置。
[NG4] 政策新鲜度检测（外部政策变更 → 自动重生成规则）后续再评估，本轮只在评测门禁侧预留接口。

用户与场景

目标用户：
1. 报销人 / 申请人：感知到系统越来越准，少打回、少补件。
2. 财务审批人：误报率下降，审批被打断的次数减少。
3. 算法/运营同学：能看到智商曲线、能灰度上线 prompt、能跑回归评测。
使用入口：
- 推理时自动注入 few-shot（对用户透明）。
- 后台 Canary 控制台（运营切流量、看分数）。
- AI 智商看板（周报 / 在线查询）。
核心场景：
1. 用户提交报销 → 系统预审 → 预审 prompt 自动注入相似历史误报样本 → 给出更准结论。
2. 算法同学改了 risk rule 生成 prompt → 发布前自动跑 golden set → 不达标被门禁拦下。
3. 用户给低分 → 归因 agent 诊断"是检索没召回 / 规则误判 / 回复格式问题"→ 自动建改进任务并回写样本池。
4. 审批人改了 OCR 抽错的金额 → diff 自动沉淀 → 下次同类票据抽取 prompt 多一条 few-shot。
异常场景：
- 样本池为空或检索失败 → 退化为无 few-shot 推理，不阻塞主链路。
- 评测门禁服务不可用 → 默认放行 stable，canary 自动暂停。
- Canary 候选 prompt 分数劣化 → 自动回滚到 stable。

功能能力

[C1] 输入能力：消费 accumulator 样本池、AgentOperationFeedback、附件修正 diff、trace 数据作为飞轮原料。
[C2] 处理能力：样本检索（向量 + 元数据过滤）、评测打分（准确率/召回率/误报率/F1）、Canary 流量切分、低分归因。
[C3] 输出能力：few-shot 注入后的 messages、评测报告、智商曲线、改进任务、归因结论。
[C4] 状态与权限：样本带"人工已确认"标签才进可注入集合；prompt 版本有 stable/canary/pinned 状态；评测门禁可由运营关闭（审计可见）。
[C5] 边界与降级：检索失败、评测失败、Canary 失败均降级到 stable，不阻塞业务推理。

方案设计

前端

页面/组件：
- AI 智商看板（新页面，复用 finance-report 看板骨架）：准确率/召回率/误报率/人工干预率随时间曲线 + golden set 覆盖度。
- Canary 控制台（并入 SettingsView / PoliciesView）：列出各场景 prompt 版本、流量比例、当前分数、一键回滚。
交互状态：加载/空态（样本不足）/错误态（评测失败）/权限态（仅算法运营）。
展示规则：曲线按场景（差旅/报销/预算）分面；Canary 显示置信区间，差异不显著时标注。
降级处理：看板数据不可用时提示"数据生成中"，不报错。

后端

接口/服务（新增，按职责拆分，单文件 ≤ 800 行）：
- services/few_shot_retrieval.py：样本检索器，复用 Qdrant，输入 case 特征 → 输出 top-k 样本（带人工结论）。
- services/prompt_registry.py：prompt 版本注册中心，按场景 + 策略（latest/canary/pinned）取 prompt。
- services/eval_harness.py：在 golden set 上跑评测，输出指标；被发布门禁和智商看板共用。
- services/feedback_attribution.py：低分归因 agent，复用 AgentTraceCenter 数据。
- services/extraction_correction_recorder.py：记录 OCR 抽取字段的人工修正 diff。
改造点（在现有 prompt 构造文件加 inject 钩子，不改业务接口）：
- risk_rule_generation_prompt.py、user_agent_application.py、expense_claim_pre_review.py、document_intelligence_rules.py、ontology_extraction.py 的 prompt 构造处。
权限与校验：Canary 控制台仅算法/运营角色；门禁关闭需审计日志。
持久化（新表，Alembic 迁移）：
- prompt_version：id / scene / content / version / status(stable/canary/pinned) / eval_score / created_by / created_at。
- golden_set：id / scene / case_payload / expected / source(accumulator/manual) / confirmed / version。
- extraction_correction：id / attachment_id / field / raw_value / corrected_value / operator / created_at。
- eval_run：id / prompt_version_id / scene / metrics_json / started_at / finished_at。
降级处理：所有飞轮组件故障均降级到无 few-shot + stable prompt，主链路不阻塞。

算法与规则

输入：case 特征向量（场景标签 + 文本摘要 + 关键字段）、golden set、反馈样本、修正 diff。
流程：
1. 推理前：few_shot_retrieval 检索 top-k → 拼 system prompt。
2. 推理后：结果 + 反馈写入 accumulator。
3. 发布前：eval_harness 在 golden set 上跑分 → 门禁判定。
4. 低分触发：feedback_attribution 归因 → 改进任务回写样本池。
输出：few-shot 样本块、评测指标、归因结论、智商曲线数据点。
解释：few-shot 注入在 prompt 中保留"参考案例（历史已确认）"段落，可追溯；评测报告附错误 case 列表；归因输出错误环节标签 + 证据 trace 片段。

数据与契约

核心字段：scene、case_signature、few_shot_samples、metrics(acc/recall/fpr/f1)、prompt_version_id、status。
状态枚举：
- prompt: stable / canary / pinned / archived。
- golden case: draft / confirmed / deprecated。
- eval: pass / fail / blocked。
兼容策略：prompt_registry 找不到版本时回退到当前硬编码 prompt（保证向后兼容）。
版本/审计：每次 prompt / 规则 / golden set 变更记 eval_run，可回放历史。

算法与公式

few-shot 检索排序

score(sample, case) = α * sim(emb(sample), emb(case)) + β * match(meta(sample), meta(case))

变量说明：

score：样本与当前 case 的综合相似度。
sim：余弦相似度，复用 Qdrant 现有 embedding。
match：元数据硬匹配得分（场景同 / 域同 / 级别同），取 0 或 1。
α、β：权重，默认 α=0.8、β=0.2，可在 prompt_registry 中按场景覆盖。
适用边界：仅取 confirmed=true 的样本；top-k 默认 k=3，按 token 预算动态裁剪。

评测指标

precision = TP / (TP + FP)
recall    = TP / (TP + FN)
f1        = 2 * precision * recall / (precision + recall)