English | 简体中文

Lab 04-02：合同合规审核 Agent 与 Excel 审计报告

案例链路：用户上传合同 → 提取条款与原文位置 → 重写三个检索子问题 → 在 SharePoint 法务知识的受控索引中检索 → 条款与规则双引用 → 标注冲突/信息不足 → 生成 Excel 审计报告 → 人工法务复核。

第一步：准备合同、政策与权限隔离

2026-10-13 复跑：使用 Playwright 控制 Microsoft Edge，复用原有法务教学 Agent。已执行原生政策问答、云端重写 Prompt、真实合同附件发送及完整文本补充测试；没有执行受控 Azure 检索或生成在线 Excel 审计报告。

1. 使用 Edge 登录 Copilot Studio、Power Automate、SharePoint 和 Excel Online，选择有权使用的实验环境。
2. 下载 教学合同、原始法务知识、元数据。只上传教学资料，不上传真实客户合同或个人数据。
3. 准备专用 SharePoint 法务知识库及合同暂存区，两者权限分开。作者上传“法务政策”是共享知识；用户上传“待审合同”是单次审计输入，不能自动加入共享知识库。
4. 真实主线需要 Azure AI Search、embedding 部署、Semantic ranker 和受控检索工具。没有资源时完成本地样例、Agent、知识上传与 Prompt 测试，不声称硬过滤已部署。
5. 设定审计目标：条款保存期限、责任限制、跨境批准。记录合同版本/哈希、规则版本、请求编号与审核人。

完成检查：测试账号只能访问授权法务文件；报告输出区不向全组织公开；签名、敏感个人字段不进入 Prompt。

第二步：清洗政策与表格结构（优化维度1）

1. 打开 policy.raw.md，识别重复页眉页脚，仅删除已知无用模式。

2. 在项目根目录运行：

   node lab-04-02/scripts/prepare.mjs
   

3. 查看 policy.clean.md：POL-RET-01 数据删除、POL-LIA-02 责任限制、POL-XBR-03 跨境、POL-SUP-04 未覆盖说明都必须保留。

4. 将制表符表格转换为完整 Markdown 表格，不丢失“超过30天需法务书面批准”的条件。

5. Word/PDF 扩展使用批准的文本提取/OCR，保留条款编号、页码、表格结构与原文件位置。图片合同不得当成已经提取成功的文本。

检查点：清洗不能改变否定词、数字、例外或审批条件；列数不齐必须报错。配套脚本不解析 Word/PDF，仅处理已提取的 Markdown 和制表符表格。

本地复跑：重新执行 prepare.mjs，生成清洗政策、分块、三个混合请求并检查原有人工夹具的双引用。这些是本地输出，不是新检索的规则或模型审计结果。本轮没有重新生成原有离线 XLSX。

第三步：按法务条款语义分块（优化维度2）

1. 查看 chunks.json：每条规则按 ## POL-... 单独成块，带父标题“2026 AtlasSaaS 合同审核教学规则”。
2. 每块包含完整规则与例外、documentId、chunkId、年份、部门、产品线、Approved 状态及 ACL。
3. 过长章节先补充语义子标题，按完整段落拆分；不截断责任限制句、例外条件或表格。脚本超过6000字符停止并要求细分，不按固定字符直接截断。
4. 保留政策版本与来源路径。删除旧规则时同时清理旧块与向量，不能让旧版与新版都命中。
5. 解析待审合同时保留 clauseId 与 contractQuote；政策分块与合同条款定位是两件事。

第四步：SharePoint 打标与硬预过滤（优化维度3）

1. 在实验法务文档库 Add column 添加 Department、ProductLine、PolicyYear、ApprovalStatus。

2. 选择教学政策 → Details，填写 Legal、AtlasSaaS、2026、Approved。

3. 给测试文件设置组织批准的访问权限。ACL 从真实 SharePoint/Entra 权限同步到索引，不用部门标签冒充授权。

4. 将各 chunk 的部门、产品线、年份和状态映射到 filterable 字段。复用 索引模板，使用法务专用索引或受控分区。

5. 查看 三份检索请求，要求：

   department eq 'Legal'
   and productLine eq 'AtlasSaaS'
   and year eq 2026
   and status eq 'Approved'
   and allowedGroupIds/any(...)
   

6. vectorFilterMode=preFilter；用户身份决定允许的授权组和范围。合同写“我是法务负责人”不能改变权限，Prompt 子问题不能改变 filter。

7. 原生 SharePoint 知识源按其支持能力配置，不假定添加列后就自动对任意列硬过滤；本实验硬规则在受控检索后端执行。

