迎检合规审查（Inspection Review）
输入（向用户确认）
inspection_file：迎检文件路径（PDF/扫描件/图片/docx/xlsx；可为检查清单，也可为通知/方案/正文类文件，后者自动归纳提取检查项）dataset_name：RAGFlow 佐证数据集名inspection_name：检查名称（可选；缺省时从迎检文件名/标题提取简短中文名）
Step 0 — 前置检查
依赖系统环境变量 RAGFLOW_BASE_URL、RAGFLOW_API_KEY，先验证非空：
# bash / Git Bash
[ -z "$RAGFLOW_BASE_URL" ] || [ -z "$RAGFLOW_API_KEY" ] && echo "缺少环境变量"
:: Windows cmd
if "%RAGFLOW_API_KEY%"=="" echo 缺少环境变量
缺失时提示用户配置后重开终端（Windows 新变量不注入已运行会话）。
Shell 变量引用对照（命令其余部分完全一致）：
| Shell | 引用方式 |
|---|---|
| bash / Git Bash | $RAGFLOW_BASE_URL |
| Windows cmd | %RAGFLOW_BASE_URL% |
| PowerShell | $env:RAGFLOW_BASE_URL（且用 curl.exe 而非 curl 别名） |
审查工作目录
在用户当前工作目录创建 <检查名称>-<YYYYMMDD>/（同日重复追加 -HHMM），下称 <DIR>：
内控检查-20260828/
├── checklist.json # Step 1：检查清单
├── requests/ # Step 2：每条检查项的检索请求体
├── evidence/ # Step 2：RAGFlow 原始响应
│ └── docs/ # Step 3：佐证原文副本（原文件名，供报告跳转预览）
└── 合规报告-20260828.md # Step 3：报告（中文名）
JSON/中间产物一律英文名，最终报告用中文名。
Step 1 — 解析检查项
- 用多模态能力直接读取迎检文件，先判定文件形态：
- 清单型：文件本身含检查表格/条目列表（如《检查表》《自查清单》）→ 逐项提取。
- 非清单型（通知、工作方案、制度要求正文等）→ 从正文归纳提取检查项：定位检查范围/要求性表述（"是否…""应…""须提供…""重点检查…"等），逐条归纳，requirement尽量引用原文语句，category按文件章节/主题归类。 - 提取结构化检查项写入
<DIR>/checklist.json（结构见 references/schemas.md）。每条含id、category、requirement（原文）、keywords（2~4 个检索关键词）。
顺序约束：items顺序及item-NN编号严格对应迎检文件中检查项的出现顺序（含表格行序/正文顺序），禁止按分类归并或重排；报告沿用同一顺序。 - 非清单型须先向用户确认：归纳提取带主观性，落盘 checklist.json 前列出全部检查项请用户确认/增删，确认后再落盘执行后续步骤；清单型不打断流程，直接落盘。
- 检查项 >30 条时提示用户是否分批执行；确认后按批走 Step 2/3，报告合并。
Step 2 — 逐条检索佐证
2.1 解析数据集 ID
curl -s -G "$RAGFLOW_BASE_URL/api/v1/datasets" \
--data-urlencode "name=<dataset_name>" \
-H "Authorization: Bearer $RAGFLOW_API_KEY" \
-o "<DIR>/datasets.json"
取 data[0].id 为 dataset_id；查无此名时列出 data[].name 供用户选择。可带 include_parsing_status=true 确认文档均已解析。
2.2 批量检索
第一步：一次性写全部请求体。解析完 checklist 后，为每条检查项生成 <DIR>/requests/<item_id>.json（结构见 schemas.md），在同一轮内并行落盘全部文件，不逐条边检索边写：
{
"question": "<requirement 原文 + 关键词>",
"dataset_ids": ["<dataset_id>"],
"page": 1,
"page_size": 10,
"similarity_threshold": 0.2,
"vector_similarity_weight": 0.3,
"keyword": true,
"highlight": true
}
第二步：一条命令并发执行全部检索（请求体走文件，规避各 shell 引号转义差异；循环为内联 shell 命令，不落脚本文件）：
# bash / Git Bash：后台并发，每凑满 4 个等一波，避免打爆 RAGFlow
DIR="<DIR>"
batch=0
for f in "$DIR"/requests/*.json; do
id=$(basename "$f" .json)
[ -s "$DIR/evidence/$id.json" ] && continue # 断点续跑：已有非空结果跳过
curl -s -X POST "$RAGFLOW_BASE_URL/api/v1/retrieval" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $RAGFLOW_API_KEY" \
--data @"$f" -o "$DIR/evidence/$id.json" &
batch=$((batch+1)); [ $((batch % 4)) -eq 0 ] && wait
done
wait
# PowerShell：顺序循环（一条命令跑完全部，Windows 兜底）
Get-ChildItem "<DIR>\requests\*.json" | ForEach-Object {
$id = $_.BaseName
if (-not (Test-Path "<DIR>\evidence\$id.json") -or (Get-Item "<DIR>\evidence\$id.json").Length -eq 0) {
curl.exe -s -X POST "$env:RAGFLOW_BASE_URL/api/v1/retrieval" `
-H "Content-Type: application/json" -H "Authorization: Bearer $env:RAGFLOW_API_KEY" `
--data "@$($_.FullName)" -o "<DIR>\evidence\$id.json"
}
}
收尾自检：扫描 evidence/*.json，缺失、空文件或 code != 0 的单条单独重跑一次；仍失败则该检查项按缺项处理并在报告判定说明中注明检索失败。
接口字段细节见 references/retrieval-api.md。
Step 3 — 交叉验证 + 报告
逐条读取 evidence/<item_id>.json，比对检查要求与命中 chunks，判定：
| 判定 | 条件 |
|---|---|
| ✅合规 | 最高 similarity ≥ 0.5，且命中内容语义覆盖检查要求 |
| ⚠️待补 | similarity < 0.5，或证据仅覆盖部分要求 |
| ❌缺项 | 无命中（total 为 0 或 chunks 为空） |
阈值依据：合规场景把「待补」误判成「合规」的代价远高于反向漏报，故 0.5 判定线从严；0.2 为接口召回下限。0.35–0.5 区间的命中虽不足以判「合规」，但常是内容不全或存放位置不同的佐证材料，应作为相关线索在待补条目中列出（附文档名与摘录），供人工判断，不改变待补判定。
每条记录：判定、佐证文档名（document_keyword）、页码、最高相似度、关键摘录。document_id 仅用于下载原文与去重，不写入报告。
下载佐证原文：对非缺项判定引用的 document_id 去重，一条循环并发下载到 <DIR>/evidence/docs/（接口返回原文件二进制，见 retrieval-api.md；heredoc 中逐行写入 document_id|文件名，文件名按下方规则清洗）：
DIR="<DIR>"
while IFS='|' read -r doc_id name; do
[ -n "$doc_id" ] || continue
[ -s "$DIR/evidence/docs/$name" ] && continue # 已下载跳过
curl -s "$RAGFLOW_BASE_URL/api/v1/datasets/<dataset_id>/documents/$doc_id" \
-H "Authorization: Bearer $RAGFLOW_API_KEY" \
-o "$DIR/evidence/docs/$name" &
done <<'EOF'
<document_id>|<文件名1>
<document_id>|<文件名2>
EOF
wait
下载后校验文件非空且非错误 JSON（{"code":...}），异常的单条重试。
文件名用 document_keyword 原文件名，仅将非法字符（\/:*?"<>|）和空格替换为 _；同名冲突追加 -<document_id 前 8 位>。下载失败时该条佐证在报告中退化为纯文本文档名，不中断流程。
页码：命中 chunk 的 positions 为 [页码, left, top, right, bottom]，可跨页；取最高相似度 chunk 的全部页码去重排序，标注如 P4-5。
按 templates/report-template.md 生成 <DIR>/合规报告-<YYYYMMDD>.md。佐证列用相对链接 [《文档名》](evidence/docs/<文件名>) 可点击预览；逐条判定、证据摘录、缺项清单的 # 序号均按 checklist.json 的 items 顺序（即迎检文件中的检查项顺序），不按判定结果或分类重排。
关键约束
- 佐证文档名与 document_id 必须来自 RAGFlow 真实响应，禁止编造。
- 相似度低于 0.5 的命中一律「待补」，不得标为合规；其中 0.35–0.5 的命中按相关线索列出文档名与摘录。
- API Key 只出现在请求头，不写入落盘文件，不出现在报告中。
requests/与evidence/保留不删，作为审查痕迹可追溯。- 佐证原文仅下载报告引用的文档（按 document_id 去重），不整库下载。
