fix: bugs-04
This commit is contained in:
66
docs/competition-book/chapters/01-overview.tex
Normal file
66
docs/competition-book/chapters/01-overview.tex
Normal file
@@ -0,0 +1,66 @@
|
||||
\chapter{项目背景与建设意义}
|
||||
|
||||
\section{建设背景}
|
||||
|
||||
近年来,电信网络诈骗案件持续高发,受害人提供的电子支付证据呈现出来源平台多、截图数量大、页面形态杂、内容重复展示频繁等特征。基层派出所民警在制作受害人笔录和核查被骗金额时,往往需要面对微信、支付宝、手机银行、数字钱包等多种支付渠道的账单截图,人工逐张查看、手工登记、交叉比对已成为高频且高耗时工作。
|
||||
|
||||
现有处理方式主要依赖个人经验,存在三个明显短板:一是截图之间缺乏统一结构化表达,难以快速还原完整交易事实;二是同一笔资金在不同页面、不同APP中多次出现,容易导致重复计算或漏算;三是本人账户中转、退款返还、余额充值等复杂情形仅凭单张截图难以准确认定。上述问题直接影响被骗金额核算准确性、笔录质量和案件材料整理效率。
|
||||
|
||||
\section{建设意义}
|
||||
|
||||
本项目聚焦“受害人资金核查”这一基层警务最刚性、最频繁、最易出错的环节,构建面向案件任务目标的多智能体协同认定系统。项目的建设意义主要体现在以下三个方面。
|
||||
|
||||
\subsection{对一线办案的直接支撑}
|
||||
|
||||
系统通过截图自动解析、交易归并、资金路径分析、认定复核、笔录辅助和报告导出,形成完整处理闭环,将原本分散在民警个人经验中的流程规则沉淀为可执行、可复用的数字能力,有助于显著降低基础性整理工作量。
|
||||
|
||||
\subsection{对证据组织方式的升级}
|
||||
|
||||
项目将非结构化截图材料转化为案件级结构化资产,使图片证据不再只是附件,而是能够参与去重、关联、认定和报告生成的可计算对象。由此实现从“材料堆积”到“证据组织”的转变。
|
||||
|
||||
\subsection{对警务智能体应用范式的示范}
|
||||
|
||||
本项目不是简单的OCR工具,也不是单轮问答助手,而是围绕办案目标持续调用识别、规则、推理和复核能力的任务型智能体系统,具有较强的示范意义和可推广价值。
|
||||
|
||||
\section{项目定位}
|
||||
|
||||
本项目定位为面向电信网络诈骗案件受害人资金核查场景的警务专用认定系统,服务于以下典型环节:
|
||||
|
||||
\begin{itemize}
|
||||
\item 受害人报案受理后的证据初整;
|
||||
\item 笔录制作前的交易事实梳理;
|
||||
\item 被骗金额认定与人工复核;
|
||||
\item 笔录内容快速生成与直接插入;
|
||||
\item 资金流向分析与案件汇报;
|
||||
\item 报告导出与后续材料复用。
|
||||
\end{itemize}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{项目定位与警务价值对应表}
|
||||
\begin{tabularx}{\textwidth}{p{0.19\textwidth}p{0.27\textwidth}Y}
|
||||
\toprule
|
||||
定位维度 & 具体对象 & 直接价值 \\
|
||||
\midrule
|
||||
使用对象 & 基层派出所民警、反诈岗位民警 & 面向真实办案过程,降低重复性人工整理负担 \\
|
||||
核心任务 & 多APP截图证据解析与被骗金额认定 & 统一证据口径,提高金额核算效率与一致性 \\
|
||||
输出形态 & 交易明细、认定结果、路径图、问询建议、笔录内容、报告 & 既能辅助分析,也能支撑后续文书与汇报 \\
|
||||
应用方式 & 人机协同复核 & 兼顾效率、可解释性与审慎性 \\
|
||||
推广范围 & 电诈、涉网资金案件、电子支付证据归集场景 & 具备跨场景复用空间 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\placeholderwidefigure{建议放置“项目总体价值示意图”或“传统人工处理与系统辅助处理对比流程图”。正式提交时,可用一页图展示民警传统处理链路与系统处理链路的差异。}
|
||||
|
||||
\section{建设目标}
|
||||
|
||||
项目的总体目标可以概括为“让碎片化截图证据自动转化为可认定、可复核、可办案的资金事实”。围绕该目标,系统设定以下建设目标:
|
||||
|
||||
\begin{enumerate}
|
||||
\item 实现对多源账单截图的统一识别与字段抽取;
|
||||
\item 实现跨平台交易归并、重复交易识别与本人账户中转识别;
|
||||
\item 实现面向办案语境的被骗金额分层认定与理由生成;
|
||||
\item 实现人工复核、笔录辅助、问询提示和证据化报告输出闭环;
|
||||
\item 为后续规模化推广奠定标准化流程和数据基础。
|
||||
\end{enumerate}
|
||||
88
docs/competition-book/chapters/02-demand.tex
Normal file
88
docs/competition-book/chapters/02-demand.tex
Normal file
@@ -0,0 +1,88 @@
|
||||
\chapter{场景痛点与需求分析}
|
||||
|
||||
\section{业务场景还原}
|
||||
|
||||
基层民警在接报电信网络诈骗案件时,受害人通常会同时提供多个APP内的账单截图,包括支付成功页、账单详情页、银行卡流水页、聊天转账页、充值记录页等。不同截图之间既存在互补信息,也存在大量重复展示。民警需要在有限时间内完成以下工作:
|
||||
|
||||
\begin{itemize}
|
||||
\item 判断截图属于哪个APP、哪个页面类型;
|
||||
\item 提取金额、时间、对手方、订单号、账户尾号等关键信息;
|
||||
\item 区分真实对外支付、本人账户中转、退款返还等不同类型交易;
|
||||
\item 对同一笔交易进行归并,防止重复累计;
|
||||
\item 生成可用于笔录、汇报和报告的结果材料。
|
||||
\end{itemize}
|
||||
|
||||
\placeholderwidefigure{建议放置“受害人提供多APP截图材料”的拼图,占位图可由微信、支付宝、银行APP截图样例构成。正式提交时可替换为脱敏后的真实截图。}
|
||||
|
||||
\section{现有处理方式存在的问题}
|
||||
|
||||
\subsection{问题一:截图材料分散,人工整理耗时长}
|
||||
|
||||
单案少则十余张截图,多则数十乃至上百张。人工逐张阅读与登记既耗费时间,也会影响后续问询节奏。
|
||||
|
||||
\subsection{问题二:同一交易多次展示,重复计算风险高}
|
||||
|
||||
同一笔交易可能同时出现在支付成功页、账单详情页、交易记录页和银行流水页。仅以人工方式排重,极易因时间、金额、订单号对照不充分导致重复累计。
|
||||
|
||||
\subsection{问题三:中转与对外支付混杂,认定难度大}
|
||||
|
||||
受害人往往会先从银行卡向微信或支付宝充值,再通过余额转出;也可能先转入再转出,形成本人账户内部中转。若缺乏跨页面、跨平台关联分析,仅靠单张截图难以准确判断是否应计入被骗金额。
|
||||
|
||||
\subsection{问题四:结果不可复用,后续仍需重复整理}
|
||||
|
||||
人工处理通常只能形成零散记录,缺乏结构化交易清单、证据索引和认定说明,导致汇报、移送和复核阶段仍需重复整理。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{传统处理方式主要问题分析表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.23\textwidth}Y}
|
||||
\toprule
|
||||
问题类别 & 具体表现 & 对办案造成的影响 \\
|
||||
\midrule
|
||||
材料碎片化 & 截图来源多、页型多、命名混乱 & 前期梳理时间长,信息容易遗漏 \\
|
||||
证据重复化 & 同笔交易在多页面反复出现 & 被骗金额重复计算风险高 \\
|
||||
关系复杂化 & 中转、退款、充值、外部支付交叉出现 & 认定标准不统一,依赖个人经验 \\
|
||||
输出非结构化 & 结果停留在手工记录与零散截图层面 & 后续复核、汇报、移送无法直接复用 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{核心需求分析}
|
||||
|
||||
围绕上述问题,本项目提出以下核心需求。
|
||||
|
||||
\subsection{需求一:统一识别与结构化抽取}
|
||||
|
||||
系统需要对不同APP、不同页面的截图进行页面分类和字段抽取,至少识别交易时间、金额、交易方向、对手方、本人账户尾号、订单号和备注信息。
|
||||
|
||||
\subsection{需求二:跨平台归并与资金链恢复}
|
||||
|
||||
系统需要能够将多平台截图中的同一笔交易关联起来,进行去重归并,并进一步识别本人账户内部中转关系,恢复对外支付链条。
|
||||
|
||||
\subsection{需求三:面向办案的认定结果输出}
|
||||
|
||||
系统不能只输出“识别结果”,还需要结合规则和上下文给出“是否计入被骗金额”的分层认定、认定理由和排除说明,以便民警复核。
|
||||
|
||||
\subsection{需求四:形成可复核、可汇报、可导出的成果}
|
||||
|
||||
系统输出应同时兼顾分析与办案文书需要,形成清单、图表、摘要和证据索引,支持后续报告导出。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{系统建设需求分解表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.28\textwidth}Y}
|
||||
\toprule
|
||||
需求层级 & 具体要求 & 对应建设方向 \\
|
||||
\midrule
|
||||
感知层需求 & 多APP截图自动识别、字段抽取、页型判断 & OCR识别与多模态解析 \\
|
||||
关联层需求 & 订单号、金额、时间窗口、账户尾号综合归并 & 去重匹配与跨平台关联 \\
|
||||
推理层需求 & 中转识别、分层认定、理由生成、问询提示 & 规则引擎与智能推理 \\
|
||||
行动层需求 & 复核、报告、图表、证据索引输出 & 人机协同与文书化输出 \\
|
||||
管理层需求 & 案件化组织、结果回写、重复分析可复用 & 案件级数据沉淀与闭环流程 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{项目书写作边界说明}
|
||||
|
||||
本项目书以当前系统已具备的功能链路为依据,聚焦“案件管理、截图识别、交易归并、资金分析、认定复核、报告导出”六类核心能力展开说明。对后续可拓展能力,如更复杂的模型训练、跨案件比对或更广泛的警种复用,将仅作方向性展望,不将其写为既成事实。
|
||||
89
docs/competition-book/chapters/03-solution.tex
Normal file
89
docs/competition-book/chapters/03-solution.tex
Normal file
@@ -0,0 +1,89 @@
|
||||
\chapter{总体方案与技术路线}
|
||||
|
||||
\section{总体设计原则}
|
||||
|
||||
为确保项目既能解决实战问题,又具备可解释、可复核和可落地特征,系统总体设计遵循以下原则:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{目标导向原则}:围绕“认定被骗金额并形成证据化输出”设计流程,而非停留在单点识别。
|
||||
\item \textbf{任务分工原则}:将复杂问题拆分为截图解析、交易归并、路径分析、金额认定、问询辅助、报告输出等多个能力单元。
|
||||
\item \textbf{规则约束原则}:在关键认定环节引入明确规则,避免完全黑盒化输出。
|
||||
\item \textbf{人机协同原则}:系统先给出候选结论与理由,民警完成最终审核确认。
|
||||
\item \textbf{结果复用原则}:所有分析结果以案件为单元沉淀,支持复核、导出和再次分析。
|
||||
\end{enumerate}
|
||||
|
||||
\section{总体架构}
|
||||
|
||||
从整体上看,系统采用“前端工作台 + 后端服务编排 + 外部AI能力 + 数据存储”的分层架构。前端负责案件录入、截图上传、过程展示、人工复核与报告下载;后端负责业务流程编排、规则执行、数据治理和报告生成;外部AI能力负责截图视觉识别和文本推理;数据库与队列负责持久化与异步任务调度。
|
||||
|
||||
\placeholderwidefigure{建议放置“系统总体架构图”。图中应包括:案件管理前端、截图上传、OCR识别、字段解析、去重归并、中转识别、资金分析、认定复核、报告导出、数据库、队列与外部模型服务。}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{总体架构层次说明表}
|
||||
\begin{tabularx}{\textwidth}{p{0.16\textwidth}p{0.22\textwidth}Y}
|
||||
\toprule
|
||||
架构层次 & 主要组成 & 作用说明 \\
|
||||
\midrule
|
||||
展示层 & 案件页、工作台、截图页、交易页、分析页、复核页、报告页 & 承载办案过程中的录入、查看、复核与导出 \\
|
||||
业务层 & 案件服务、图片服务、分析流水线、认定服务、报告服务 & 完成案件级处理逻辑编排 \\
|
||||
规则层 & 去重规则、中转规则、认定规则 & 对关键判断建立可解释约束 \\
|
||||
智能层 & OCR/视觉模型、文本推理模型 & 负责截图理解、理由优化与问询建议生成 \\
|
||||
数据层 & PostgreSQL、Redis、文件存储 & 支撑数据持久化、任务队列与文件管理 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{多智能体协同分工}
|
||||
|
||||
虽然当前系统工程实现体现为模块化服务流水线,但从任务组织视角,可将其归纳为面向办案目标的多智能体协同体系。不同智能体各自承担一段清晰职责,并通过案件上下文串联起来。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{多智能体协同分工表}
|
||||
\begin{tabularx}{\textwidth}{p{0.19\textwidth}p{0.27\textwidth}Y}
|
||||
\toprule
|
||||
智能体角色 & 主要输入 & 主要输出 \\
|
||||
\midrule
|
||||
案件受理智能体 & 案件编号、受害人信息、截图材料 & 案件级上下文与处理任务 \\
|
||||
截图解析智能体 & 原始截图 & 页面类型、关键字段、候选交易记录 \\
|
||||
归并关联智能体 & 候选交易记录、订单号、时间、金额等特征 & 去重后的统一交易视图 \\
|
||||
资金分析智能体 & 去重交易、账户关系 & 资金流图、时间轴、收款方聚合结果 \\
|
||||
金额认定智能体 & 有效交易、规则结果、上下文线索 & 认定金额、置信等级、认定理由 \\
|
||||
问询辅助智能体 & 待复核记录、认定摘要 & 笔录追问建议 \\
|
||||
证据输出智能体 & 案件摘要、交易清单、图表数据 & Excel/PDF 等导出材料 \\
|
||||
人工复核代理 & 系统输出结果 & 最终确认结果与审计痕迹 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{技术路线}
|
||||
|
||||
系统采取“视觉识别 + 规则校验 + 智能推理 + 人工复核”的混合式技术路线,其核心不是让单一模型直接给出最终结果,而是让各类能力按办案流程分工协作。
|
||||
|
||||
\begin{enumerate}
|
||||
\item 通过视觉识别能力完成截图页型判断和关键字段抽取;
|
||||
\item 通过解析逻辑将抽取结果转换为统一交易记录;
|
||||
\item 通过规则引擎完成去重判断和中转识别;
|
||||
\item 通过认定逻辑对交易进行高、中、低置信分层;
|
||||
\item 通过文本推理能力优化理由表述并生成问询建议;
|
||||
\item 通过人工复核确认最终结果并导出报告。
|
||||
\end{enumerate}
|
||||
|
||||
\placeholderwidefigure{建议放置“技术路线流程图”,展示从截图输入到报告输出的完整链路。}
|
||||
|
||||
\section{流程闭环}
|
||||
|
||||
系统围绕案件形成如下闭环流程:
|
||||
|
||||
\begin{enumerate}
|
||||
\item 民警创建案件并批量上传截图;
|
||||
\item 系统发起OCR识别,完成字段抽取;
|
||||
\item 系统将候选记录进行归并与去重;
|
||||
\item 系统识别本人账户中转并构建资金流图;
|
||||
\item 系统形成被骗金额认定清单与问询建议;
|
||||
\item 民警在复核页面确认、排除或补充;
|
||||
\item 系统导出结构化报告,形成可复用证据底稿。
|
||||
\end{enumerate}
|
||||
|
||||
\note{正式提交时,建议将本章架构图与流程图制作成高信息密度的一页整图,评审可在极短时间内把握项目全貌。}
|
||||
140
docs/competition-book/chapters/04-mechanism.tex
Normal file
140
docs/competition-book/chapters/04-mechanism.tex
Normal file
@@ -0,0 +1,140 @@
|
||||
\chapter{核心能力与关键机制}
|
||||
|
||||
\section{多APP截图识别与字段抽取}
|
||||
|
||||
系统首先面向微信、支付宝、银行APP、数字钱包等不同来源截图进行页面识别与字段抽取,重点获取交易时间、金额、收付款方向、对手方名称、本人账户尾号、订单号、备注等结构化要素。该过程的目的不只是“把图上的字识别出来”,而是为后续跨平台关联和金额认定提供统一数据底座。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{截图识别关键字段表}
|
||||
\begin{tabularx}{\textwidth}{p{0.2\textwidth}p{0.22\textwidth}Y}
|
||||
\toprule
|
||||
字段名称 & 典型来源位置 & 主要用途 \\
|
||||
\midrule
|
||||
交易时间 & 账单详情、流水页、支付结果页 & 交易排序、时间窗归并、路径恢复 \\
|
||||
交易金额 & 支付结果页、交易明细页 & 金额认定与汇总统计 \\
|
||||
交易方向 & 转出、转入、收入、支出等标识 & 区分被骗支付、中转与返还 \\
|
||||
对手方信息 & 收款方、商户名、账户名 & 收款方聚合与风险识别 \\
|
||||
本人账户标识 & 银行尾号、支付账户标识 & 中转识别与账户关系恢复 \\
|
||||
订单号/商户单号 & 详情页、通知页 & 重复展示识别与证据关联 \\
|
||||
备注信息 & 交易说明、附言、商品名 & 风险关键词识别与认定辅助 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\placeholderwidefigure{建议放置“多APP截图识别示意图”,按“原始截图 - 抽取字段 - 结构化结果”三栏展示。}
|
||||
|
||||
\section{关键词回溯驱动的自我完善机制}
|
||||
|
||||
传统OCR流程往往在第一次页面分类后即固定结果,但在真实办案场景中,截图模糊、裁切不完整、平台UI相似等情况都可能导致初始识别误差。本项目引入“证据识别后关键词回溯”的优化机制,即在完成一轮交易字段抽取和部分认定后,利用高置信证据重新回看前序页面类型判断,对可能误判的截图进行二次校正。
|
||||
|
||||
该机制的基本思路如下:
|
||||
|
||||
\begin{enumerate}
|
||||
\item 首次识别时完成页面分类与字段抽取;
|
||||
\item 在归并、认定过程中收集高置信字段和高价值关键词;
|
||||
\item 将“支付成功”“账单详情”“订单号”“退款”“充值”“银行卡”等关键词回溯到原始截图分类判断中;
|
||||
\item 若后验信息与原始页型不一致,则触发页面类型再验证;
|
||||
\item 将修正后的结果重新参与后续归并和认定。
|
||||
\end{enumerate}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{关键词回溯优化机制说明表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.25\textwidth}Y}
|
||||
\toprule
|
||||
回溯维度 & 典型信号 & 优化作用 \\
|
||||
\midrule
|
||||
行为关键词 & 转账、支付、收款、充值、退款 & 修正交易性质判断 \\
|
||||
页面结构词 & 账单详情、交易记录、支付成功、到账通知 & 修正页面类型识别 \\
|
||||
证据字段词 & 订单号、商户单号、收款方、尾号 & 增强截图与交易的绑定关系 \\
|
||||
认定结果信号 & 对外支付证据、中转凭证、待复核记录 & 用后验高置信结果反向约束前序识别 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
这一机制体现了项目的自我完善特征:系统不是一次识别后静态输出,而是在任务执行过程中利用中间结果持续修正前序判断,使账单类型识别更贴近真实办案需求。
|
||||
|
||||
\section{跨平台交易归并与去重}
|
||||
|
||||
同一笔交易可能在多个APP和多个页面中反复出现。系统围绕订单号、金额、时间窗口、对手方名称、账户尾号等线索进行综合归并,在保证召回率的同时降低重复累计风险。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{交易归并与去重规则表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.28\textwidth}Y}
|
||||
\toprule
|
||||
规则维度 & 判断依据 & 目的 \\
|
||||
\midrule
|
||||
标识一致性 & 订单号、商户单号一致 & 直接识别同一交易重复展示 \\
|
||||
金额一致性 & 金额完全一致或处于可接受误差范围 & 辅助无订单号场景下的归并判断 \\
|
||||
时间窗口 & 交易时间接近 & 缩小候选匹配范围,提升准确率 \\
|
||||
对手方相似性 & 收款方名称或账号高度相似 & 识别跨平台展示的同一对手方 \\
|
||||
账户特征 & 本人账户尾号、支付渠道一致 & 提升去重与中转识别精度 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\placeholderwidefigure{建议放置“交易归并前后对比图”,展示同一笔转账在多个截图中重复出现,系统归并后只保留一条有效记录。}
|
||||
|
||||
\section{本人账户中转识别}
|
||||
|
||||
本人账户中转识别是本项目区别于普通账单OCR工具的关键设计之一。系统通过对手方信息、备注关键词、支付平台特征及交易方向判断,识别受害人账户之间的内部流转行为,避免将内部资金搬移误计为被骗金额。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{本人账户中转识别逻辑表}
|
||||
\begin{tabularx}{\textwidth}{p{0.17\textwidth}p{0.25\textwidth}Y}
|
||||
\toprule
|
||||
判断规则 & 典型特征 & 处理方式 \\
|
||||
\midrule
|
||||
本人关键词命中 & 本人、自己、余额、充值、提现等字样 & 标记为中转候选 \\
|
||||
平台间内部流转 & 银行卡转入微信、支付宝充值等 & 识别为本人账户内部转移 \\
|
||||
已知账户匹配 & 与已知本人账户标识相匹配 & 不直接计入被骗金额 \\
|
||||
方向辅助判断 & 转出后紧接转入同类账户 & 作为路径恢复的重要线索 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\placeholderwidefigure{建议放置“本人账户中转示意图”,展示“银行卡→支付账户→外部收款方”的资金路径,并标记哪一段属于中转、哪一段属于实际对外支付。}
|
||||
|
||||
\section{被骗金额分层认定}
|
||||
|
||||
系统不直接给出不可质疑的“唯一金额结论”,而是将交易分为高、中、低置信三类,以适应警务场景对审慎性和可复核性的要求。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{被骗金额分层认定表}
|
||||
\begin{tabularx}{\textwidth}{p{0.16\textwidth}p{0.22\textwidth}Y}
|
||||
\toprule
|
||||
置信等级 & 典型条件 & 处理建议 \\
|
||||
\midrule
|
||||
高置信 & 对外支付明确、无重复、证据链完整 & 可优先计入被骗金额 \\
|
||||
中置信 & 证据不完整或背景信息不足 & 提示民警补充问询后确认 \\
|
||||
低置信 & 疑似重复、退款、中转或证据不足 & 暂不计入,待后续核实 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
系统同时为每笔交易输出认定理由和排除说明,使结果具备可解释性、可汇报性和可复核性。
|
||||
|
||||
\section{笔录辅助生成、问询建议与证据化输出}
|
||||
|
||||
在识别和认定基础上,系统进一步根据待复核交易、中置信记录和案件交易摘要生成笔录辅助内容。该功能嵌入认定复核页,在民警完成逐笔确认或排除后,可自动汇总关键信息,生成适合直接插入受害人笔录的结构化描述,如转账时间、金额、支付渠道、收款对象、诱导背景和需进一步核实的问题点,从而减少重复输入和整理负担。
|
||||
|
||||
除笔录内容外,系统还会根据待复核交易生成笔录辅助问询建议,如是否还有其他支付平台、是否存在退款返还、是否有未提供截图的记录等。最终输出包括交易明细、认定结果、笔录内容、资金流图、时间轴、收款方聚合和导出报告,从而实现从截图材料到办案结果的闭环转换。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{认定复核页笔录功能说明表}
|
||||
\begin{tabularx}{\textwidth}{p{0.19\textwidth}p{0.24\textwidth}Y}
|
||||
\toprule
|
||||
功能环节 & 主要内容 & 实战价值 \\
|
||||
\midrule
|
||||
内容汇总 & 自动汇总已确认交易的时间、金额、渠道和对象 & 减少民警重复摘录工作 \\
|
||||
语句生成 & 形成适合笔录使用的规范化描述文本 & 提升笔录书写效率和一致性 \\
|
||||
直接插入 & 可直接复制或插入到笔录文本中 & 缩短从复核到成文的时间 \\
|
||||
问题提示 & 标识仍需补问或核实的交易点位 & 辅助完善证据链与询问重点 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
117
docs/competition-book/chapters/05-implementation.tex
Normal file
117
docs/competition-book/chapters/05-implementation.tex
Normal file
@@ -0,0 +1,117 @@
|
||||
\chapter{系统实现与界面展示}
|
||||
|
||||
\section{系统实现概况}
|
||||
|
||||
当前系统已经形成较完整的前后端闭环能力。前端采用 React 18、TypeScript、Ant Design 与 ECharts 构建案件管理和可视化界面;后端采用 FastAPI、SQLAlchemy、PostgreSQL 和 Redis 组织业务服务与异步任务;外部AI接口承担截图视觉识别、理由生成和笔录辅助文本生成等任务。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{系统技术实现表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.24\textwidth}Y}
|
||||
\toprule
|
||||
技术层面 & 选型情况 & 作用说明 \\
|
||||
\midrule
|
||||
前端展示 & React 18 + TypeScript + Ant Design + ECharts & 实现工作台、图表分析、复核与报告导出交互 \\
|
||||
后端服务 & FastAPI + SQLAlchemy & 提供案件、截图、分析、认定、报告等API能力 \\
|
||||
数据存储 & PostgreSQL & 保存案件、交易、认定、报告等核心数据 \\
|
||||
任务调度 & Celery + Redis & 支撑OCR和分析任务异步执行 \\
|
||||
智能能力 & 视觉模型接口、文本模型接口 & 支撑截图识别、理由优化和问询生成 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{前端功能页面}
|
||||
|
||||
系统前端围绕办案流程设计了案件列表、工作台、截图页、交易页、分析页、复核页和报告页等核心页面,能够覆盖从证据上传到结果导出的完整链路。其中,认定复核页新增笔录功能,可在民警完成复核确认后自动生成可直接插入笔录的内容摘要。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{前端核心页面说明表}
|
||||
\begin{tabularx}{\textwidth}{p{0.2\textwidth}p{0.23\textwidth}Y}
|
||||
\toprule
|
||||
页面名称 & 主要功能 & 办案价值 \\
|
||||
\midrule
|
||||
案件列表页 & 创建、查看和管理案件 & 统一案件入口,形成案件级组织 \\
|
||||
工作台页 & 上传截图、查看处理进度、快速发起OCR和分析 & 串联完整工作流程 \\
|
||||
截图页 & 查看截图、识别状态与提取结果 & 便于证据逐张核验 \\
|
||||
交易页 & 查看提取交易、去重状态、中转标记 & 便于排查重复与异常记录 \\
|
||||
分析页 & 资金流图、时间轴、收款方聚合 & 快速把握案件整体资金结构 \\
|
||||
复核页 & 审核认定结果、确认或排除记录、生成笔录内容 & 落实人机协同闭环并提升笔录效率 \\
|
||||
报告页 & 生成和下载Excel/PDF报告 & 支撑汇报、归档和复用 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\placeholderwidefigure{建议放置“工作台界面截图”,重点体现上传截图、OCR状态、交易数量、待复核数量等关键指标。}
|
||||
|
||||
\placeholderwidefigure{建议放置“分析页界面截图”,突出资金流转关系图、交易时间轴和收款方聚合三个区域。}
|
||||
|
||||
\placeholderwidefigure{建议放置“认定复核页界面截图”,突出逐笔复核区域、笔录内容生成区域和可直接插入笔录的功能入口。}
|
||||
|
||||
\placeholderwidefigure{建议放置“报告页界面截图”,展示导出格式选择、报告内容选择、历史报告列表等区域。}
|
||||
|
||||
\section{后端接口与服务实现}
|
||||
|
||||
后端按案件管理、截图管理、分析任务、交易管理、认定复核、笔录辅助、报告导出等能力拆分接口,接口组织结构与办案流程高度对应,便于前后端协同和后续系统集成。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{后端主要接口表}
|
||||
\begin{tabularx}{\textwidth}{p{0.32\textwidth}p{0.12\textwidth}Y}
|
||||
\toprule
|
||||
接口路径 & 方法 & 功能说明 \\
|
||||
\midrule
|
||||
/api/v1/cases & GET/POST & 案件列表查询与案件创建 \\
|
||||
/api/v1/cases/\{id\} & GET/PATCH & 案件详情查询与更新 \\
|
||||
/api/v1/cases/\{id\}/images & GET/POST & 案件截图列表与批量上传 \\
|
||||
/api/v1/images/\{id\} & GET & 截图详情及识别结果查看 \\
|
||||
/api/v1/cases/\{id\}/analyze & POST & 触发案件分析任务 \\
|
||||
/api/v1/cases/\{id\}/transactions & GET & 交易列表查看 \\
|
||||
/api/v1/cases/\{id\}/flows & GET & 资金流图数据获取 \\
|
||||
/api/v1/cases/\{id\}/assessments & GET & 认定结果列表获取 \\
|
||||
/api/v1/assessments/\{id\}/review & POST & 人工复核提交 \\
|
||||
/api/v1/cases/\{id\}/inquiry-suggestions & GET & 获取笔录问询建议 \\
|
||||
/api/v1/cases/\{id\}/reports & GET/POST & 报告列表获取与生成 \\
|
||||
/api/v1/reports/\{id\}/download & GET & 下载生成后的报告文件 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{处理链路实现}
|
||||
|
||||
系统分析链路采用按案件执行的同步或异步流水线模式。典型处理顺序为:先完成交易匹配与去重,再进行金额认定,最后回写案件总额并进入待复核状态。该设计兼顾了逻辑清晰性和工程可落地性。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{案件分析链路实现表}
|
||||
\begin{tabularx}{\textwidth}{p{0.16\textwidth}p{0.22\textwidth}Y}
|
||||
\toprule
|
||||
处理阶段 & 主要动作 & 结果输出 \\
|
||||
\midrule
|
||||
阶段一 & 读取案件与截图上下文 & 初始化分析任务 \\
|
||||
阶段二 & 执行交易匹配、去重与中转识别 & 形成有效交易集合 \\
|
||||
阶段三 & 对有效交易执行金额认定与理由生成 & 形成认定结果清单 \\
|
||||
阶段四 & 回写案件总额并切换案件状态 & 进入人工复核阶段 \\
|
||||
阶段五 & 生成笔录内容、问询建议与导出报告 & 形成可办案输出材料 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{部署与演示方式}
|
||||
|
||||
项目支持本地开发部署和基础设施一键启动,便于完成比赛演示。当前设计同时支持在后端不可用时以前端内置数据进行演示,能够保证展示过程的稳定性与连续性。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{部署与演示方式表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.22\textwidth}Y}
|
||||
\toprule
|
||||
场景 & 主要方式 & 适用说明 \\
|
||||
\midrule
|
||||
本地联调 & 前端 + 后端 + PostgreSQL + Redis & 适合完整演示业务闭环 \\
|
||||
纯前端演示 & 前端使用内置Mock数据 & 适合网络环境受限时的稳定展示 \\
|
||||
AI接口配置 & OCR与LLM接口可分别配置 & 适合按需接入不同模型能力 \\
|
||||
扩展部署 & 可进一步迁移至专网或本地化环境 & 适合警务场景安全要求 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
72
docs/competition-book/chapters/06-innovation.tex
Normal file
72
docs/competition-book/chapters/06-innovation.tex
Normal file
@@ -0,0 +1,72 @@
|
||||
\chapter{创新点与方案优势}
|
||||
|
||||
\section{创新点提炼}
|
||||
|
||||
本项目的创新不在于单纯引入大模型,而在于将多源截图证据处理、规则认定和人机协同复核整合为面向办案任务的智能体系统。结合当前实现和警务场景需求,可归纳出以下创新点。
|
||||
|
||||
\subsection{场景创新}
|
||||
|
||||
项目聚焦电信网络诈骗案件受害人资金核查这一基层高频、刚需、长期依赖人工经验的环节,直接面向民警真实工作负载,问题选择具有很强的实战导向。
|
||||
|
||||
\subsection{方法创新}
|
||||
|
||||
项目采用“多智能体协同 + 规则约束 + 人工复核”的混合范式,避免了纯规则方式过于僵化、纯大模型方式难以解释的问题,使系统既具灵活性,又具可控性。
|
||||
|
||||
\subsection{机制创新}
|
||||
|
||||
项目引入证据识别后的关键词回溯优化机制,能够利用后续高置信识别结果反向修正账单页面类型判断,体现了智能体在任务执行过程中的自我校正和自我完善能力。
|
||||
|
||||
\subsection{输出创新}
|
||||
|
||||
项目最终输出的不只是识别结果,而是交易清单、认定结果、路径图、问询建议和导出报告等多层成果,形成“识别即治理、分析即成材”的证据化输出模式。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{项目创新点汇总表}
|
||||
\begin{tabularx}{\textwidth}{p{0.18\textwidth}p{0.23\textwidth}Y}
|
||||
\toprule
|
||||
创新类别 & 创新内容 & 体现方式 \\
|
||||
\midrule
|
||||
场景创新 & 聚焦基层资金核查刚需场景 & 解决民警实际高频痛点 \\
|
||||
方法创新 & 智能体、规则和人工复核融合 & 兼顾灵活性、可控性与解释性 \\
|
||||
机制创新 & 关键词回溯驱动的自我完善闭环 & 优化页面类型识别准确率 \\
|
||||
输出创新 & 从截图到报告的证据化输出 & 支撑复核、汇报与后续复用 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{与传统方式对比优势}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{与传统人工处理方式对比表}
|
||||
\begin{tabularx}{\textwidth}{p{0.2\textwidth}p{0.23\textwidth}Y}
|
||||
\toprule
|
||||
对比维度 & 传统人工方式 & 本项目方式 \\
|
||||
\midrule
|
||||
材料处理 & 逐张阅读、手工登记 & 批量上传、自动识别、统一结构化 \\
|
||||
重复控制 & 靠人工比对金额与时间 & 订单号、金额、时间窗等多特征归并 \\
|
||||
中转识别 & 依赖个人经验判断 & 规则化识别与路径分析结合 \\
|
||||
金额认定 & 结论易受个体经验影响 & 分层认定并提供理由说明 \\
|
||||
结果复核 & 二次整理成本高 & 复核页面直接确认与修正 \\
|
||||
输出能力 & 多为零散记录与截图附件 & 形成图、表、文一体的证据化报告 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{与单点OCR工具对比优势}
|
||||
|
||||
与单点OCR工具相比,本项目的关键差异在于目标层级不同。单点OCR关注“从图片读出文字”,而本项目关注“围绕案件任务还原交易事实并形成可复核结论”。因此,它在以下方面具有明显优势:
|
||||
|
||||
\begin{itemize}
|
||||
\item 从页面识别升级到案件级证据关联;
|
||||
\item 从文字抽取升级到交易归并与路径恢复;
|
||||
\item 从单次识别升级到可回溯、可修正的闭环处理;
|
||||
\item 从结果输出升级到办案材料生成。
|
||||
\end{itemize}
|
||||
|
||||
\placeholderwidefigure{建议放置“传统人工处理、普通OCR工具、本项目系统”三者对比示意图,适合作为答辩中最直观的一页。}
|
||||
|
||||
\section{方案优势总结}
|
||||
|
||||
综合来看,本项目的核心优势可概括为四点:第一,问题切口小而刚需强,容易在比赛中形成明确价值判断;第二,技术路径稳妥,兼顾智能性与可控性;第三,输出结果可解释、可复核、可追溯;第四,具备向更多涉网资金案件场景推广的现实基础。
|
||||
77
docs/competition-book/chapters/07-application.tex
Normal file
77
docs/competition-book/chapters/07-application.tex
Normal file
@@ -0,0 +1,77 @@
|
||||
\chapter{应用成效与推广前景}
|
||||
|
||||
\section{应用成效说明}
|
||||
|
||||
本项目面向真实办案流程设计,其价值不只体现在“能识别截图”,更体现在“能把截图整理成可认定的案件结果”。结合当前系统能力,项目的应用成效可从效率、质量和管理三个维度进行评估。
|
||||
|
||||
\subsection{效率提升}
|
||||
|
||||
在传统模式下,民警需要完成截图整理、重复排查、金额核算、笔录补问、笔录成文和结果汇总等多项重复劳动。系统上线后,这些工作由人工全流程串行处理,转变为“系统先处理、民警再复核”的方式,尤其是认定复核页新增的笔录功能,可将已确认交易自动汇总为可直接插入笔录的内容,预计可显著提升案件初整、金额核算和笔录制作效率。
|
||||
|
||||
\subsection{质量提升}
|
||||
|
||||
系统通过统一字段抽取、跨平台归并、中转识别和分层认定,能够降低重复计算、漏算和误算风险,减少不同民警之间因个人经验差异带来的认定口径不一致问题。
|
||||
|
||||
\subsection{复用提升}
|
||||
|
||||
系统输出结构化交易清单、证据索引、路径图、笔录内容和导出报告后,后续汇报、移送、笔录制作和归档环节可直接复用处理结果,减少重复劳动。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{应用成效示例表(正式提交时替换为实测数据)}
|
||||
\begin{tabularx}{\textwidth}{p{0.26\textwidth}p{0.2\textwidth}p{0.2\textwidth}Y}
|
||||
\toprule
|
||||
指标项 & 传统方式 & 系统辅助方式 & 备注说明 \\
|
||||
\midrule
|
||||
单案截图整理时长 & 【示例:90分钟】 & 【示例:25分钟】 & 以典型案件为样本测算 \\
|
||||
被骗金额核算时长 & 【示例:60分钟】 & 【示例:15分钟】 & 含排重和中转识别 \\
|
||||
重复计算发生率 & 【示例:较高】 & 【示例:显著下降】 & 可用抽样复核统计 \\
|
||||
结果复核准备时长 & 【示例:30分钟】 & 【示例:10分钟】 & 依赖结构化清单与理由输出 \\
|
||||
笔录成文时长 & 【示例:45分钟】 & 【示例:12分钟】 & 依赖复核页笔录功能直接生成内容 \\
|
||||
报告整理时长 & 【示例:40分钟】 & 【示例:5分钟】 & 由系统导出结果替代人工汇总 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{答辩展示建议}
|
||||
|
||||
为了增强比赛展示效果,建议答辩环节围绕“问题切入、流程演示、亮点提炼、成效说明”四步展开。
|
||||
|
||||
\begin{enumerate}
|
||||
\item 先用一页讲清基层民警在大量截图整理中的痛点;
|
||||
\item 再演示完整工作闭环:上传截图、OCR识别、交易归并、资金分析、认定复核、笔录生成、报告导出;
|
||||
\item 接着突出四个亮点:跨平台去重、中转识别、关键词回溯自我完善、笔录内容直接插入;
|
||||
\item 最后用图表说明效率提升和推广价值。
|
||||
\end{enumerate}
|
||||
|
||||
\placeholderwidefigure{建议放置“答辩演示链路图”或“演示截图拼图”,作为现场展示的核心大图。}
|
||||
|
||||
\section{推广前景}
|
||||
|
||||
本项目的处理框架并不限于电诈受害人资金核查,还可在以下场景中复制推广:
|
||||
|
||||
\begin{itemize}
|
||||
\item 帮助信息网络犯罪活动案件中的资金梳理;
|
||||
\item 非法集资、网络赌博等涉网案件的电子支付证据分析;
|
||||
\item 行政案件中多源支付凭证的整理与核验;
|
||||
\item 其他需要从多截图材料中恢复资金事实的场景。
|
||||
\end{itemize}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{项目推广价值分析表}
|
||||
\begin{tabularx}{\textwidth}{p{0.19\textwidth}p{0.25\textwidth}Y}
|
||||
\toprule
|
||||
推广维度 & 具体表现 & 预期价值 \\
|
||||
\midrule
|
||||
场景迁移 & 可迁移至其他涉网资金案件 & 提高系统复用率和投资产出比 \\
|
||||
能力复用 & OCR、归并、认定、导出链路可复用 & 降低二次开发成本 \\
|
||||
数据沉淀 & 形成结构化案件数据与规则样本 & 支撑持续优化与模型迭代 \\
|
||||
组织推广 & 易于形成标准流程与培训材料 & 便于基层快速复制落地 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{安全与合规考虑}
|
||||
|
||||
警务智能体项目必须兼顾效果与合规。本项目在设计中坚持以下原则:只面向授权办案场景使用;案件数据按最小必要原则采集与处理;智能体输出仅作为辅助意见,最终认定由民警依法审核;关键过程保留结果快照和复核痕迹;部署方式可进一步向本地化或专网化环境扩展。
|
||||
16
docs/competition-book/chapters/08-conclusion.tex
Normal file
16
docs/competition-book/chapters/08-conclusion.tex
Normal file
@@ -0,0 +1,16 @@
|
||||
\chapter{结论}
|
||||
|
||||
本项目围绕电信网络诈骗案件受害人资金核查这一基层高频警务场景,构建了一套从截图证据输入到认定结果输出的多智能体协同系统。系统通过多APP截图自动识别、跨平台交易归并、本人账户中转识别、资金路径分析、被骗金额分层认定、人工复核与报告导出,形成了完整的办案辅助闭环。
|
||||
|
||||
与传统人工处理方式相比,本项目的核心价值在于三点:其一,将分散、重复、零碎的截图材料转化为统一结构化证据;其二,将依赖个体经验的排重与认定过程沉淀为可解释、可复核的规则化能力;其三,将最终结果直接转化为可汇报、可导出、可复用的办案材料。尤其是“证据识别后关键词回溯”的自我完善机制,使系统具备在任务执行过程中持续修正前序判断的能力,更符合智能体系统的发展方向。
|
||||
|
||||
从项目建设现状看,系统已经具备较清晰的功能边界、完整的业务链路和较强的展示性,适合作为全国“智慧+警务”AI智能体大赛的递交项目。从后续发展看,项目仍可在真实样本积累、规则精细化、专网部署、安全审计和跨案件研判等方面持续深化,进一步提升实战支撑能力和推广价值。
|
||||
|
||||
\section{后续完善建议}
|
||||
|
||||
\begin{enumerate}
|
||||
\item 在正式提交前补充脱敏后的真实截图、界面截图和导出报告样页;
|
||||
\item 用真实案件样本替换文中示例性成效数据,增强说服力;
|
||||
\item 补充本地化部署、安全控制和日志审计细节,提升项目完整性;
|
||||
\item 准备一段完整演示视频,与项目书形成互相印证的展示材料。
|
||||
\end{enumerate}
|
||||
41
docs/competition-book/chapters/09-appendix.tex
Normal file
41
docs/competition-book/chapters/09-appendix.tex
Normal file
@@ -0,0 +1,41 @@
|
||||
\chapter{附录}
|
||||
|
||||
\section{建议替换的图片清单}
|
||||
|
||||
\begin{longtable}{p{0.09\textwidth}p{0.22\textwidth}p{0.23\textwidth}p{0.28\textwidth}}
|
||||
\toprule
|
||||
序号 & 图片名称 & 建议来源 & 替换说明 \\
|
||||
\midrule
|
||||
图1 & 系统总体架构图 & 自绘架构图 & 展示系统分层、模块关系与数据流 \\
|
||||
图2 & 多APP截图样例图 & 脱敏后的真实截图 & 建议同时展示微信、支付宝、银行APP三类页面 \\
|
||||
图3 & 工作台界面图 & 系统前端页面截图 & 突出上传、OCR进度、交易数量、待复核数量 \\
|
||||
图4 & 交易归并对比图 & 自绘示意图或页面截图 & 展示归并前后记录数量变化 \\
|
||||
图5 & 中转识别示意图 & 自绘路径图 & 展示内部中转与对外支付的边界 \\
|
||||
图6 & 资金流转关系图 & 分析页截图 & 展示本人账户、涉诈账户、中转账户节点关系 \\
|
||||
图7 & 交易时间轴图 & 分析页截图 & 展示案件关键交易时序 \\
|
||||
图8 & 认定复核界面图 & 复核页截图 & 展示高、中、低置信和人工复核动作 \\
|
||||
图9 & 报告导出样页图 & PDF/Excel导出样页 & 展示最终办案输出成果 \\
|
||||
\bottomrule
|
||||
\end{longtable}
|
||||
|
||||
\section{建议替换的数据项}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{正式提交前建议补充的数据项}
|
||||
\begin{tabularx}{\textwidth}{p{0.22\textwidth}p{0.28\textwidth}Y}
|
||||
\toprule
|
||||
数据类别 & 具体字段 & 用途说明 \\
|
||||
\midrule
|
||||
案例基本信息 & 截图总数、涉及APP数量、交易总笔数 & 强化场景真实度 \\
|
||||
效率数据 & 人工耗时、系统耗时、复核耗时 & 用于说明效率提升 \\
|
||||
质量数据 & 重复计算减少情况、漏算纠正情况 & 用于说明准确率提升 \\
|
||||
输出数据 & 报告页数、导出格式、证据索引数量 & 用于说明办案输出能力 \\
|
||||
推广数据 & 试用人员反馈、可复制场景数量 & 用于说明推广价值 \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\end{table}
|
||||
|
||||
\section{编译说明}
|
||||
|
||||
本项目书建议使用 \texttt{xelatex} 编译,以便稳定支持中文排版。若后续新增真实图片,请统一放置在 \texttt{figures/} 目录中,并在替换占位图时采用脱敏后的正式材料。
|
||||
Reference in New Issue
Block a user