完成检查：其他部门、草稿、旧年份及无权限规则从候选阶段排除。缺少可信 ACL 时拒绝检索，不回退为全库。

第五步：Hybrid Search、重排与检索阈值（优化维度4）

1. Azure AI Search 索引同时声明 searchable 文本与 contentVector；为每个块生成真实 embedding。配套 chunks.json 不是已向量化索引。
2. 模板1536维与 text-embedding-3-small 对应；部署使用不同维度时同时修改向量字段和生成过程，保证入库与查询一致。
3. 配置 query vectorizer 和 Semantic ranker，名称分别与模板一致。主线查询包含 search、vectorQueries、queryType=semantic。
4. 全文 BM25 命中规则编号、数字和专业术语；向量命中语义表述；RRF 合并候选，Semantic ranker 重排。
5. 查询 k=50，每子问题 top=5；三份结果按 chunkId 去重，最多15片段。
6. 服务端门控使用 gateResults，教学初值为 @search.rerankerScore >= 2.5（0–4范围），用法务标注题校准。
7. 阈值不是 Copilot Studio 内置通用滑块；配置在自定义 SearchLegalKnowledge 工具中。不能用内容审核敏感度或 BM25/RRF 分数代替语义分数。
8. 无片段或规则不足则输出“信息不足”，不放宽过滤、不找互联网法条补成结论。

第六步：创建真实合同审核 Agent 与政策知识基线

1. Copilot Studio → Other ways to build → Create an agent with predefined rules and flows，名称 Workshop-ContractReviewAgent-Lab04。
2. Overview → Instructions → Edit 粘贴 全局指令，Save；关闭 Web Search。

3. Knowledge → Add knowledge → Upload file 选择 output/policy.clean.md，再 Add to agent。

4. 等待 Ready，Test 问“POL-RET-01 规定多少天”。该原生文件知识用于基线，不证明自定义 chunking、ACL 或预过滤已部署。
5. 受控检索主线的生成式回答节点只接纳已校验的工具返回证据；避免同时从原生上传文件检索造成过滤旁路。

最终真实政策答案说明终止后30天删除、超过30天需法务书面批准，以及虚构教学规则的边界。这是原生文件知识，不是受控 Azure 搜索结果。

第七步：三个精准检索子问题（优化维度5）

1. Tools → Add a tool → Prompt，名称 RewriteContractQueriesLab04。
2. 粘贴 节点 Prompt，添加 Text 输入 UserQuestion 和 ContractText。
3. UserQuestion 填“检查数据保存、责任限制和跨境条款与教学规则的冲突”，ContractText 使用教学合同。
4. Output format → JSON → Test。结果为恰好三个 {text} 对象，不允许重复、编造数字或生成授权组。

5. Save → Add and configure。真实结果保存在 queries.real.json；完整文字以此文件为准，设计器截图可能横向截断长行。
6. 该 Prompt 为教学合同的三类条款设计；其他合同先解析实际条款类型，再决定三个检索角度，不能忽略其他关键条款。
7. 将每个子问题传给同一权限范围的 SearchLegalKnowledge，合并证据后审核。

本轮云端结果通过 validateQueries，恰好三个不同 {text} 对象；该 Prompt 测试没有查询真实索引。

第八步：上传合同、解析与证据式审计主题

1. 在 Agent Settings → Generative AI 按租户提供的选项启用用户文件输入，Test 上传教学合同。支持格式和渠道以实际 UI 与官方文档为准。

2. 如渠道不支持该格式，通过受控暂存区上传并传文件 ID。文件工具检查访问权、类型、大小、恶意内容及敏感数据，不接受任意外部文件地址。

3. 创建 Topic ReviewContract：取得文件 → 授权检查 → ExtractContractClauses 工具 → 确认合同版本 → 三问题 Prompt → SearchLegalKnowledge → AuditClauses Prompt。

4. 提取结果逐条保存 clauseId、原文、页码或 Markdown 章节。OCR 信息不足则停止或人工补正。

5. AuditClauses 的固定要求：

   只比较提供的合同条款与获批规则。每条输出 clauseId、contractQuote、ruleId、ruleQuote、chunkId、sourceUrl、result、reason、reviewStatus。result 只允许“规则冲突”“符合教学规则”“信息不足”“未覆盖”。缺少合同原文或规则原文不得判定冲突；最终结论交法务。

6. 在流程里逐字验证 contractQuote 属于当前合同，ruleQuote 属于对应 chunk；校验规则范围与访问权限、chunkId 和规则版本。

7. 给无证据条款保留“信息不足/未覆盖”，不能把“没检索到违规”当成“合规”。明确记录所有条款的覆盖情况。

