fix: bugs-04
This commit is contained in:
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{项目书写作边界说明}
|
||||
|
||||
本项目书以当前系统已具备的功能链路为依据,聚焦“案件管理、截图识别、交易归并、资金分析、认定复核、报告导出”六类核心能力展开说明。对后续可拓展能力,如更复杂的模型训练、跨案件比对或更广泛的警种复用,将仅作方向性展望,不将其写为既成事实。
|
||||
Reference in New Issue
Block a user