Audit Case Rag

核心用法

audit-case-rag 是一套面向商业房地产审计与调查案件的本地优先、事件驱动型RAG工作流。用户需按规范命名案件目录（<项目问题编号>__<标题>），并在内部建立标准化阶段子文件夹（01_policy_basis至09_rectification），随后通过命令行工具完成索引构建与智能检索。

索引阶段：执行 audit_case_rag.py index 扫描案件目录，自动处理PDF/DOCX/PPTX/XLSX等格式，生成 manifest.jsonl 清单及本地持久化索引（joblib格式）。系统推荐搭配LibreOffice实现Office文档的精准页码映射。

查询阶段：执行 audit_case_rag.py query 支持多维度过滤（--case 案件编号、--stage 阶段标签），采用混合检索策略（向量召回+TF-IDF重排序），返回答案时附带可点击的 file://...#page=N 页码级引用，直接满足审计底稿编制、整改闭环跟踪、举报线索调查的举证需求。

显著优点

1. 完全离线：零云端API调用，敏感审计证据全程本地化，规避数据泄露风险
2. 案件化组织：事件驱动架构，强制阶段分层（policy/process/contract/payment等），天然匹配审计作业流程
3. 精准溯源：页码级引用（PDF #page）而非仅文件级，满足审计准则对证据可追溯性的严格要求
4. 格式兼容：原生支持审计场景高频格式（PDF、Word、Excel、PPT），无需预处理转换
5. 轻量部署：Python虚拟环境+单脚本运行，无复杂服务依赖

潜在局限

• 规模限制：设计目标为单案件50-200份文档，超大规模案件（千级文件）性能未经验证
• 中文分词依赖：TF-IDF重排序效果受底层分词器质量影响，专业审计术语可能需自定义词表
• LibreOffice依赖：Office文档页码精准映射需外部LibreOffice进程，Windows/Linux路径配置可能存在兼容性问题
• 无协同机制：纯本地设计，多审计师协作需自行解决索引同步（如NAS/版本控制），无内置权限管理
• 索引冷启动：每次新增文档需重新索引，增量更新机制未明确

适合人群

• 内部审计/监察部门需处理涉密举报线索的调查人员
• 商业地产项目审计团队管理多阶段证据（招采-合同-结算-整改）
• 合规检查场景下需快速定位制度依据与付款凭证的质控岗位
• 对数据主权敏感、拒绝SaaS方案的企业风控部门

常规风险

• 索引数据残留：audit_rag_db/ 及转换后的PDF缓存含案件敏感信息，需严格遵循.gitignore或加密存储
• 路径硬编码风险：Windows/macOS/Linux路径格式差异可能导致file://链接失效
• LibreOffice版本差异：不同版本Office→PDF分页结果可能偏差1-2页，关键证据建议人工复核页码
• 依赖库供应链：虽为本地运行，但requirements.txt中的PyPDF2/docx2pdf等库需关注CVE安全更新
• 证据链完整性：RAG摘要可能遗漏上下文，正式底稿引用时必须核对原始文档，避免"AI幻觉"传导至审计结论

核心用法

audit-case-rag 是一款专为审计与调查场景设计的本地优先、事件驱动型RAG系统。用户需按规范命名案件文件夹（<项目问题编号>__<标题>），并在内部建立标准化的阶段子目录（01_policy_basis制度依据、02_process招采过程、03_contract合同协议、04_settlement_payment结算付款、05_comm沟通记录、06_interviews访谈笔录、07_workpapers审计底稿、09_rectification整改落实）。通过audit_case_rag.py index命令构建持久化本地索引后，即可使用query子命令进行阶段过滤的精准检索，返回结果附带file://...#page=N格式的可点击页级引用，直接支撑工作底稿编制、整改闭环跟踪及举报线索调查。

显著优点

隐私安全极致化：完全本地化架构是该技能最突出的竞争优势。无需任何云端API密钥，所有文档解析、嵌入向量生成、索引构建与检索排序均在用户本地设备完成，从根本上杜绝敏感审计数据外泄风险，天然符合GDPR/CCPA合规要求。

阶段化证据管理：首创"项目-阶段"双层过滤模型，将复杂案件的证据链条按审计业务流程结构化拆解。检索时可精确限定--stage参数（如payment阶段查付款倒挂），避免全库噪音干扰，显著提升取证效率。

页级精确引用：区别于传统RAG的段落级溯源，该技能通过LibreOffice转换+PDF页码解析，实现真正的页级定位。输出的file://链接可直接在PDF阅读器中跳转，满足审计准则对证据出处的严苛要求。

混合检索优化：采用embedding语义召回+TF-IDF重排序的混合策略（alpha可调），兼顾语义理解能力与关键词匹配精度，适应审计文档中大量专业术语与固定表述并存的场景。

潜在缺点与局限性

环境依赖较重：必须预装Python虚拟环境及LibreOffice（soffice需加入PATH），Windows/macOS/Linux各平台配置差异较大，对非技术背景审计人员有一定上手门槛。

格式支持边界：虽然支持PDF/DOCX/PPTX/XLSX等常见办公格式，但复杂排版、扫描件OCR、加密文档等场景可能转换失败或丢失页码信息，需人工预处理。

单案件架构：当前设计为"一案一库"模式，索引文件（.joblib）与案件绑定，不支持跨案件联合检索或历史案件的知识沉淀，大规模重复案件场景下管理成本较高。

无增量更新机制：文档变更后需重新全量索引，缺乏实时或增量更新能力，动态跟踪中的案件需注意版本一致性。

适合的目标群体

• 内部审计/合规团队：处理商业地产、工程建设等领域的专项审计，需快速从海量项目文档中提取制度违规、流程瑕疵证据
• 监察调查人员：负责举报线索核实、责任追溯调查，需要页级精准出处支撑询问笔录与调查报告
• 第三方审计机构：为客户提供现场审计服务时，在客户内网环境部署离线RAG，满足数据不出域要求
• 整改督办岗位：跟踪整改措施落实情况，通过阶段过滤快速定位历史决策依据与当前执行偏差

使用风险与注意事项

性能风险： embedding模型（fastembed）在CPU环境下处理200份以上文档时索引耗时较长，建议配备足够内存（16GB+）或GPU加速。

依赖维护风险：当前未提供版本锁定的requirements.txt，fastembed等库的快速迭代可能导致接口不兼容，建议用户自行锁定版本并定期安全检查。

LibreOffice兼容性：不同版本LibreOffice的PDF转换效果存在差异，建议团队统一版本并在标准化案例中验证页码对齐准确性。

索引存储管理：.joblib索引文件与原始文档分离存储，需建立规范的备份机制，避免索引丢失导致重复劳动。

T3来源审慎原则：作为个人开发者项目，建议首次使用前在隔离环境（虚拟机/容器）中审查代码，确认无恶意行为后再部署生产环境。