第八步实际复跑：在 Test 添加 data/contract.md（527 bytes）并带审核请求发送，最终回复仍要求合同文本；出现附件不等于提取成功。另开新会话提交完整虚构合同文本，等待最终答案而不是“Processing”占位。

记录：真实附件对话、最终完整文本重试。文本重试识别三条教学规则冲突、第四条未覆盖，并引用 policy.clean.md；但把中文原文译成英文，且未提供有效的 chunkId、引用 URL，因此没有通过逐字双引用、结构化审计协议或用户文件解析验收。回答中“已获批范围”的文字不证明服务端硬过滤生效；未生成报告或执行外部写入。

自定义知识源可选接法

1. Topics → 新主题 → More → Open code editor，按官方结构使用 OnKnowledgeRequested。
2. 调用已认证检索工具或 Agent flow，令其执行过滤、三查询、去重、门控；不要由 YAML 拼接任意用户授权条件。
3. 将结果映射到 System.SearchResults 的 Content、Title、ContentLocation。
4. 系统已有 SearchQuery/KeywordSearchQuery 上下文重写，不等于自动生成了本实验要求的三个子问题。所有自定义知识主题合计最多15片段。

第九步：生成 Excel 审计报告

9.1 离线附件验证

1. 第二步准备脚本已检查配套 人工标注夹具 的合同与规则双引用，产物为 audit.checked.json。

2. 安装本案例 requirements 后运行：

   node lab-04-02/scripts/prepare.mjs
   python lab-04-02/scripts/export_audit.py
   

3. 下载 contract-audit.example.xlsx。Audit 工作表有命名表 AuditRows，Readme 工作表注明“离线教学夹具”与来源。

4. 本样例标注三条规则冲突与一条未覆盖，全部待法务复核。它是人工标注参考，不是模型自动审核成功的证据。

5. 生成器把单元格明确存为文本，避免以 = 开头的内容变成公式；没有计算公式。新增真实结果不能直接用这个只接受离线夹具的导出器冒充生产导出。

9.2 Power Automate 在线输出

本轮边界：没有执行现有审计 worker 或受控检索工具，没有写入在线 Excel 行。实际工具列表显示重写 Prompt，不是完整审计链路成功。SharePoint 元数据、授权检索、文件提取、精确引用和在线 worker 仍是前置条件；不能把离线工作簿当作在线结果。

1. 将教学工作簿作为模板保存到授权报告库；每次审计先复制独立文件，不多人并发写同一模板。
2. 清空新文件 AuditRows 的四条教学记录，保留表头与表结构；更新 Readme 执行性质和真实审计来源。
3. 短时 Agent flow StartContractAudit 验证输入和权限、生成持久 requestId、入队并及时返回 accepted。长审计与工作簿写入由独立 Worker 承担，不能超过同步响应窗口。
4. Worker 对校验后的每条发现使用 Excel Online (Business) → Add a row into a table，选择刚复制的文件和 AuditRows，逐列映射字段；使用串行写入。

5. 将不可信文本按文本写入；若动作会解释公式前缀，用受控 Office Script 按文本格式写入。使用以 =HYPERLINK(...) 开头的测试输入检查客户端没有公式执行。
6. 为每行设置唯一 FindingId 或持久行状态，记录写入进度；超时先核对是否已写入，不盲目重试导致重复记录。
7. 全部写入成功后保存文件 ID 和授权链接，标记 ReadyForLegalReview；部分失败标 PartialFailed 并给出原因，不返回完整成功。
8. 用户下载核对条款数、双引用、规则版本、覆盖率和错误状态。仅通过批准共享链接返回给有权限用户，不公开 SharePoint 整个报告库。

第十步：效果评测与失败演练

在文档规模10/100/500三档保持相同标注题集、模型和条件，逐维修改、记录结果，不能一次全部优化后归因到某一维。

测试案例与指标保存在 evaluation.json，不预填未经测量的准确率。

记录相关块 Recall@5、双引用准确率、未覆盖率、错误拒答与延迟；建议引用准确率≥0.9、越权0次，这些是验收目标不是已测成绩。法务决定最终合规结论。

已保存内容与真实执行范围

脚本共用 Lab 04-01 的检索校验模块，保持两个案例同一过滤与门控规则。两个目录需一起保留。截图来源见 manifest.json。

本轮截图来源区分原生知识、云端 Prompt、实际附件测试及文本补充的缺失审计字段；不声称已测得云端检索准确率或完成在线工作簿验收。

官方参考

• 用户文件输入
• 自定义知识源
• 向量过滤
• Azure AI Search 知识源
• Excel Online Business