fix: bugs-04
This commit is contained in:
@@ -16,6 +16,7 @@ from app.schemas.assessment import (
|
||||
InquirySuggestionOut,
|
||||
)
|
||||
from app.services.assessment_service import generate_inquiry_suggestions
|
||||
from app.services.case_service import recalculate_case_total
|
||||
|
||||
router = APIRouter()
|
||||
|
||||
@@ -48,6 +49,7 @@ async def review_assessment(
|
||||
"reviewed_by": body.reviewed_by,
|
||||
"reviewed_at": datetime.now(timezone.utc),
|
||||
})
|
||||
await recalculate_case_total(assessment.case_id, db)
|
||||
|
||||
# eager-load the transaction relationship to avoid lazy-load in async context
|
||||
result = await db.execute(
|
||||
|
||||
@@ -15,11 +15,13 @@ from app.schemas.image import (
|
||||
ImageOut,
|
||||
ImageDetailOut,
|
||||
OcrFieldCorrection,
|
||||
OcrBlockUpdateIn,
|
||||
CaseOcrStartIn,
|
||||
CaseImagesDeleteIn,
|
||||
)
|
||||
from app.utils.hash import sha256_file
|
||||
from app.utils.file_storage import save_upload
|
||||
from app.models.ocr_block import OcrBlock
|
||||
|
||||
router = APIRouter()
|
||||
|
||||
@@ -149,6 +151,50 @@ async def correct_ocr(
|
||||
return {"message": "修正已保存", "corrections": len(corrections)}
|
||||
|
||||
|
||||
@router.patch("/images/{image_id}/ocr-blocks")
|
||||
async def update_ocr_blocks(
|
||||
image_id: UUID,
|
||||
blocks: list[OcrBlockUpdateIn],
|
||||
db: AsyncSession = Depends(get_db),
|
||||
):
|
||||
repo = ImageRepository(db)
|
||||
image = await repo.get(image_id)
|
||||
if not image:
|
||||
raise HTTPException(404, "截图不存在")
|
||||
|
||||
existing = sorted(list(image.ocr_blocks), key=lambda b: b.seq_order)
|
||||
total = len(blocks)
|
||||
if total == 0:
|
||||
return {"message": "未提交可保存内容", "updated": 0}
|
||||
|
||||
# Update existing blocks first.
|
||||
min_len = min(len(existing), total)
|
||||
for idx in range(min_len):
|
||||
existing[idx].content = blocks[idx].content
|
||||
existing[idx].confidence = blocks[idx].confidence
|
||||
existing[idx].seq_order = idx
|
||||
|
||||
# Create extra blocks if payload has more.
|
||||
for idx in range(min_len, total):
|
||||
db.add(
|
||||
OcrBlock(
|
||||
image_id=image_id,
|
||||
content=blocks[idx].content,
|
||||
bbox={},
|
||||
seq_order=idx,
|
||||
confidence=blocks[idx].confidence,
|
||||
)
|
||||
)
|
||||
|
||||
# Remove extra old blocks if payload has fewer.
|
||||
for idx in range(total, len(existing)):
|
||||
await db.delete(existing[idx])
|
||||
|
||||
await db.flush()
|
||||
await db.commit()
|
||||
return {"message": f"已保存 {total} 条OCR内容", "updated": total}
|
||||
|
||||
|
||||
@router.get("/images/{image_id}/file")
|
||||
async def get_image_file(image_id: UUID, db: AsyncSession = Depends(get_db)):
|
||||
repo = ImageRepository(db)
|
||||
|
||||
@@ -5,7 +5,12 @@ from sqlalchemy.ext.asyncio import AsyncSession
|
||||
|
||||
from app.core.database import get_db
|
||||
from app.repositories.transaction_repo import TransactionRepository
|
||||
from app.schemas.transaction import TransactionOut, TransactionListOut, FlowGraphOut
|
||||
from app.schemas.transaction import (
|
||||
TransactionOut,
|
||||
TransactionListOut,
|
||||
FlowGraphOut,
|
||||
TransactionUpdateIn,
|
||||
)
|
||||
from app.services.flow_service import build_flow_graph
|
||||
|
||||
router = APIRouter()
|
||||
@@ -31,6 +36,23 @@ async def get_transaction(tx_id: UUID, db: AsyncSession = Depends(get_db)):
|
||||
return tx
|
||||
|
||||
|
||||
@router.patch("/transactions/{tx_id}", response_model=TransactionOut)
|
||||
async def update_transaction(
|
||||
tx_id: UUID,
|
||||
body: TransactionUpdateIn,
|
||||
db: AsyncSession = Depends(get_db),
|
||||
):
|
||||
repo = TransactionRepository(db)
|
||||
tx = await repo.get(tx_id)
|
||||
if not tx:
|
||||
raise HTTPException(404, "交易不存在")
|
||||
|
||||
update_data = body.model_dump(exclude_unset=True)
|
||||
tx = await repo.update(tx, update_data)
|
||||
await db.commit()
|
||||
return tx
|
||||
|
||||
|
||||
@router.get("/cases/{case_id}/flows", response_model=FlowGraphOut)
|
||||
async def get_fund_flows(case_id: UUID, db: AsyncSession = Depends(get_db)):
|
||||
return await build_flow_graph(case_id, db)
|
||||
|
||||
@@ -4,9 +4,13 @@ Identifies transactions that are internal transfers between the victim's
|
||||
own accounts (e.g. bank -> Alipay -> WeChat) and should NOT be counted
|
||||
as fraud loss.
|
||||
"""
|
||||
from datetime import datetime
|
||||
|
||||
from app.models.transaction import TransactionRecord
|
||||
|
||||
SELF_KEYWORDS = ["本人", "自己", "余额", "充值", "提现", "银行卡转入", "银行卡充值"]
|
||||
FEE_TRANSIT_WINDOW_SECONDS = 120
|
||||
FEE_TOLERANCE_RATIO = 0.02
|
||||
|
||||
|
||||
def is_self_transfer(tx: TransactionRecord, known_self_accounts: list[str]) -> bool:
|
||||
@@ -33,3 +37,27 @@ def is_self_transfer(tx: TransactionRecord, known_self_accounts: list[str]) -> b
|
||||
return True
|
||||
|
||||
return False
|
||||
|
||||
|
||||
def is_fee_tolerant_transit_pair(tx_a: TransactionRecord, tx_b: TransactionRecord) -> bool:
|
||||
"""Two-way transfer pattern: opposite direction, close time, similar amount."""
|
||||
if tx_a.direction.value == tx_b.direction.value:
|
||||
return False
|
||||
|
||||
amount_a = float(tx_a.amount or 0)
|
||||
amount_b = float(tx_b.amount or 0)
|
||||
if amount_a <= 0 or amount_b <= 0:
|
||||
return False
|
||||
|
||||
time_a = tx_a.trade_time
|
||||
time_b = tx_b.trade_time
|
||||
if not isinstance(time_a, datetime) or not isinstance(time_b, datetime):
|
||||
return False
|
||||
if abs((time_a - time_b).total_seconds()) > FEE_TRANSIT_WINDOW_SECONDS:
|
||||
return False
|
||||
|
||||
amount_base = max(amount_a, amount_b)
|
||||
if amount_base <= 0:
|
||||
return False
|
||||
diff_ratio = abs(amount_a - amount_b) / amount_base
|
||||
return diff_ratio <= FEE_TOLERANCE_RATIO
|
||||
|
||||
@@ -35,6 +35,11 @@ class OcrFieldCorrection(CamelModel):
|
||||
new_value: str
|
||||
|
||||
|
||||
class OcrBlockUpdateIn(CamelModel):
|
||||
content: str
|
||||
confidence: float = 0.5
|
||||
|
||||
|
||||
class CaseOcrStartIn(CamelModel):
|
||||
include_done: bool = False
|
||||
image_ids: list[UUID] = []
|
||||
|
||||
@@ -25,6 +25,21 @@ class TransactionOut(CamelModel):
|
||||
is_transit: bool
|
||||
|
||||
|
||||
class TransactionUpdateIn(CamelModel):
|
||||
source_app: SourceApp | None = None
|
||||
trade_time: datetime | None = None
|
||||
amount: float | None = None
|
||||
direction: Direction | None = None
|
||||
counterparty_name: str | None = None
|
||||
counterparty_account: str | None = None
|
||||
self_account_tail_no: str | None = None
|
||||
order_no: str | None = None
|
||||
remark: str | None = None
|
||||
confidence: float | None = None
|
||||
is_duplicate: bool | None = None
|
||||
is_transit: bool | None = None
|
||||
|
||||
|
||||
class TransactionListOut(CamelModel):
|
||||
items: list[TransactionOut]
|
||||
total: int
|
||||
|
||||
@@ -9,11 +9,17 @@ from app.models.assessment import FraudAssessment, ReviewStatus
|
||||
|
||||
|
||||
async def recalculate_case_total(case_id: UUID, db: AsyncSession) -> float:
|
||||
"""Recalculate and persist the total confirmed fraud amount for a case."""
|
||||
"""Recalculate and persist the recognized fraud amount for a case.
|
||||
|
||||
The case-level amount shown in case list/workspace represents the current
|
||||
recognized amount after analysis, so it should include pending/confirmed/
|
||||
needs_info items and only exclude explicitly rejected records.
|
||||
"""
|
||||
result = await db.execute(
|
||||
select(func.coalesce(func.sum(FraudAssessment.assessed_amount), 0))
|
||||
.where(FraudAssessment.case_id == case_id)
|
||||
.where(FraudAssessment.review_status == ReviewStatus.confirmed)
|
||||
.where(FraudAssessment.assessed_amount > 0)
|
||||
.where(FraudAssessment.review_status != ReviewStatus.rejected)
|
||||
)
|
||||
total = float(result.scalar() or 0)
|
||||
case = await db.get(Case, case_id)
|
||||
|
||||
@@ -15,7 +15,7 @@ from app.models.transaction import TransactionRecord
|
||||
from app.models.transaction_cluster import TransactionCluster
|
||||
from app.repositories.transaction_repo import TransactionRepository
|
||||
from app.rules.dedup_rules import is_duplicate_pair
|
||||
from app.rules.transit_rules import is_self_transfer
|
||||
from app.rules.transit_rules import is_self_transfer, is_fee_tolerant_transit_pair
|
||||
|
||||
|
||||
async def run_matching(case_id: UUID, self_accounts: list[str], db: AsyncSession) -> None:
|
||||
@@ -70,6 +70,15 @@ async def run_matching(case_id: UUID, self_accounts: list[str], db: AsyncSession
|
||||
if is_self_transfer(tx, self_accounts):
|
||||
tx.is_transit = True
|
||||
|
||||
# Rule extension: if an in/out pair occurs within 2 minutes and
|
||||
# amount difference is within 2% (e.g. fee), mark both as transit.
|
||||
non_duplicate = [tx for tx in transactions if not tx.is_duplicate]
|
||||
for i, tx_a in enumerate(non_duplicate):
|
||||
for tx_b in non_duplicate[i + 1 :]:
|
||||
if is_fee_tolerant_transit_pair(tx_a, tx_b):
|
||||
tx_a.is_transit = True
|
||||
tx_b.is_transit = True
|
||||
|
||||
await db.flush()
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ import pytest
|
||||
from app.models.transaction import Direction
|
||||
from app.models.evidence_image import SourceApp
|
||||
from app.rules.dedup_rules import is_duplicate_pair
|
||||
from app.rules.transit_rules import is_self_transfer
|
||||
from app.rules.transit_rules import is_self_transfer, is_fee_tolerant_transit_pair
|
||||
from app.rules.assessment_rules import classify_transaction
|
||||
|
||||
|
||||
@@ -79,6 +79,32 @@ class TestTransitRules:
|
||||
tx = _make_tx(counterparty_name="李*华", remark="投资款")
|
||||
assert not is_self_transfer(tx, [])
|
||||
|
||||
def test_fee_tolerant_pair_match(self):
|
||||
out_tx = _make_tx(
|
||||
direction=Direction.out,
|
||||
amount=10000,
|
||||
trade_time=datetime(2026, 3, 8, 10, 0, tzinfo=timezone.utc),
|
||||
)
|
||||
in_tx = _make_tx(
|
||||
direction=Direction.in_,
|
||||
amount=9850, # 1.5% diff
|
||||
trade_time=datetime(2026, 3, 8, 10, 1, 30, tzinfo=timezone.utc),
|
||||
)
|
||||
assert is_fee_tolerant_transit_pair(out_tx, in_tx)
|
||||
|
||||
def test_fee_tolerant_pair_time_window_exceeded(self):
|
||||
out_tx = _make_tx(
|
||||
direction=Direction.out,
|
||||
amount=10000,
|
||||
trade_time=datetime(2026, 3, 8, 10, 0, tzinfo=timezone.utc),
|
||||
)
|
||||
in_tx = _make_tx(
|
||||
direction=Direction.in_,
|
||||
amount=9900,
|
||||
trade_time=datetime(2026, 3, 8, 10, 3, 1, tzinfo=timezone.utc),
|
||||
)
|
||||
assert not is_fee_tolerant_transit_pair(out_tx, in_tx)
|
||||
|
||||
|
||||
class TestAssessmentRules:
|
||||
def test_transit_classified_as_low(self):
|
||||
|
||||
9
docs/competition-book/Makefile
Normal file
9
docs/competition-book/Makefile
Normal file
@@ -0,0 +1,9 @@
|
||||
LATEX=xelatex
|
||||
TARGET=main
|
||||
|
||||
all:
|
||||
$(LATEX) $(TARGET).tex
|
||||
$(LATEX) $(TARGET).tex
|
||||
|
||||
clean:
|
||||
rm -f *.aux *.fdb_latexmk *.fls *.log *.out *.toc *.lof *.lot *.xdv *.synctex.gz
|
||||
5
docs/competition-book/build.sh
Executable file
5
docs/competition-book/build.sh
Executable file
@@ -0,0 +1,5 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
xelatex main.tex
|
||||
xelatex main.tex
|
||||
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/} 目录中，并在替换占位图时采用脱敏后的正式材料。
|
||||
115
docs/competition-book/main.aux
Normal file
115
docs/competition-book/main.aux
Normal file
@@ -0,0 +1,115 @@
|
||||
\relax
|
||||
\providecommand\hyper@newdestlabel[2]{}
|
||||
\providecommand*\HyPL@Entry[1]{}
|
||||
\HyPL@Entry{0<</S/D>>}
|
||||
\HyPL@Entry{1<</S/r>>}
|
||||
\@writefile{toc}{\contentsline {chapter}{摘要}{i}{chapter*.1}\protected@file@percent }
|
||||
\HyPL@Entry{4<</S/D>>}
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第一章\hspace {.3em}}项目背景与建设意义}{1}{chapter.1}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.1}建设背景}{1}{section.1.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.2}建设意义}{1}{section.1.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.1}对一线办案的直接支撑}{1}{subsection.1.2.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}对证据组织方式的升级}{1}{subsection.1.2.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.3}对警务智能体应用范式的示范}{1}{subsection.1.2.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.3}项目定位}{1}{section.1.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {1.1}{\ignorespaces 项目定位与警务价值对应表}}{2}{table.caption.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.4}建设目标}{2}{section.1.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第二章\hspace {.3em}}场景痛点与需求分析}{2}{chapter.2}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.1}业务场景还原}{2}{section.2.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.2}现有处理方式存在的问题}{3}{section.2.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2.1}问题一：截图材料分散，人工整理耗时长}{3}{subsection.2.2.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2.2}问题二：同一交易多次展示，重复计算风险高}{3}{subsection.2.2.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2.3}问题三：中转与对外支付混杂，认定难度大}{3}{subsection.2.2.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2.4}问题四：结果不可复用，后续仍需重复整理}{3}{subsection.2.2.4}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {2.1}{\ignorespaces 传统处理方式主要问题分析表}}{3}{table.caption.6}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.3}核心需求分析}{3}{section.2.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.1}需求一：统一识别与结构化抽取}{3}{subsection.2.3.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.2}需求二：跨平台归并与资金链恢复}{4}{subsection.2.3.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.3}需求三：面向办案的认定结果输出}{4}{subsection.2.3.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3.4}需求四：形成可复核、可汇报、可导出的成果}{4}{subsection.2.3.4}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {2.2}{\ignorespaces 系统建设需求分解表}}{4}{table.caption.7}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.4}项目书写作边界说明}{4}{section.2.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第三章\hspace {.3em}}总体方案与技术路线}{4}{chapter.3}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3.1}总体设计原则}{4}{section.3.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3.2}总体架构}{4}{section.3.2}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {3.1}{\ignorespaces 总体架构层次说明表}}{5}{table.caption.9}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3.3}多智能体协同分工}{5}{section.3.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {3.2}{\ignorespaces 多智能体协同分工表}}{5}{table.caption.10}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3.4}技术路线}{6}{section.3.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {3.5}流程闭环}{6}{section.3.5}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第四章\hspace {.3em}}核心能力与关键机制}{6}{chapter.4}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.1}多APP截图识别与字段抽取}{6}{section.4.1}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.1}{\ignorespaces 截图识别关键字段表}}{7}{table.caption.12}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.2}关键词回溯驱动的自我完善机制}{7}{section.4.2}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.2}{\ignorespaces 关键词回溯优化机制说明表}}{8}{table.caption.14}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.3}跨平台交易归并与去重}{8}{section.4.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.3}{\ignorespaces 交易归并与去重规则表}}{8}{table.caption.15}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.4}本人账户中转识别}{8}{section.4.4}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.4}{\ignorespaces 本人账户中转识别逻辑表}}{9}{table.caption.17}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.5}被骗金额分层认定}{9}{section.4.5}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.5}{\ignorespaces 被骗金额分层认定表}}{9}{table.caption.19}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {4.6}笔录辅助生成、问询建议与证据化输出}{9}{section.4.6}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {4.6}{\ignorespaces 认定复核页笔录功能说明表}}{10}{table.caption.20}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第五章\hspace {.3em}}系统实现与界面展示}{10}{chapter.5}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {5.1}系统实现概况}{10}{section.5.1}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {5.1}{\ignorespaces 系统技术实现表}}{10}{table.caption.21}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {5.2}前端功能页面}{10}{section.5.2}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {5.2}{\ignorespaces 前端核心页面说明表}}{11}{table.caption.22}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {5.3}后端接口与服务实现}{12}{section.5.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {5.3}{\ignorespaces 后端主要接口表}}{12}{table.caption.27}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {5.4}处理链路实现}{12}{section.5.4}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {5.4}{\ignorespaces 案件分析链路实现表}}{12}{table.caption.28}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {5.5}部署与演示方式}{13}{section.5.5}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {5.5}{\ignorespaces 部署与演示方式表}}{13}{table.caption.29}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第六章\hspace {.3em}}创新点与方案优势}{13}{chapter.6}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6.1}创新点提炼}{13}{section.6.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.1}场景创新}{13}{subsection.6.1.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.2}方法创新}{13}{subsection.6.1.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.3}机制创新}{13}{subsection.6.1.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1.4}输出创新}{13}{subsection.6.1.4}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {6.1}{\ignorespaces 项目创新点汇总表}}{14}{table.caption.30}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6.2}与传统方式对比优势}{14}{section.6.2}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {6.2}{\ignorespaces 与传统人工处理方式对比表}}{14}{table.caption.31}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6.3}与单点OCR工具对比优势}{14}{section.6.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6.4}方案优势总结}{14}{section.6.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第七章\hspace {.3em}}应用成效与推广前景}{15}{chapter.7}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {7.1}应用成效说明}{15}{section.7.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1.1}效率提升}{15}{subsection.7.1.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1.2}质量提升}{15}{subsection.7.1.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1.3}复用提升}{15}{subsection.7.1.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {7.1}{\ignorespaces 应用成效示例表（正式提交时替换为实测数据）}}{15}{table.caption.33}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {7.2}答辩展示建议}{15}{section.7.2}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {7.3}推广前景}{16}{section.7.3}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {7.2}{\ignorespaces 项目推广价值分析表}}{16}{table.caption.35}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {7.4}安全与合规考虑}{16}{section.7.4}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {第八章\hspace {.3em}}结论}{16}{chapter.8}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\gdef \LT@i {\LT@entry
|
||||
{1}{55.27486pt}\LT@entry
|
||||
{1}{117.78789pt}\LT@entry
|
||||
{1}{122.59377pt}\LT@entry
|
||||
{1}{146.6378pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {8.1}后续完善建议}{17}{section.8.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {附录 A\hspace {.3em}}附录}{17}{appendix.A}\protected@file@percent }
|
||||
\@writefile{lof}{\addvspace {10.0pt}}
|
||||
\@writefile{lot}{\addvspace {10.0pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {A.1}建议替换的图片清单}{17}{section.A.1}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {A.2}建议替换的数据项}{17}{section.A.2}\protected@file@percent }
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {A.2}{\ignorespaces 正式提交前建议补充的数据项}}{17}{table.caption.36}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {A.3}编译说明}{18}{section.A.3}\protected@file@percent }
|
||||
\gdef \@abspage@last{22}
|
||||
64
docs/competition-book/main.out
Normal file
64
docs/competition-book/main.out
Normal file
@@ -0,0 +1,64 @@
|
||||
\BOOKMARK [0][-]{chapter*.1}{\376\377\144\130\211\201}{}% 1
|
||||
\BOOKMARK [0][-]{chapter.1}{\376\377\230\171\166\356\200\314\146\157\116\016\136\372\213\276\141\017\116\111}{}% 2
|
||||
\BOOKMARK [1][-]{section.1.1}{\376\377\136\372\213\276\200\314\146\157}{chapter.1}% 3
|
||||
\BOOKMARK [1][-]{section.1.2}{\376\377\136\372\213\276\141\017\116\111}{chapter.1}% 4
|
||||
\BOOKMARK [2][-]{subsection.1.2.1}{\376\377\133\371\116\000\176\277\122\236\150\110\166\204\166\364\143\245\145\057\144\221}{section.1.2}% 5
|
||||
\BOOKMARK [2][-]{subsection.1.2.2}{\376\377\133\371\213\301\143\156\176\304\176\307\145\271\137\017\166\204\123\107\176\247}{section.1.2}% 6
|
||||
\BOOKMARK [2][-]{subsection.1.2.3}{\376\377\133\371\213\146\122\241\146\172\200\375\117\123\136\224\165\050\203\003\137\017\166\204\171\072\203\003}{section.1.2}% 7
|
||||
\BOOKMARK [1][-]{section.1.3}{\376\377\230\171\166\356\133\232\117\115}{chapter.1}% 8
|
||||
\BOOKMARK [1][-]{section.1.4}{\376\377\136\372\213\276\166\356\150\007}{chapter.1}% 9
|
||||
\BOOKMARK [0][-]{chapter.2}{\376\377\127\072\146\157\165\333\160\271\116\016\227\000\154\102\122\006\147\220}{}% 10
|
||||
\BOOKMARK [1][-]{section.2.1}{\376\377\116\032\122\241\127\072\146\157\217\330\123\237}{chapter.2}% 11
|
||||
\BOOKMARK [1][-]{section.2.2}{\376\377\163\260\147\011\131\004\164\006\145\271\137\017\133\130\127\050\166\204\225\356\230\230}{chapter.2}% 12
|
||||
\BOOKMARK [2][-]{subsection.2.2.1}{\376\377\225\356\230\230\116\000\377\032\142\052\126\376\147\120\145\231\122\006\145\143\377\014\116\272\135\345\145\164\164\006\200\027\145\366\225\177}{section.2.2}% 13
|
||||
\BOOKMARK [2][-]{subsection.2.2.2}{\376\377\225\356\230\230\116\214\377\032\124\014\116\000\116\244\146\023\131\032\153\041\134\125\171\072\377\014\221\315\131\015\213\241\173\227\230\316\226\151\232\330}{section.2.2}% 14
|
||||
\BOOKMARK [2][-]{subsection.2.2.3}{\376\377\225\356\230\230\116\011\377\032\116\055\217\154\116\016\133\371\131\026\145\057\116\330\155\367\147\102\377\014\213\244\133\232\226\276\136\246\131\047}{section.2.2}% 15
|
||||
\BOOKMARK [2][-]{subsection.2.2.4}{\376\377\225\356\230\230\126\333\377\032\176\323\147\234\116\015\123\357\131\015\165\050\377\014\124\016\176\355\116\315\227\000\221\315\131\015\145\164\164\006}{section.2.2}% 16
|
||||
\BOOKMARK [1][-]{section.2.3}{\376\377\150\070\137\303\227\000\154\102\122\006\147\220}{chapter.2}% 17
|
||||
\BOOKMARK [2][-]{subsection.2.3.1}{\376\377\227\000\154\102\116\000\377\032\176\337\116\000\213\306\122\053\116\016\176\323\147\204\123\026\142\275\123\326}{section.2.3}% 18
|
||||
\BOOKMARK [2][-]{subsection.2.3.2}{\376\377\227\000\154\102\116\214\377\032\215\350\136\163\123\360\137\122\136\166\116\016\215\104\221\321\224\376\140\142\131\015}{section.2.3}% 19
|
||||
\BOOKMARK [2][-]{subsection.2.3.3}{\376\377\227\000\154\102\116\011\377\032\227\142\124\021\122\236\150\110\166\204\213\244\133\232\176\323\147\234\217\223\121\372}{section.2.3}% 20
|
||||
\BOOKMARK [2][-]{subsection.2.3.4}{\376\377\227\000\154\102\126\333\377\032\137\142\142\020\123\357\131\015\150\070\060\001\123\357\154\107\142\245\060\001\123\357\133\374\121\372\166\204\142\020\147\234}{section.2.3}% 21
|
||||
\BOOKMARK [1][-]{section.2.4}{\376\377\230\171\166\356\116\146\121\231\117\134\217\271\165\114\213\364\146\016}{chapter.2}% 22
|
||||
\BOOKMARK [0][-]{chapter.3}{\376\377\140\073\117\123\145\271\150\110\116\016\142\200\147\057\215\357\176\277}{}% 23
|
||||
\BOOKMARK [1][-]{section.3.1}{\376\377\140\073\117\123\213\276\213\241\123\237\122\031}{chapter.3}% 24
|
||||
\BOOKMARK [1][-]{section.3.2}{\376\377\140\073\117\123\147\266\147\204}{chapter.3}% 25
|
||||
\BOOKMARK [1][-]{section.3.3}{\376\377\131\032\146\172\200\375\117\123\123\117\124\014\122\006\135\345}{chapter.3}% 26
|
||||
\BOOKMARK [1][-]{section.3.4}{\376\377\142\200\147\057\215\357\176\277}{chapter.3}% 27
|
||||
\BOOKMARK [1][-]{section.3.5}{\376\377\155\101\172\013\225\355\163\257}{chapter.3}% 28
|
||||
\BOOKMARK [0][-]{chapter.4}{\376\377\150\070\137\303\200\375\122\233\116\016\121\163\225\056\147\072\122\066}{}% 29
|
||||
\BOOKMARK [1][-]{section.4.1}{\376\377\131\032\000A\000P\000P\142\052\126\376\213\306\122\053\116\016\133\127\153\265\142\275\123\326}{chapter.4}% 30
|
||||
\BOOKMARK [1][-]{section.4.2}{\376\377\121\163\225\056\213\315\126\336\156\257\232\161\122\250\166\204\201\352\142\021\133\214\125\204\147\072\122\066}{chapter.4}% 31
|
||||
\BOOKMARK [1][-]{section.4.3}{\376\377\215\350\136\163\123\360\116\244\146\023\137\122\136\166\116\016\123\273\221\315}{chapter.4}% 32
|
||||
\BOOKMARK [1][-]{section.4.4}{\376\377\147\054\116\272\215\046\142\067\116\055\217\154\213\306\122\053}{chapter.4}% 33
|
||||
\BOOKMARK [1][-]{section.4.5}{\376\377\210\253\232\227\221\321\230\235\122\006\134\102\213\244\133\232}{chapter.4}% 34
|
||||
\BOOKMARK [1][-]{section.4.6}{\376\377\173\024\137\125\217\205\122\251\165\037\142\020\060\001\225\356\213\342\136\372\213\256\116\016\213\301\143\156\123\026\217\223\121\372}{chapter.4}% 35
|
||||
\BOOKMARK [0][-]{chapter.5}{\376\377\174\373\176\337\133\236\163\260\116\016\165\114\227\142\134\125\171\072}{}% 36
|
||||
\BOOKMARK [1][-]{section.5.1}{\376\377\174\373\176\337\133\236\163\260\151\202\121\265}{chapter.5}% 37
|
||||
\BOOKMARK [1][-]{section.5.2}{\376\377\122\115\172\357\122\237\200\375\230\165\227\142}{chapter.5}% 38
|
||||
\BOOKMARK [1][-]{section.5.3}{\376\377\124\016\172\357\143\245\123\343\116\016\147\015\122\241\133\236\163\260}{chapter.5}% 39
|
||||
\BOOKMARK [1][-]{section.5.4}{\376\377\131\004\164\006\224\376\215\357\133\236\163\260}{chapter.5}% 40
|
||||
\BOOKMARK [1][-]{section.5.5}{\376\377\220\350\177\162\116\016\157\024\171\072\145\271\137\017}{chapter.5}% 41
|
||||
\BOOKMARK [0][-]{chapter.6}{\376\377\122\033\145\260\160\271\116\016\145\271\150\110\117\030\122\277}{}% 42
|
||||
\BOOKMARK [1][-]{section.6.1}{\376\377\122\033\145\260\160\271\143\320\160\274}{chapter.6}% 43
|
||||
\BOOKMARK [2][-]{subsection.6.1.1}{\376\377\127\072\146\157\122\033\145\260}{section.6.1}% 44
|
||||
\BOOKMARK [2][-]{subsection.6.1.2}{\376\377\145\271\154\325\122\033\145\260}{section.6.1}% 45
|
||||
\BOOKMARK [2][-]{subsection.6.1.3}{\376\377\147\072\122\066\122\033\145\260}{section.6.1}% 46
|
||||
\BOOKMARK [2][-]{subsection.6.1.4}{\376\377\217\223\121\372\122\033\145\260}{section.6.1}% 47
|
||||
\BOOKMARK [1][-]{section.6.2}{\376\377\116\016\117\040\176\337\145\271\137\017\133\371\153\324\117\030\122\277}{chapter.6}% 48
|
||||
\BOOKMARK [1][-]{section.6.3}{\376\377\116\016\123\125\160\271\000O\000C\000R\135\345\121\167\133\371\153\324\117\030\122\277}{chapter.6}% 49
|
||||
\BOOKMARK [1][-]{section.6.4}{\376\377\145\271\150\110\117\030\122\277\140\073\176\323}{chapter.6}% 50
|
||||
\BOOKMARK [0][-]{chapter.7}{\376\377\136\224\165\050\142\020\145\110\116\016\143\250\136\177\122\115\146\157}{}% 51
|
||||
\BOOKMARK [1][-]{section.7.1}{\376\377\136\224\165\050\142\020\145\110\213\364\146\016}{chapter.7}% 52
|
||||
\BOOKMARK [2][-]{subsection.7.1.1}{\376\377\145\110\163\207\143\320\123\107}{section.7.1}% 53
|
||||
\BOOKMARK [2][-]{subsection.7.1.2}{\376\377\215\050\221\317\143\320\123\107}{section.7.1}% 54
|
||||
\BOOKMARK [2][-]{subsection.7.1.3}{\376\377\131\015\165\050\143\320\123\107}{section.7.1}% 55
|
||||
\BOOKMARK [1][-]{section.7.2}{\376\377\173\124\217\251\134\125\171\072\136\372\213\256}{chapter.7}% 56
|
||||
\BOOKMARK [1][-]{section.7.3}{\376\377\143\250\136\177\122\115\146\157}{chapter.7}% 57
|
||||
\BOOKMARK [1][-]{section.7.4}{\376\377\133\211\121\150\116\016\124\010\211\304\200\003\206\121}{chapter.7}% 58
|
||||
\BOOKMARK [0][-]{chapter.8}{\376\377\176\323\213\272}{}% 59
|
||||
\BOOKMARK [1][-]{section.8.1}{\376\377\124\016\176\355\133\214\125\204\136\372\213\256}{chapter.8}% 60
|
||||
\BOOKMARK [0][-]{appendix.A}{\376\377\226\104\137\125}{}% 61
|
||||
\BOOKMARK [1][-]{section.A.1}{\376\377\136\372\213\256\146\377\143\142\166\204\126\376\162\107\156\005\123\125}{appendix.A}% 62
|
||||
\BOOKMARK [1][-]{section.A.2}{\376\377\136\372\213\256\146\377\143\142\166\204\145\160\143\156\230\171}{appendix.A}% 63
|
||||
\BOOKMARK [1][-]{section.A.3}{\376\377\177\026\213\321\213\364\146\016}{appendix.A}% 64
|
||||
BIN
docs/competition-book/main.pdf
Normal file
BIN
docs/competition-book/main.pdf
Normal file
Binary file not shown.
65
docs/competition-book/main.tex
Normal file
65
docs/competition-book/main.tex
Normal file
@@ -0,0 +1,65 @@
|
||||
\documentclass[UTF8,11pt,a4paper,oneside,openany]{ctexbook}
|
||||
|
||||
\input{preamble}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{titlepage}
|
||||
\centering
|
||||
\vspace*{1.8cm}
|
||||
|
||||
{\zihao{2}\bfseries 全国“智慧+警务”AI智能体大赛项目书\par}
|
||||
\vspace{1.6cm}
|
||||
{\zihao{0}\bfseries 智析反诈\par}
|
||||
\vspace{0.5cm}
|
||||
{\zihao{2}\bfseries 面向电信网络诈骗案件受害人资金核查的\par}
|
||||
\vspace{0.25cm}
|
||||
{\zihao{2}\bfseries 多智能体协同认定系统\par}
|
||||
\vspace{1.2cm}
|
||||
{\zihao{4}多APP账单截图解析、跨平台交易归并、资金路径分析与被骗金额认定\par}
|
||||
|
||||
\vfill
|
||||
|
||||
\begin{tabularx}{0.72\textwidth}{>{\raggedleft\arraybackslash}p{0.28\textwidth}X}
|
||||
项目名称： & 智析反诈 \\
|
||||
申报单位： & 【待填写】 \\
|
||||
项目负责人： & 【待填写】 \\
|
||||
团队成员： & 【待填写】 \\
|
||||
完成时间： & \today \\
|
||||
\end{tabularx}
|
||||
|
||||
\vfill
|
||||
{\small 本项目书为递交版草案，文中带“占位”或“示例”的图表数据需在正式提交前替换为真实材料。}
|
||||
\end{titlepage}
|
||||
|
||||
\frontmatter
|
||||
|
||||
\chapter*{摘\quad 要}
|
||||
\addcontentsline{toc}{chapter}{摘要}
|
||||
|
||||
针对电信网络诈骗案件受害人资金核查过程中截图数量大、平台来源杂、重复统计风险高、人工整理负担重等突出问题，本文提出并实现“智析反诈”多智能体协同认定系统。系统面向基层派出所民警真实办案场景，以案件为组织单元，对微信、支付宝、银行APP、数字钱包等多源账单截图进行自动识别、字段抽取、跨平台归并、资金路径分析、被骗金额分层认定与证据化输出，并通过人工复核机制保障结果可解释、可追溯、可确认。
|
||||
|
||||
本项目采用“视觉识别 + 规则约束 + 智能推理 + 人机协同”的技术路线，重点解决三类核心难题：一是不同APP与不同页面之间的截图证据统一建模；二是同一交易在多截图、多平台中的重复展示识别；三是本人账户中转、退款返还、待核实交易等复杂情形下的被骗金额认定。系统进一步引入证据识别后的关键词回溯机制，利用后续高置信识别结果反向校正账单页面类型判断，形成具备自我完善特征的轻量级优化闭环。
|
||||
|
||||
从系统实现看，项目已形成案件管理、截图上传、OCR识别、交易归并、资金分析、认定复核、问询建议和报告导出等完整办案链路；从应用价值看，项目能够显著提升受害人笔录前事实梳理效率、降低金额误算与漏算风险，并为案件流转提供可复用的结构化证据底稿。该系统兼具实战价值、推广价值和示范意义，适合作为基层警务智能体应用的典型样板。
|
||||
|
||||
\vspace{0.6cm}
|
||||
\noindent\textbf{关键词：}电信网络诈骗；资金核查；多智能体协同；截图证据解析；被骗金额认定；人机协同
|
||||
|
||||
\tableofcontents
|
||||
\clearpage
|
||||
|
||||
\mainmatter
|
||||
|
||||
\input{chapters/01-overview}
|
||||
\input{chapters/02-demand}
|
||||
\input{chapters/03-solution}
|
||||
\input{chapters/04-mechanism}
|
||||
\input{chapters/05-implementation}
|
||||
\input{chapters/06-innovation}
|
||||
\input{chapters/07-application}
|
||||
\input{chapters/08-conclusion}
|
||||
\appendix
|
||||
\input{chapters/09-appendix}
|
||||
|
||||
\end{document}
|
||||
64
docs/competition-book/main.toc
Normal file
64
docs/competition-book/main.toc
Normal file
@@ -0,0 +1,64 @@
|
||||
\contentsline {chapter}{摘要}{i}{chapter*.1}%
|
||||
\contentsline {chapter}{\numberline {第一章\hspace {.3em}}项目背景与建设意义}{1}{chapter.1}%
|
||||
\contentsline {section}{\numberline {1.1}建设背景}{1}{section.1.1}%
|
||||
\contentsline {section}{\numberline {1.2}建设意义}{1}{section.1.2}%
|
||||
\contentsline {subsection}{\numberline {1.2.1}对一线办案的直接支撑}{1}{subsection.1.2.1}%
|
||||
\contentsline {subsection}{\numberline {1.2.2}对证据组织方式的升级}{1}{subsection.1.2.2}%
|
||||
\contentsline {subsection}{\numberline {1.2.3}对警务智能体应用范式的示范}{1}{subsection.1.2.3}%
|
||||
\contentsline {section}{\numberline {1.3}项目定位}{1}{section.1.3}%
|
||||
\contentsline {section}{\numberline {1.4}建设目标}{2}{section.1.4}%
|
||||
\contentsline {chapter}{\numberline {第二章\hspace {.3em}}场景痛点与需求分析}{2}{chapter.2}%
|
||||
\contentsline {section}{\numberline {2.1}业务场景还原}{2}{section.2.1}%
|
||||
\contentsline {section}{\numberline {2.2}现有处理方式存在的问题}{3}{section.2.2}%
|
||||
\contentsline {subsection}{\numberline {2.2.1}问题一：截图材料分散，人工整理耗时长}{3}{subsection.2.2.1}%
|
||||
\contentsline {subsection}{\numberline {2.2.2}问题二：同一交易多次展示，重复计算风险高}{3}{subsection.2.2.2}%
|
||||
\contentsline {subsection}{\numberline {2.2.3}问题三：中转与对外支付混杂，认定难度大}{3}{subsection.2.2.3}%
|
||||
\contentsline {subsection}{\numberline {2.2.4}问题四：结果不可复用，后续仍需重复整理}{3}{subsection.2.2.4}%
|
||||
\contentsline {section}{\numberline {2.3}核心需求分析}{3}{section.2.3}%
|
||||
\contentsline {subsection}{\numberline {2.3.1}需求一：统一识别与结构化抽取}{3}{subsection.2.3.1}%
|
||||
\contentsline {subsection}{\numberline {2.3.2}需求二：跨平台归并与资金链恢复}{4}{subsection.2.3.2}%
|
||||
\contentsline {subsection}{\numberline {2.3.3}需求三：面向办案的认定结果输出}{4}{subsection.2.3.3}%
|
||||
\contentsline {subsection}{\numberline {2.3.4}需求四：形成可复核、可汇报、可导出的成果}{4}{subsection.2.3.4}%
|
||||
\contentsline {section}{\numberline {2.4}项目书写作边界说明}{4}{section.2.4}%
|
||||
\contentsline {chapter}{\numberline {第三章\hspace {.3em}}总体方案与技术路线}{4}{chapter.3}%
|
||||
\contentsline {section}{\numberline {3.1}总体设计原则}{4}{section.3.1}%
|
||||
\contentsline {section}{\numberline {3.2}总体架构}{4}{section.3.2}%
|
||||
\contentsline {section}{\numberline {3.3}多智能体协同分工}{5}{section.3.3}%
|
||||
\contentsline {section}{\numberline {3.4}技术路线}{6}{section.3.4}%
|
||||
\contentsline {section}{\numberline {3.5}流程闭环}{6}{section.3.5}%
|
||||
\contentsline {chapter}{\numberline {第四章\hspace {.3em}}核心能力与关键机制}{6}{chapter.4}%
|
||||
\contentsline {section}{\numberline {4.1}多APP截图识别与字段抽取}{6}{section.4.1}%
|
||||
\contentsline {section}{\numberline {4.2}关键词回溯驱动的自我完善机制}{7}{section.4.2}%
|
||||
\contentsline {section}{\numberline {4.3}跨平台交易归并与去重}{8}{section.4.3}%
|
||||
\contentsline {section}{\numberline {4.4}本人账户中转识别}{8}{section.4.4}%
|
||||
\contentsline {section}{\numberline {4.5}被骗金额分层认定}{9}{section.4.5}%
|
||||
\contentsline {section}{\numberline {4.6}笔录辅助生成、问询建议与证据化输出}{9}{section.4.6}%
|
||||
\contentsline {chapter}{\numberline {第五章\hspace {.3em}}系统实现与界面展示}{10}{chapter.5}%
|
||||
\contentsline {section}{\numberline {5.1}系统实现概况}{10}{section.5.1}%
|
||||
\contentsline {section}{\numberline {5.2}前端功能页面}{10}{section.5.2}%
|
||||
\contentsline {section}{\numberline {5.3}后端接口与服务实现}{12}{section.5.3}%
|
||||
\contentsline {section}{\numberline {5.4}处理链路实现}{12}{section.5.4}%
|
||||
\contentsline {section}{\numberline {5.5}部署与演示方式}{13}{section.5.5}%
|
||||
\contentsline {chapter}{\numberline {第六章\hspace {.3em}}创新点与方案优势}{13}{chapter.6}%
|
||||
\contentsline {section}{\numberline {6.1}创新点提炼}{13}{section.6.1}%
|
||||
\contentsline {subsection}{\numberline {6.1.1}场景创新}{13}{subsection.6.1.1}%
|
||||
\contentsline {subsection}{\numberline {6.1.2}方法创新}{13}{subsection.6.1.2}%
|
||||
\contentsline {subsection}{\numberline {6.1.3}机制创新}{13}{subsection.6.1.3}%
|
||||
\contentsline {subsection}{\numberline {6.1.4}输出创新}{13}{subsection.6.1.4}%
|
||||
\contentsline {section}{\numberline {6.2}与传统方式对比优势}{14}{section.6.2}%
|
||||
\contentsline {section}{\numberline {6.3}与单点OCR工具对比优势}{14}{section.6.3}%
|
||||
\contentsline {section}{\numberline {6.4}方案优势总结}{14}{section.6.4}%
|
||||
\contentsline {chapter}{\numberline {第七章\hspace {.3em}}应用成效与推广前景}{15}{chapter.7}%
|
||||
\contentsline {section}{\numberline {7.1}应用成效说明}{15}{section.7.1}%
|
||||
\contentsline {subsection}{\numberline {7.1.1}效率提升}{15}{subsection.7.1.1}%
|
||||
\contentsline {subsection}{\numberline {7.1.2}质量提升}{15}{subsection.7.1.2}%
|
||||
\contentsline {subsection}{\numberline {7.1.3}复用提升}{15}{subsection.7.1.3}%
|
||||
\contentsline {section}{\numberline {7.2}答辩展示建议}{15}{section.7.2}%
|
||||
\contentsline {section}{\numberline {7.3}推广前景}{16}{section.7.3}%
|
||||
\contentsline {section}{\numberline {7.4}安全与合规考虑}{16}{section.7.4}%
|
||||
\contentsline {chapter}{\numberline {第八章\hspace {.3em}}结论}{16}{chapter.8}%
|
||||
\contentsline {section}{\numberline {8.1}后续完善建议}{17}{section.8.1}%
|
||||
\contentsline {chapter}{\numberline {附录 A\hspace {.3em}}附录}{17}{appendix.A}%
|
||||
\contentsline {section}{\numberline {A.1}建议替换的图片清单}{17}{section.A.1}%
|
||||
\contentsline {section}{\numberline {A.2}建议替换的数据项}{17}{section.A.2}%
|
||||
\contentsline {section}{\numberline {A.3}编译说明}{18}{section.A.3}%
|
||||
86
docs/competition-book/preamble.tex
Normal file
86
docs/competition-book/preamble.tex
Normal file
@@ -0,0 +1,86 @@
|
||||
\usepackage[a4paper,margin=2.05cm]{geometry}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{array}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{longtable}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{multirow}
|
||||
\usepackage{float}
|
||||
\usepackage{enumitem}
|
||||
\usepackage{hyperref}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{titlesec}
|
||||
\usepackage{caption}
|
||||
\usepackage{setspace}
|
||||
\usepackage{amsmath}
|
||||
|
||||
\setstretch{1.12}
|
||||
\setlength{\parskip}{0.15em}
|
||||
\setlength{\headheight}{15pt}
|
||||
\setlist[itemize]{leftmargin=2em,itemsep=0.25em,topsep=0.3em}
|
||||
\setlist[enumerate]{leftmargin=2.2em,itemsep=0.25em,topsep=0.3em}
|
||||
\raggedbottom
|
||||
|
||||
\hypersetup{
|
||||
colorlinks=true,
|
||||
linkcolor=black,
|
||||
urlcolor=blue!60!black,
|
||||
citecolor=black,
|
||||
pdftitle={智析反诈项目书},
|
||||
pdfauthor={Cursor}
|
||||
}
|
||||
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
\fancyhead[L]{智析反诈项目书}
|
||||
\fancyhead[R]{\leftmark}
|
||||
\fancyfoot[C]{\thepage}
|
||||
|
||||
\makeatletter
|
||||
\renewcommand\chapter{%
|
||||
\par
|
||||
\thispagestyle{plain}%
|
||||
\global\@topnum\z@
|
||||
\@afterindentfalse
|
||||
\secdef\@chapter\@schapter}
|
||||
\makeatother
|
||||
\titleformat{\chapter}{\normalfont\zihao{3}\bfseries}{第\thechapter 章}{1em}{}
|
||||
\titleformat{\section}{\normalfont\zihao{4}\bfseries}{\thesection}{0.8em}{}
|
||||
\titleformat{\subsection}{\normalfont\bfseries}{\thesubsection}{0.8em}{}
|
||||
\titlespacing*{\chapter}{0pt}{0.5em}{0.8em}
|
||||
\titlespacing*{\section}{0pt}{0.8em}{0.5em}
|
||||
\titlespacing*{\subsection}{0pt}{0.6em}{0.4em}
|
||||
|
||||
\captionsetup{
|
||||
font=small,
|
||||
labelfont=bf
|
||||
}
|
||||
|
||||
\newcolumntype{Y}{>{\raggedright\arraybackslash}X}
|
||||
|
||||
\newcommand{\placeholderfigure}[2][0.13\textheight]{
|
||||
\begin{center}
|
||||
\setlength{\fboxsep}{0pt}
|
||||
\fbox{
|
||||
\parbox[c][#1][c]{0.9\textwidth}{
|
||||
\centering
|
||||
\vspace*{0.2em}
|
||||
{\bfseries 图片占位}\\[0.5em]
|
||||
#2
|
||||
}
|
||||
}
|
||||
\end{center}
|
||||
}
|
||||
|
||||
\newcommand{\placeholderwidefigure}[2][0.16\textheight]{
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\placeholderfigure[#1]{#2}
|
||||
\end{figure}
|
||||
}
|
||||
|
||||
\newcommand{\note}[1]{
|
||||
\vspace{0.3em}
|
||||
\noindent\textcolor{blue!60!black}{\textbf{说明：}#1}
|
||||
}
|
||||
416
docs/competition-plan.md
Normal file
416
docs/competition-plan.md
Normal file
@@ -0,0 +1,416 @@
|
||||
# 全国“智慧+警务”AI智能体大赛参赛方案
|
||||
|
||||
## 一、项目名称
|
||||
|
||||
**智析反诈：面向电信网络诈骗案件受害人资金核查的多智能体协同认定系统**
|
||||
|
||||
一句话概括：
|
||||
面向基层派出所电信网络诈骗案件取证环节，围绕“多 APP 账单截图解析、跨平台交易归并、资金路径分析、被骗金额认定、证据化输出”构建多智能体协同系统，显著提升受害人笔录制作、被骗资金核算和证据整理效率与准确率。
|
||||
|
||||
## 二、项目背景与警务痛点
|
||||
|
||||
在电信网络诈骗案件办理中，受害人往往同时提供微信、支付宝、手机银行、数字钱包等多个平台的大量截图。基层民警在制作笔录和核查被骗金额时，通常面临以下问题：
|
||||
|
||||
1. 截图数量大、来源杂，人工逐张查看耗时长。
|
||||
2. 同一笔资金可能在不同 APP、不同页面、不同时间段重复出现，人工极易重复计算或漏算。
|
||||
3. 存在本人账户中转、退款返还、零钱充值、银行卡转入转出等复杂情形，仅凭单张截图难以准确认定是否属于被骗金额。
|
||||
4. 受害人陈述与截图证据之间往往缺乏结构化对应关系，后续复核、汇报、移送、审查起诉都需要重复整理。
|
||||
5. 民警在高强度办案状态下，最缺的不是“看图能力”，而是“自动归集、自动关联、自动解释、自动输出”的整套辅助能力。
|
||||
|
||||
因此，该场景真正需要的并不是单点 OCR 工具，也不是简单的大模型问答，而是一套能够围绕办案目标持续执行、调用工具、跨步推理、输出可复核证据链的警务智能体系统。
|
||||
|
||||
## 三、从专家评审角度看，本项目为什么是真正的“AI 智能体”
|
||||
|
||||
评审专家通常不会只看“是否用了大模型”，而会重点看项目是否具备智能体的核心属性。本项目在本质上符合智能体的关键特征：
|
||||
|
||||
### 1. 目标驱动，而非单步问答
|
||||
|
||||
本项目的任务目标不是“识别一张图片是什么”，而是围绕一个明确警务目标持续推进：
|
||||
|
||||
`从多源截图中，还原交易事实，识别有效证据，认定被骗金额，并生成办案可用结果。`
|
||||
|
||||
系统会围绕该目标自动完成截图理解、字段抽取、去重归并、路径分析、认定分层、人工复核提示、文书输出等连续动作，体现出完整的目标导向执行能力。
|
||||
|
||||
### 2. 具备感知、推理、行动闭环
|
||||
|
||||
智能体的核心不只是“看见”，更是“理解后采取行动”。本项目形成了清晰闭环：
|
||||
|
||||
- 感知：识别不同 APP 截图页面类型、金额、时间、对手方、订单号、账户尾号等要素。
|
||||
- 推理：判断交易之间是否重复、是否属于本人账户中转、是否应计入被骗金额、认定置信度如何。
|
||||
- 行动：自动归并交易、生成资金流图、给出认定理由、提示需补充询问的问题、输出证据化报告。
|
||||
|
||||
### 3. 具备多智能体协同，而非单模型硬做
|
||||
|
||||
单个大模型擅长通用理解，但警务实战需要分工、约束和可控性。本项目将任务拆分为多个能力单元协同完成，避免“一次提示词包打天下”导致的不稳定与不可解释。
|
||||
|
||||
### 4. 具备工具调用与外部系统协作能力
|
||||
|
||||
项目并非停留在对话层，而是实际调用 OCR、多模态识别、规则引擎、数据库、案件管理、报告导出等工具与系统，实现对办案流程的真实嵌入。
|
||||
|
||||
### 5. 具备记忆与上下文持续利用能力
|
||||
|
||||
系统以“案件”为组织单元，将截图、交易记录、认定结果、人工复核状态、报告快照等统一沉淀，支持多轮补充材料后的再次分析与结果更新，这种持续上下文记忆正是智能体区别于一次性脚本的重要特征。
|
||||
|
||||
### 6. 具备基于结果反馈的自我完善能力
|
||||
|
||||
智能体不仅能完成识别和认定，还能基于后续证据理解结果反向修正前序判断。例如，在完成截图证据识别后，系统会对交易页面中出现的高价值关键词进行回溯分析，如“收付款”“转账成功”“账单详情”“商户单号”“退款”“充值”“零钱”“银行卡”等，再结合最终识别出的交易类型、字段结构和认定结果，对账单页面类型判断进行二次校正。
|
||||
|
||||
这种“先识别、再验证、再回溯优化”的机制，本质上是一种轻量级自我完善闭环。它使系统不再停留于单次 OCR 输出，而是能够利用后续证据理解结果持续提升前端账单类型识别准确率，尤其适用于截图质量不高、页面裁切不完整、不同平台 UI 相似导致的误判场景。
|
||||
|
||||
### 7. 具备人机协同与安全兜底机制
|
||||
|
||||
警务场景不能接受“黑盒自动决定”。本项目不是替代民警，而是通过高、中、低置信分层与人工复核机制，实现“机器先归集判断，民警再确认把关”的协同模式，兼顾效率与法律风险控制。
|
||||
|
||||
## 四、项目定位
|
||||
|
||||
本项目的定位不是通用办公助手，不是泛金融风控工具，也不是简单 OCR 平台，而是：
|
||||
|
||||
**面向电信网络诈骗案件受害人资金核查场景的警务专用认定型智能体。**
|
||||
|
||||
它直接服务于基层最刚性的几个环节：
|
||||
|
||||
- 受害人笔录制作前的事实梳理
|
||||
- 被骗金额核算与复核
|
||||
- 交易路径分析
|
||||
- 证据整理与报告输出
|
||||
- 后续流转中的结果复用
|
||||
|
||||
这种定位决定了项目最重要的评价维度应当是：
|
||||
|
||||
- 是否真正解决实战问题
|
||||
- 是否显著降低人工负担
|
||||
- 是否可复核、可追溯、可解释
|
||||
- 是否能嵌入现有办案流程
|
||||
- 是否具备复制推广价值
|
||||
|
||||
## 五、总体技术方案
|
||||
|
||||
### 1. 总体架构思路
|
||||
|
||||
系统采用“多智能体协同 + 规则引擎约束 + 人工复核闭环”的总体架构。
|
||||
|
||||
#### 智能体分工设计
|
||||
|
||||
| 智能体/模块 | 主要职责 | 输出结果 |
|
||||
|------|------|------|
|
||||
| 案件受理智能体 | 接收案件基础信息、受害人陈述、截图材料，建立案件上下文 | 案件任务上下文 |
|
||||
| 截图解析智能体 | 识别截图来源 APP、页面类型、关键字段 | 结构化交易候选记录 |
|
||||
| 跨平台关联智能体 | 按订单号、金额、时间窗口、账户尾号等进行交易归并与去重 | 统一交易视图 |
|
||||
| 资金路径分析智能体 | 识别本人账户中转、收款方聚合、交易方向与流转路径 | 资金流图与路径链条 |
|
||||
| 金额认定智能体 | 依据规则与上下文判断是否计入被骗金额，给出置信度与理由 | 认定清单 |
|
||||
| 笔录辅助智能体 | 基于不确定项与缺失点，自动生成问询建议 | 追问问题清单 |
|
||||
| 证据输出智能体 | 输出表格、报告、文书化摘要、证据索引 | Excel / PDF / Word 报告 |
|
||||
| 人工复核代理 | 对中低置信项进行确认、修改、留痕 | 最终认定结果 |
|
||||
|
||||
### 2. 核心处理流程
|
||||
|
||||
1. 民警创建案件，批量上传多平台账单截图。
|
||||
2. 截图解析智能体自动识别截图类型并提取交易要素。
|
||||
3. 跨平台关联智能体对多截图中的同笔交易进行去重与归并。
|
||||
4. 资金路径分析智能体识别本人账户中转关系，避免重复计入被骗金额。
|
||||
5. 金额认定智能体对每笔交易给出“计入/不计入/待复核”判断，并附带认定理由与置信等级。
|
||||
6. 笔录辅助智能体自动生成针对性问询提示，指导民警补齐证据链。
|
||||
7. 证据输出智能体自动形成汇总清单、路径图、认定报告和审计快照。
|
||||
8. 民警完成复核确认后，形成可用于办案流转的最终结果。
|
||||
|
||||
### 3. 与现有系统能力的对应关系
|
||||
|
||||
从当前项目实现看，系统已具备较完整的落地链路，包括：
|
||||
|
||||
- 案件管理
|
||||
- 多 APP 截图上传与识别
|
||||
- OCR/多模态抽取
|
||||
- 交易字段结构化解析
|
||||
- 交易去重与匹配
|
||||
- 资金流图生成
|
||||
- 认定理由生成
|
||||
- 笔录问询建议生成
|
||||
- 报告导出与结果复核
|
||||
|
||||
这意味着本项目不是“概念方案”，而是已经形成可演示、可运行、可迭代的实战型原型系统。
|
||||
|
||||
## 六、关键能力设计
|
||||
|
||||
### 1. 多 APP 截图自动识别
|
||||
|
||||
针对微信、支付宝、手机银行、数字钱包等不同来源截图，系统自动识别页面类型和关键字段，重点抽取：
|
||||
|
||||
- 交易时间
|
||||
- 交易金额
|
||||
- 收付款方向
|
||||
- 对手方姓名或账号
|
||||
- 本人账户尾号
|
||||
- 订单号
|
||||
- 备注信息
|
||||
- 截图来源平台
|
||||
|
||||
其价值不在于“识别字段本身”，而在于为后续跨平台关联和金额认定奠定统一数据底座。
|
||||
|
||||
### 2. 关键词回溯驱动的 OCR 自我优化
|
||||
|
||||
本项目在截图识别阶段引入了结果反馈式优化机制。系统并非在第一次页面分类后就固定结果，而是在完成证据识别、交易抽取和部分认定后，将已识别出的高置信字段与关键词重新回溯到原始截图类型判断中，对页面类别进行再验证和再修正。
|
||||
|
||||
重点回溯的信息包括：
|
||||
|
||||
- 交易行为关键词，如“转账”“支付”“收款”“充值”“退款”
|
||||
- 页面结构关键词，如“账单详情”“交易记录”“支付成功”“转账到账”
|
||||
- 证据字段关键词，如“订单号”“商户单号”“对方账户”“收款方”“尾号”
|
||||
- 认定结果关联信号，如“该页面最终被识别为对外支付证据”或“该页面更符合本人账户中转凭证”
|
||||
|
||||
这种机制的优势在于：
|
||||
|
||||
- 可以修正首次 OCR 因截图模糊、裁切不全、模板差异造成的页面类型误识别
|
||||
- 可以利用后续证据链结果反向增强前序识别准确率
|
||||
- 可以使系统随着案件处理不断积累“页面类型 - 关键词 - 字段模式”的经验映射
|
||||
|
||||
从智能体视角看，这一机制体现了系统的自我完善能力，即不是一次识别后静态输出，而是在任务执行过程中根据中间结果持续调整前面步骤的判断。
|
||||
|
||||
### 3. 跨平台交易关联与去重
|
||||
|
||||
这是项目区别于普通 OCR 工具的核心能力之一。系统综合以下维度进行去重和归并：
|
||||
|
||||
- 订单号一致
|
||||
- 金额一致
|
||||
- 时间窗口接近
|
||||
- 对手方相同或高度相似
|
||||
- 本人账户尾号一致
|
||||
- 截图来源上下文一致
|
||||
|
||||
该能力可以有效解决同一笔转账在支付成功页、账单详情页、银行流水页中多次出现的重复统计问题。
|
||||
|
||||
### 4. 本人账户中转识别
|
||||
|
||||
在实战中，受害人常先从银行卡充值到微信零钱或支付宝余额，再对外转账；或者在多个本人账户之间中转。若不识别中转关系，就会导致被骗金额被重复累计。
|
||||
|
||||
本项目通过交易方向、时间关系、账户标识、平台关系等线索识别中转行为，将“本人账户内部流转”和“对外实际被骗支付”区分开来，这是办案价值极高的关键设计。
|
||||
|
||||
### 5. 被骗金额认定与分层置信
|
||||
|
||||
项目不直接输出一个“绝对正确”的金额，而是采用更符合实战的证据审查逻辑：
|
||||
|
||||
- 高置信：证据链完整、对外支付明确、重复性低，可优先计入。
|
||||
- 中置信：存在部分证据缺口或上下文不充分，建议民警补充问询后确认。
|
||||
- 低置信：疑似重复、退款、内部转账或证据不足，暂不计入。
|
||||
|
||||
这种机制体现了智能体在警务场景中的专业性和审慎性，避免“大模型看起来很聪明，但结论不适合办案”的问题。
|
||||
|
||||
### 6. 认定理由可解释化
|
||||
|
||||
每笔认定结果都不只是一个金额数字，还附带自然语言理由，例如：
|
||||
|
||||
- 该笔为受害人账户向外部收款方的实际转账，且无重复记录，建议计入被骗金额。
|
||||
- 该笔与另一截图中的订单号一致，疑似同一交易的重复展示，不重复计入。
|
||||
- 该笔表现为本人银行卡向本人支付账户充值，属于中转资金，不直接计入被骗金额。
|
||||
|
||||
这使结果具备可解释性、可汇报性和可复核性。
|
||||
|
||||
### 7. 笔录问询辅助
|
||||
|
||||
项目还能自动提出下一步问询重点，例如：
|
||||
|
||||
- 是否还存在未提供截图的支付平台或银行账户？
|
||||
- 某几笔中置信交易的具体操作背景是什么？
|
||||
- 是否存在部分返还、退款或追回？
|
||||
- 是否还有 ATM、柜台或他人代转等转账方式？
|
||||
|
||||
这意味着系统不仅帮助“算钱”，还帮助“补证据、补事实、补笔录”。
|
||||
|
||||
### 8. 证据化输出
|
||||
|
||||
项目最终输出的不是一个聊天答案，而是一套办案可用成果：
|
||||
|
||||
- 结构化交易清单
|
||||
- 被骗金额认定明细
|
||||
- 资金流转关系图
|
||||
- 证据索引
|
||||
- 文书化摘要
|
||||
- 审计快照与人工复核痕迹
|
||||
|
||||
这非常契合警务工作“重结果、更重依据”的实际要求。
|
||||
|
||||
## 七、项目亮点提炼
|
||||
|
||||
如果从比赛评审展示角度提炼，本项目至少有以下亮点：
|
||||
|
||||
### 亮点一：选题非常“基层”、非常“刚需”
|
||||
|
||||
项目聚焦派出所民警最常见、最耗时、最容易出错的诈骗资金核查环节，问题真实、频次高、痛点强，具有极强的实战导向。
|
||||
|
||||
### 亮点二：不是做聊天机器人，而是做“办案任务型智能体”
|
||||
|
||||
项目以案件处理目标为中心，具备任务分解、协同执行、工具调用、结果回写、人工复核等能力，符合 AI 智能体的发展方向。
|
||||
|
||||
### 亮点三：把“看图识别”升级为“证据推理”
|
||||
|
||||
真正难点不在 OCR，而在于跨平台关联、路径还原、重复剔除、金额认定。本项目抓住了比赛中更容易打动专家的深层价值。
|
||||
|
||||
### 亮点四：结果可解释、可追溯、可复核
|
||||
|
||||
评审专家尤其关注警务 AI 的可靠性与风险控制。本项目通过置信分层、理由说明、人工复核、审计留痕等设计，使系统输出具备证据属性，而非黑盒结论。
|
||||
|
||||
### 亮点五：能直接嵌入现有办案流程
|
||||
|
||||
从案件创建、截图上传、分析、复核到报告导出，链路完整，便于在基层单位以“小切口、快落地”的方式推广。
|
||||
|
||||
### 亮点六：具备复制推广空间
|
||||
|
||||
该框架不仅适用于电诈受害人资金核查，还可扩展至：
|
||||
|
||||
- 帮助信息网络犯罪活动案件资金梳理
|
||||
- 非法集资、网络赌博等涉网资金分析
|
||||
- 行政案件中的电子支付证据整理
|
||||
- 其他多源截图证据归集场景
|
||||
|
||||
## 八、项目创新点
|
||||
|
||||
从赛事评审偏好的“创新性”维度看，建议重点突出以下创新：
|
||||
|
||||
### 1. 场景创新
|
||||
|
||||
将 AI 智能体深度应用于电诈案件受害人资金认定这一高频、刚需、长期依赖人工经验的基层警务场景，具有鲜明的行业创新价值。
|
||||
|
||||
### 2. 方法创新
|
||||
|
||||
采用“多智能体协同 + 规则引擎约束 + 人工复核兜底”的混合式范式，不走纯规则僵化路线，也不走纯大模型黑盒路线，兼顾灵活性与可控性。
|
||||
|
||||
进一步引入“证据识别后关键词回溯”的结果反馈机制，让系统能够利用后续高置信证据反向修正账单页面类型识别，体现出智能体在任务执行过程中的自我校正与自我完善能力。
|
||||
|
||||
### 3. 数据组织创新
|
||||
|
||||
将非结构化截图证据转化为可计算、可关联、可解释、可复用的案件级结构化资产，实现从“图片材料”到“证据数据”的跃迁。
|
||||
|
||||
### 4. 认定逻辑创新
|
||||
|
||||
把办案中的“被骗金额认定”拆解为多因素综合判断过程，以置信分层和认定理由表达证据充分度，贴近真实司法审查思维。
|
||||
|
||||
### 5. 输出形态创新
|
||||
|
||||
不是止步于智能识别结果，而是进一步形成图、表、文、问询建议、审计快照等多种输出，为办案流程提供完整支撑。
|
||||
|
||||
## 九、项目实战价值与预期成效
|
||||
|
||||
建议在正式提交材料时，用真实数据替换下列占位内容，以增强说服力。
|
||||
|
||||
### 1. 效率提升
|
||||
|
||||
- 单案截图整理时间由 **[原平均时长]** 降低至 **[现平均时长]**
|
||||
- 被骗金额核算时间由 **[原平均时长]** 降低至 **[现平均时长]**
|
||||
- 笔录前事实梳理效率提升 **[X]%**
|
||||
|
||||
### 2. 质量提升
|
||||
|
||||
- 重复计算问题显著减少
|
||||
- 漏算、误算情况明显下降
|
||||
- 交易认定结果的一致性提升
|
||||
- 后续复核、汇报、移送环节的材料复用率提升
|
||||
|
||||
### 3. 办案支撑价值
|
||||
|
||||
- 为民警快速锁定关键转账链条提供依据
|
||||
- 为问询受害人提供结构化提示
|
||||
- 为报案受理、案件研判、案卷整理提供统一底稿
|
||||
|
||||
### 4. 管理价值
|
||||
|
||||
- 沉淀案件级结构化资金数据
|
||||
- 形成标准化、可复用、可统计的实战能力
|
||||
- 为后续跨案件研判和模型优化积累高质量样本
|
||||
|
||||
## 十、比赛展示时建议重点讲清的“评审关注点”
|
||||
|
||||
### 1. 先讲痛点，不要先讲技术
|
||||
|
||||
建议答辩开场直接从基层民警日常工作切入：
|
||||
|
||||
“受害人带来几十张、上百张支付截图，涉及多个 APP。人工逐张核对不仅耗时，而且极易重算、漏算，直接影响笔录质量和被骗金额认定效率。本项目就是围绕这一高频痛点设计的实战型智能体系统。”
|
||||
|
||||
### 2. 强调项目不是普通 OCR
|
||||
|
||||
建议明确指出：
|
||||
|
||||
“OCR 只能解决读字问题，不能解决跨平台关联、本人账户中转识别、被骗金额认定和证据化输出问题。本项目的核心创新在于把截图识别升级为案件级证据推理。”
|
||||
|
||||
### 3. 强调项目不是单大模型问答
|
||||
|
||||
建议表达为：
|
||||
|
||||
“本项目不是让一个大模型直接给出答案，而是将任务分解为多个智能体协同处理，并用规则、流程和人工复核机制保证结果可控、可解释、可用于办案。”
|
||||
|
||||
### 4. 强调可落地、可推广
|
||||
|
||||
建议突出：
|
||||
|
||||
- 基层单位直接可用
|
||||
- 与现有办案流程衔接自然
|
||||
- 不要求改变民警工作习惯
|
||||
- 可以从反诈场景向其他涉案资金核查场景扩展
|
||||
|
||||
## 十一、建议的答辩展示结构
|
||||
|
||||
### 1. 30 秒项目定义
|
||||
|
||||
用一句话讲清楚：
|
||||
|
||||
“这是一个面向电诈案件受害人资金核查场景的多智能体协同系统，能够自动解析多 APP 账单截图，关联交易、识别中转、认定被骗金额，并输出可复核证据结果。”
|
||||
|
||||
### 2. 1 分钟问题描述
|
||||
|
||||
展示基层民警在大量截图整理、核算被骗金额时的真实工作痛点。
|
||||
|
||||
### 3. 1 分钟系统流程展示
|
||||
|
||||
建议按以下顺序演示：
|
||||
|
||||
截图上传 -> 自动识别 -> 交易归并 -> 资金路径图 -> 认定结果 -> 问询建议 -> 报告导出
|
||||
|
||||
### 4. 1 分钟亮点与创新
|
||||
|
||||
重点讲：
|
||||
|
||||
- 多智能体协同
|
||||
- 跨平台关联去重
|
||||
- 本人账户中转识别
|
||||
- 置信分层与人工复核
|
||||
- 证据化输出
|
||||
|
||||
### 5. 1 分钟成效与推广价值
|
||||
|
||||
补充实战使用效果、效率提升、准确率提升、可复制推广空间。
|
||||
|
||||
## 十二、建议的提交文案摘要
|
||||
|
||||
以下内容可作为申报书摘要的基础版本：
|
||||
|
||||
> 针对电信网络诈骗案件中受害人多平台账单截图数量大、核查耗时长、重复统计和漏算风险高等问题，项目构建了面向基层警务实战的多智能体协同认定系统。系统围绕案件任务目标，自动完成多 APP 截图识别、交易字段抽取、跨平台关联去重、本人账户中转识别、被骗金额分层认定、问询建议生成和证据化报告输出，形成“感知-推理-行动-复核”闭环。项目突出可解释、可追溯、可复核、可落地，能够显著提升受害人笔录制作和被骗资金核算效率，降低人工误差，具有较强的实战应用价值和推广前景。
|
||||
|
||||
## 十三、项目落地与合规性说明
|
||||
|
||||
警务智能体要想获得专家认可，必须提前回应安全与合规问题。建议在材料中明确写明：
|
||||
|
||||
1. 系统仅面向授权办案场景使用，不面向社会公众开放。
|
||||
2. 案件数据按最小必要原则采集与处理。
|
||||
3. 支持本地化部署或专网部署，避免敏感数据外流风险。
|
||||
4. 智能体输出仅作为办案辅助意见，最终认定由民警依法审核确认。
|
||||
5. 关键分析过程保留日志、快照和人工复核记录，便于责任追溯。
|
||||
|
||||
## 十四、专家评审最容易被打动的总结表达
|
||||
|
||||
如果要用一段话概括项目竞争力，建议使用如下表述：
|
||||
|
||||
> 本项目的价值，不在于让 AI “看懂一张截图”，而在于让 AI 真正参与到基层反诈案件最繁琐、最容易出错、最需要经验判断的资金核查环节中。它把分散、零碎、重复的截图证据，转化为可关联、可解释、可复核的案件结论，既解决了一线民警的现实痛点，也体现了 AI 智能体从通用能力走向警务实战能力的典型路径。
|
||||
|
||||
## 十五、后续建议补充的材料
|
||||
|
||||
为了让参赛材料更有竞争力，建议你后续再补充以下内容：
|
||||
|
||||
1. 真实案例一例：截图数量、涉及 APP 数量、人工耗时、系统耗时、最终认定金额。
|
||||
2. 对比数据一组：人工处理与系统辅助处理的效率和差错率对比。
|
||||
3. 演示视频一段：完整展示从上传截图到报告输出的闭环。
|
||||
4. 界面截图若干：案件页、截图页、交易页、分析页、复核页、报告页。
|
||||
5. 部署说明一份：本地/专网部署、权限控制、数据留痕、安全策略。
|
||||
|
||||
---
|
||||
|
||||
## 附：一句话参赛口号
|
||||
|
||||
**让碎片化截图证据，自动变成可认定、可复核、可办案的资金事实。**
|
||||
11
docs/project-book/.gitignore
vendored
11
docs/project-book/.gitignore
vendored
@@ -1,11 +0,0 @@
|
||||
# LaTeX 编译产物
|
||||
build/
|
||||
*.aux
|
||||
*.log
|
||||
*.toc
|
||||
*.out
|
||||
*.bbl
|
||||
*.blg
|
||||
*.synctex.gz
|
||||
*.fls
|
||||
*.fdb_latexmk
|
||||
@@ -1,19 +0,0 @@
|
||||
# 智析反诈 项目书 - LaTeX 编译
|
||||
# 使用: make 或 make pdf
|
||||
|
||||
MAIN = main
|
||||
LATEX = xelatex
|
||||
BUILD_DIR = build
|
||||
|
||||
.PHONY: pdf clean
|
||||
|
||||
pdf: $(MAIN).tex
|
||||
@mkdir -p $(BUILD_DIR)
|
||||
$(LATEX) -output-directory=$(BUILD_DIR) -interaction=nonstopmode $(MAIN).tex
|
||||
$(LATEX) -output-directory=$(BUILD_DIR) -interaction=nonstopmode $(MAIN).tex
|
||||
@cp $(BUILD_DIR)/$(MAIN).pdf . 2>/dev/null || true
|
||||
@echo "PDF 已生成: $(BUILD_DIR)/$(MAIN).pdf"
|
||||
|
||||
clean:
|
||||
rm -rf $(BUILD_DIR)
|
||||
rm -f *.aux *.log *.toc *.out *.bbl *.blg *.synctex.gz
|
||||
@@ -1,21 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
# 智析反诈 项目书 - 一键编译脚本
|
||||
# 使用: bash build.sh
|
||||
|
||||
set -e
|
||||
cd "$(dirname "$0")"
|
||||
|
||||
MAIN=main
|
||||
BUILD_DIR=build
|
||||
|
||||
mkdir -p "$BUILD_DIR"
|
||||
xelatex -output-directory="$BUILD_DIR" -interaction=nonstopmode "$MAIN.tex" || true
|
||||
xelatex -output-directory="$BUILD_DIR" -interaction=nonstopmode "$MAIN.tex"
|
||||
|
||||
if [ -f "$BUILD_DIR/$MAIN.pdf" ]; then
|
||||
cp "$BUILD_DIR/$MAIN.pdf" .
|
||||
echo "PDF 已生成: $BUILD_DIR/$MAIN.pdf"
|
||||
else
|
||||
echo "编译可能有问题，请检查 $BUILD_DIR 目录下的 .log 文件"
|
||||
exit 1
|
||||
fi
|
||||
@@ -1 +0,0 @@
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
% ============================================================
|
||||
% 第一章 引言
|
||||
% 对应评审维度：需求与场景适配、应用价值
|
||||
% ============================================================
|
||||
|
||||
\chapter{引言}
|
||||
|
||||
\section{目标用户与典型场景概述}
|
||||
|
||||
本项目面向基层派出所、反诈中心及刑侦部门的办案民警。在电信网络诈骗案件办理中，民警需要受理受害人报案、制作笔录、核查资金流向并认定被骗金额。受害人通常会提供大量来自微信、支付宝、银行卡、短信通知等不同来源的账单截图，民警需逐张查看、登记、汇总、排重、计算。这一环节是典型的高频、耗时、易错场景，也是本系统的核心目标用户与典型使用场景。第三章将详细展开目标用户画像与典型使用场景。
|
||||
|
||||
\section{项目背景}
|
||||
|
||||
电信网络诈骗案件持续高发，基层民警在受害人报案受理、资金核查、笔录制作过程中，面临大量来自不同APP的账单截图。现有工作模式主要依赖人工逐张查看、登记、汇总、排重、计算，存在效率低、重复统计、认定不统一、证据整理负担重等问题。
|
||||
|
||||
为破解该痛点，本项目面向受害人资金核查实战，研发多智能体协同的截图证据解析与被骗金额认定系统，实现多源截图自动识别、跨平台关联、资金路径分析、认定复核和文书化输出，服务电诈案件快速、规范、可追溯办理。
|
||||
|
||||
\section{研究/建设目标}
|
||||
|
||||
本项目的建设目标凝练为三项：
|
||||
|
||||
\begin{enumerate}[label=(\arabic*)]
|
||||
\item \textbf{自动化}：让截图证据从人工整理转向自动识别和结构化处理
|
||||
\item \textbf{规范化}：让被骗金额认定从经验判断转向规则化、可解释化输出
|
||||
\item \textbf{实战化}：让分析结果直接服务笔录制作、资金核查和案件材料生成
|
||||
\end{enumerate}
|
||||
|
||||
\section{文档结构说明}
|
||||
|
||||
本项目的结构安排如下：第二章介绍背景与现状；第三章进行需求分析；第四章描述系统架构设计；第五章阐述关键实现；第六章总结创新点与特色；第七章讨论应用成效与评估；第八章为总结与展望。附录提供API端点、数据库模型、图清单、初选录屏说明及答辩常见问题与建议回答。
|
||||
@@ -1,52 +0,0 @@
|
||||
% ============================================================
|
||||
% 第二章 背景与现状
|
||||
% 对应评审维度：需求与场景适配、应用价值
|
||||
% ============================================================
|
||||
|
||||
\chapter{背景与现状}
|
||||
|
||||
\section{电信诈骗受害人资金核查业务流程}
|
||||
|
||||
典型的电信诈骗案件资金核查流程可概括为：受案 $\to$ 笔录制作 $\to$ 核账 $\to$ 认定 $\to$ 报卷。受害人在报案时通常提供微信、支付宝、银行卡、短信通知等截图作为转账凭证。民警需要将这些零散证据整理为可追溯、可认定的资金流水，并回答执法层面的关键问题：哪些钱可以认定为被骗金额，理由是什么，证据在哪里。
|
||||
|
||||
\section{传统人工模式的瓶颈}
|
||||
|
||||
传统人工核账模式下，民警逐张查看截图、手动登记交易信息、人工判断重复与中转、计算被骗金额并撰写认定理由。该模式存在以下瓶颈：
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item 截图来源杂：微信、支付宝、银行卡、短信、数字钱包混杂
|
||||
\item 截图数量大：一案几十张到上百张截图
|
||||
\item 重复统计风险高：同一笔交易跨平台多次出现
|
||||
\item 中转情形复杂：本人账户过渡、充值提现、退款混杂
|
||||
\item 认定理由依赖经验：标准不统一
|
||||
\item 结果需反复整理：表格、笔录、报告重复劳动重
|
||||
\end{itemize}
|
||||
|
||||
% 图 2-1 占位
|
||||
\placeholderfigure{Fig-traditional-flow.pdf}{传统人工核账流程图}
|
||||
|
||||
\section{痛点与影响对照}
|
||||
|
||||
表\ref{tab:pain-points} 归纳了传统模式下的主要痛点及其影响。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{痛点与影响对照表}
|
||||
\label{tab:pain-points}
|
||||
\begin{tabular}{lll}
|
||||
\toprule
|
||||
\textbf{痛点} & \textbf{具体表现} & \textbf{影响} \\
|
||||
\midrule
|
||||
截图来源杂 & 微信、支付宝、银行、短信等混杂 & 分类与整理耗时 \\
|
||||
截图数量大 & 一案数十至上百张 & 人工逐张登记极耗时间 \\
|
||||
重复统计 & 同笔交易跨平台多次出现 & 易重复累计被骗金额 \\
|
||||
中转复杂 & 本人账户过渡、自充、退款 & 易错认、易漏排 \\
|
||||
认定不统一 & 依赖个人经验 & 口径不一致、难以复核 \\
|
||||
文书整理重 & 表格、笔录、报告反复整理 & 重复劳动多 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{智慧警务与 AI 智能体发展趋势}
|
||||
|
||||
智慧警务建设强调技术赋能基层、减负增效。AI 智能体具备目标导向、环境感知、规划执行、工具调用和反馈闭环等特征，适合承担高重复、高耗时的信息抽取与初判任务，而将最终确认权、补证权、修正权保留给民警。本项目正是在此背景下，将多智能体协同技术应用于电诈受害人资金核查这一垂直警务场景。
|
||||
@@ -1,100 +0,0 @@
|
||||
% ============================================================
|
||||
% 第三章 需求分析
|
||||
% 对应评审维度：需求与场景适配、技术可行性
|
||||
% ============================================================
|
||||
|
||||
\chapter{需求分析}
|
||||
|
||||
\section{目标用户画像}
|
||||
|
||||
本系统的主要目标用户包括：
|
||||
|
||||
\begin{enumerate}[label=(\arabic*)]
|
||||
\item \textbf{派出所一线民警}：受理电诈报案，制作笔录，完成资金核查初核
|
||||
\item \textbf{反诈中心办案人员}：统筹多案资金分析，复核认定结论
|
||||
\item \textbf{刑侦/经侦办案人员}：涉诈资金链梳理、多账户资金归集
|
||||
\end{enumerate}
|
||||
|
||||
\section{典型使用场景}
|
||||
|
||||
表\ref{tab:use-scenarios} 以「角色 + 任务 + 痛点 + 本系统介入方式」的形式描述典型使用场景。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{典型使用场景}
|
||||
\label{tab:use-scenarios}
|
||||
\begin{tabular}{p{2cm}p{2.5cm}p{2.5cm}p{3cm}}
|
||||
\toprule
|
||||
\textbf{角色} & \textbf{任务} & \textbf{痛点} & \textbf{本系统介入} \\
|
||||
\midrule
|
||||
派出所民警 & 受理电诈报案后核账 & 截图多、重复统计、认定难 & 批量上传、自动去重、认定初判 \\
|
||||
派出所民警 & 制作笔录前梳理资金 & 需人工整理表格、问询无依据 & 导出汇总表、生成问询建议 \\
|
||||
反诈中心 & 复核多案认定结论 & 口径不统一、证据链难追溯 & 结构化字段、认定理由、证据索引 \\
|
||||
刑侦/经侦 & 涉诈资金链分析 & 多账户、多平台流水混杂 & 跨平台关联、资金流图、路径分析 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
% 图 3-1 占位
|
||||
\placeholderfigure{Fig-user-usecase.pdf}{用户角色与用例示意}
|
||||
|
||||
\section{业务需求}
|
||||
|
||||
系统需支持以下核心业务能力：
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item 案件管理：创建、查看、更新案件信息
|
||||
\item 截图上传：批量上传多APP账单截图
|
||||
\item 截图解析：自动识别APP类型、页面类型，提取交易字段
|
||||
\item 交易归并：去重、聚类、识别本人账户中转
|
||||
\item 资金分析：资金流转关系图、交易时间轴、收款方聚合
|
||||
\item 认定复核：高/中/低置信分层，人工复核确认，自动生成认定理由
|
||||
\item 笔录辅助：基于分析结果生成笔录问询建议
|
||||
\item 报告导出：Excel 汇总表、PDF 报告、Word 文书，含证据索引和审计快照
|
||||
\end{itemize}
|
||||
|
||||
\section{功能需求}
|
||||
|
||||
表\ref{tab:func-req} 列出主要功能需求。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{功能需求列表}
|
||||
\label{tab:func-req}
|
||||
\begin{tabular}{cll}
|
||||
\toprule
|
||||
\textbf{编号} & \textbf{功能} & \textbf{说明} \\
|
||||
\midrule
|
||||
F1 & 案件管理 & 创建、查看、更新案件 \\
|
||||
F2 & 截图上传 & 批量上传，支持多格式 \\
|
||||
F3 & 截图分类 & 识别来源APP、页面类型 \\
|
||||
F4 & 交易抽取 & OCR 提取标准化交易字段 \\
|
||||
F5 & 交易去重 & 订单号、金额+时间窗口去重 \\
|
||||
F6 & 中转识别 & 识别本人账户中转 \\
|
||||
F7 & 认定分层 & 高/中/低置信，纳入/排除/待复核 \\
|
||||
F8 & 人工复核 & 确认、修正、留痕 \\
|
||||
F9 & 问询建议 & 基于认定结果生成笔录建议 \\
|
||||
F10 & 报告导出 & Excel、Word、PDF \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{非功能需求}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{非功能需求}
|
||||
\label{tab:nfr}
|
||||
\begin{tabular}{lll}
|
||||
\toprule
|
||||
\textbf{类别} & \textbf{需求} & \textbf{说明} \\
|
||||
\midrule
|
||||
性能 & 批量处理 & 支持数十张截图并发解析 \\
|
||||
性能 & 响应时间 & 单张解析在可接受延迟内完成 \\
|
||||
安全 & 数据隔离 & 按案件隔离存储 \\
|
||||
安全 & 审计留痕 & 分析、复核、修改记录可追溯 \\
|
||||
合规 & 本地部署 & 支持专网/本地化部署 \\
|
||||
合规 & 可解释性 & 认定理由、排除依据可追溯 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@@ -1,93 +0,0 @@
|
||||
% ============================================================
|
||||
% 第四章 系统架构设计
|
||||
% 对应评审维度：技术可行性、技术深度、作品完整性
|
||||
% ============================================================
|
||||
|
||||
\chapter{系统架构设计}
|
||||
|
||||
\section{总体架构}
|
||||
|
||||
系统采用四层架构：证据接入层、智能体协同层、案件推理层、结果输出层。
|
||||
|
||||
\begin{enumerate}[label=(\arabic*)]
|
||||
\item \textbf{证据接入层}：微信、支付宝、银行、短信、数字钱包等截图批量上传
|
||||
\item \textbf{智能体协同层}：编排智能体统一调度各专业智能体
|
||||
\item \textbf{案件推理层}：去重、关联、中转识别、认定评分、人工复核
|
||||
\item \textbf{结果输出层}：资金流图、交易明细、认定结论、问询建议、证据化报告
|
||||
\end{enumerate}
|
||||
|
||||
% 图 4-1 占位
|
||||
\placeholderfigure{Fig-architecture.pdf}{系统四层架构图}
|
||||
|
||||
\section{多智能体分工}
|
||||
|
||||
系统由以下八个专业智能体协同完成案件处理：
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item \textbf{案件编排智能体}：接收案件目标，规划处理步骤，调度各子智能体
|
||||
\item \textbf{截图理解智能体}：识别截图所属APP、页面类型、截图有效性
|
||||
\item \textbf{交易抽取智能体}：将账单截图解析为标准化交易记录
|
||||
\item \textbf{跨平台关联智能体}：识别同一交易在不同平台的重复呈现
|
||||
\item \textbf{资金路径分析智能体}：识别本人账户中转、分流、汇聚
|
||||
\item \textbf{被骗金额认定智能体}：纳入/排除/待复核判定，生成认定理由
|
||||
\item \textbf{文书与笔录辅助智能体}：输出认定说明、问询建议、证据化报告
|
||||
\item \textbf{人工复核协同智能体}：将低置信与争议记录提交民警确认
|
||||
\end{itemize}
|
||||
|
||||
% 图 4-2 占位
|
||||
\placeholderfigure{Fig-agent-collab.pdf}{多智能体协作示意图}
|
||||
|
||||
\section{核心业务流程}
|
||||
|
||||
核心业务流程为：上传 $\to$ 解析 $\to$ 分析 $\to$ 复核 $\to$ 报告。具体包括：新建案件、批量上传截图、自动识别来源与页面类型、自动抽取交易字段、自动去重与中转识别、生成资金路径与被骗金额初判、民警对低置信记录复核、一键导出汇总表与问询建议。
|
||||
|
||||
% 图 4-3 占位
|
||||
\placeholderfigure{Fig-business-flow.pdf}{核心业务流程}
|
||||
|
||||
\section{技术选型}
|
||||
|
||||
表\ref{tab:tech-stack} 列出技术栈。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{技术栈一览}
|
||||
\label{tab:tech-stack}
|
||||
\begin{tabular}{ll}
|
||||
\toprule
|
||||
\textbf{层级} & \textbf{技术} \\
|
||||
\midrule
|
||||
前端 & React 18, TypeScript, Ant Design, ECharts, TanStack Query, Zustand \\
|
||||
后端 & Python, FastAPI, SQLAlchemy 2.x (async), Pydantic v2 \\
|
||||
数据库 & PostgreSQL 16 \\
|
||||
队列 & Celery, Redis 7 \\
|
||||
AI 能力 & 云 OCR / 多模态大模型 API（可配置） \\
|
||||
报告 & openpyxl, python-docx \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{设计目标与实现情况对照}
|
||||
|
||||
表\ref{tab:design-vs-impl} 对照设计目标与当前实现情况，体现作品完整性。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{设计目标 vs 实现情况}
|
||||
\label{tab:design-vs-impl}
|
||||
\begin{tabular}{lp{4cm}p{4cm}}
|
||||
\toprule
|
||||
\textbf{功能模块} & \textbf{设计目标} & \textbf{实现情况} \\
|
||||
\midrule
|
||||
案件管理 & 创建、查看、更新案件 & 已实现 \\
|
||||
截图上传 & 批量上传多 APP 截图 & 已实现 \\
|
||||
截图分类 & 识别 APP、页面类型 & 已实现（OCR/多模态） \\
|
||||
交易抽取 & 标准化字段提取 & 已实现 \\
|
||||
交易去重 & 订单号、金额+时间窗口 & 已实现 \\
|
||||
中转识别 & 本人账户中转排除 & 已实现 \\
|
||||
认定分层 & 高/中/低置信 & 已实现 \\
|
||||
人工复核 & 确认、修正、留痕 & 已实现 \\
|
||||
问询建议 & 笔录辅助生成 & 已实现 \\
|
||||
报告导出 & Excel、Word、PDF & 已实现 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@@ -1,74 +0,0 @@
|
||||
% ============================================================
|
||||
% 第五章 关键实现
|
||||
% 对应评审维度：技术深度、技术可行性
|
||||
% ============================================================
|
||||
|
||||
\chapter{关键实现}
|
||||
|
||||
\section{截图理解与交易抽取}
|
||||
|
||||
系统采用多模态大模型 API 完成截图分类与交易字段抽取。首先识别截图所属 APP（微信、支付宝、银行、数字钱包等）及页面类型（账单列表、详情、转账回执等），再根据页面类型调用相应抽取策略，输出标准化交易记录。
|
||||
|
||||
抽取字段包括：交易时间、金额、收支方向、对手方名称/账号、本方账户尾号、订单号、备注、识别置信度。输出为结构化数据，支持可计算、可追溯、可比对、可复核。
|
||||
|
||||
% 图 5-1 占位
|
||||
\placeholderfigure{Fig-extract-fields.pdf}{交易抽取字段与置信度示意}
|
||||
|
||||
\section{跨平台关联与去重}
|
||||
|
||||
去重逻辑基于规则引擎实现，主要包括：订单号一致则判定为重复；金额与时间窗口相近且对手方一致时可聚类。聚类后保留置信度最高的一条为主记录，其余标记为重复。本人账户中转识别通过比对对手方与本方已知账户实现，标记为「中转」的交易不纳入被骗金额累计。
|
||||
|
||||
% 图 5-2 占位
|
||||
\placeholderfigure{Fig-dedup-transit.pdf}{去重与中转识别逻辑示意}
|
||||
|
||||
\section{被骗金额认定}
|
||||
|
||||
认定逻辑结合规则与 LLM 辅助：规则负责纳入/排除边界控制（如本人账户中转排除、收入方向排除等）；LLM 负责生成更规范的认定理由与问询建议。每笔交易输出高/中/低置信分层，低置信记录进入人工复核流程。
|
||||
|
||||
\section{报告生成}
|
||||
|
||||
报告服务支持导出 Excel、Word、PDF 三种格式，内容可包含：被骗金额汇总、交易明细、认定理由与排除说明、笔录辅助问询建议。报告保留版本快照，支持证据索引与审计追踪。
|
||||
|
||||
\section{交易结构化字段定义}
|
||||
|
||||
表\ref{tab:tx-fields} 定义交易结构化字段。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{交易结构化字段定义}
|
||||
\label{tab:tx-fields}
|
||||
\begin{tabular}{llp{5cm}}
|
||||
\toprule
|
||||
\textbf{字段} & \textbf{类型} & \textbf{说明} \\
|
||||
\midrule
|
||||
trade\_time & datetime & 交易时间，格式 YYYY-MM-DD HH:MM:SS \\
|
||||
amount & decimal & 金额（元） \\
|
||||
direction & enum & in / out \\
|
||||
counterparty\_name & string & 对手方名称 \\
|
||||
counterparty\_account & string & 对手方账号 \\
|
||||
self\_account\_tail\_no & string & 本方账户尾号 \\
|
||||
order\_no & string & 订单号 \\
|
||||
remark & string & 备注 \\
|
||||
confidence & float & 识别置信度 0--1 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{认定置信度分层}
|
||||
|
||||
表\ref{tab:confidence} 说明认定置信度分层及对应处理策略。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{认定置信度分层说明}
|
||||
\label{tab:confidence}
|
||||
\begin{tabular}{llp{4cm}}
|
||||
\toprule
|
||||
\textbf{等级} & \textbf{含义} & \textbf{处理策略} \\
|
||||
\midrule
|
||||
高 & 明确可纳入被骗金额 & 可直接确认 \\
|
||||
中 & 需结合案情判断 & 建议人工复核 \\
|
||||
低 & 建议排除或待核实 & 必须人工复核 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@@ -1,66 +0,0 @@
|
||||
% ============================================================
|
||||
% 第六章 创新点与特色
|
||||
% 对应评审维度：创新点、创新程度
|
||||
% ============================================================
|
||||
|
||||
\chapter{创新点与特色}
|
||||
|
||||
\section{传统模式 vs 本方案对照}
|
||||
|
||||
表\ref{tab:traditional-vs-ours} 逐条对比传统模式与本方案，突出创新与突破。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{传统模式 vs 本方案对照}
|
||||
\label{tab:traditional-vs-ours}
|
||||
\begin{tabular}{lp{4cm}p{4cm}}
|
||||
\toprule
|
||||
\textbf{维度} & \textbf{传统模式} & \textbf{本方案} \\
|
||||
\midrule
|
||||
截图处理 & 人工逐张查看、手写登记 & 多智能体自动分类、OCR 抽取 \\
|
||||
重复识别 & 人工凭记忆比对 & 跨平台关联、订单号/金额+时间去重 \\
|
||||
中转识别 & 依赖经验、易漏 & 规则引擎+已知账户比对 \\
|
||||
认定逻辑 & 个人经验、口径不一 & 规则化+LLM 辅助，可解释 \\
|
||||
输出形态 & 手工整理表格、笔录 & 一键导出 Excel/Word/PDF，含证据索引 \\
|
||||
复核机制 & 无系统化留痕 & 高/中/低置信分层，人工复核闭环 \\
|
||||
工作流 & 民警全量核账 & AI 初判 + 民警重点复核 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{多智能体协同创新}
|
||||
|
||||
将截图理解、交易抽取、关联分析、金额认定、文书生成拆分为专业智能体，由编排智能体协同调度，形成案件目标驱动的闭环处理流程。每个智能体只解决一类专业问题，输出可结构化传递，符合警务场景可管可控要求。
|
||||
|
||||
\section{跨平台资金证据关联创新}
|
||||
|
||||
面向微信、支付宝、银行卡、短信等多源截图，识别同笔交易的跨平台重复表达，实现资金证据自动关联和去重，直接解决「重复统计」这一实战高频痛点。
|
||||
|
||||
\section{被骗金额认定创新}
|
||||
|
||||
不止识别流水，而是围绕执法需要，结合规则和上下文对每笔交易进行纳入、排除、待复核判断，并生成认定理由与排除依据。
|
||||
|
||||
\section{证据化输出与人机协同}
|
||||
|
||||
将智能分析结果转化为可复核、可导出、可纳入案卷的报告和问询材料。同时强调人机协同：AI 负责高强度初判，民警保留最终确认权，低置信结果主动提交人工复核。
|
||||
|
||||
\section{AI 智能体五特征与本项目对应}
|
||||
|
||||
表\ref{tab:agent-features} 说明本项目如何符合 AI 智能体的五个核心特征。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{AI 智能体五特征与本项目对应关系}
|
||||
\label{tab:agent-features}
|
||||
\begin{tabular}{ll}
|
||||
\toprule
|
||||
\textbf{智能体特征} & \textbf{本项目体现} \\
|
||||
\midrule
|
||||
目标导向 & 以「受害人被骗金额认定」为目标，非单纯识图 \\
|
||||
环境感知 & 感知微信、支付宝、银行、短信等多源截图证据 \\
|
||||
规划执行 & 依次完成分类、抽取、去重、关联、分析、认定、输出 \\
|
||||
工具调用 & 调用 OCR、多模态模型、规则引擎、数据库、报表导出 \\
|
||||
反馈闭环 & 低置信结果进入人工复核，保留修正记录 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@@ -1,64 +0,0 @@
|
||||
% ============================================================
|
||||
% 第七章 应用成效与评估
|
||||
% 对应评审维度：应用价值、警务/教育适配性
|
||||
% ============================================================
|
||||
|
||||
\chapter{应用成效与评估}
|
||||
|
||||
\section{应用场景与试点情况}
|
||||
|
||||
系统面向基层派出所、反诈中心及刑侦部门，适用于电信诈骗受害人资金核查、涉诈资金链梳理、涉赌资金流水分析、经侦案件多账户资金归集等场景。【占位：如有试点，请在此处补充试点单位、时间、案件数量等。】
|
||||
|
||||
\section{成效指标}
|
||||
|
||||
表\ref{tab:metrics} 列出建议跟踪的成效指标，实测数据列供用户填写。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{成效指标}
|
||||
\label{tab:metrics}
|
||||
\begin{tabular}{llll}
|
||||
\toprule
|
||||
\textbf{指标} & \textbf{说明} & \textbf{预期方向} & \textbf{实测数据} \\
|
||||
\midrule
|
||||
单案核查时间 & 从上传到出报告 & 压缩 & \placeholdercell \\
|
||||
人工录入工作量 & 民警手工录入比例 & 下降 & \placeholdercell \\
|
||||
重复交易识别 & 准确率/召回率 & 提升 & \placeholdercell \\
|
||||
本人账户中转识别 & 准确率 & 提升 & \placeholdercell \\
|
||||
认定一致性 & 多案/多人认定一致性 & 提升 & \placeholdercell \\
|
||||
报告生成时间 & 从确认到导出 & 缩短 & \placeholdercell \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\textbf{指标参考口径}：传统人工核查需 2--4 小时的案件，系统可在数分钟内完成初步结构化和归并分析；多平台重复交易自动识别后，重复统计风险明显下降；民警由「全量逐条核对」转为「聚焦争议记录复核」，工作重心明显优化。
|
||||
|
||||
% 图 7-1, 7-2, 7-3 占位
|
||||
\placeholderfigure{Fig-main-ui.png}{系统主界面截图}
|
||||
|
||||
\placeholderfigure{Fig-review-ui.png}{分析/复核界面截图}
|
||||
|
||||
\placeholderfigure{Fig-report-sample.png}{报告导出样例截图}
|
||||
|
||||
\section{应用价值与推广路径}
|
||||
|
||||
\textbf{应用价值}：对基层民警减负增效；对案件办理提升认定规范性、完整性和可解释性；对智慧警务构建可推广、可复制的反诈资金核查智能体范式。
|
||||
|
||||
\textbf{推广路径}：派出所试点 $\to$ 反诈中心推广 $\to$ 刑侦/经侦扩展。系统流程标准、通用性强，可根据不同单位部署条件选择本地化或专网化落地。
|
||||
|
||||
\section{警务/教育适配性}
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item \textbf{警校特色}：来源于基层民警真实办案需求，可结合反诈课程、实训教学使用
|
||||
\item \textbf{落地价值}：支持本地化/专网部署，符合公安信息安全要求
|
||||
\item \textbf{数据安全}：案件数据按案隔离，证据与报告全流程留痕
|
||||
\item \textbf{可解释可信}：每笔认定可追溯至原始截图，人工拥有最终确认权
|
||||
\end{itemize}
|
||||
|
||||
\section{安全合规与可信设计}
|
||||
|
||||
\begin{enumerate}[label=(\arabic*)]
|
||||
\item \textbf{数据安全}：按案管理、隔离存储；支持本地/专网部署；模型接口可切换
|
||||
\item \textbf{权限与审计}：区分上传、复核、导出权限；保留分析时间、复核人、修改记录；报告版本快照
|
||||
\item \textbf{可信 AI}：低置信不直接下结论；人工最终确认；认定理由可解释；结果可追溯
|
||||
\end{enumerate}
|
||||
@@ -1,24 +0,0 @@
|
||||
% ============================================================
|
||||
% 第八章 总结与展望
|
||||
% ============================================================
|
||||
|
||||
\chapter{总结与展望}
|
||||
|
||||
\section{项目总结}
|
||||
|
||||
本项目聚焦电信网络诈骗案件受害人资金核查这一基层高频、耗时、易错场景，构建多智能体协同的截图证据解析与被骗金额认定系统。系统围绕案件目标，自动完成多 APP 账单截图识别、交易字段抽取、跨平台重复关联、本人账户中转识别、资金路径分析、被骗金额认定和证据化报告输出，并通过人工复核机制保障结果可信可控。
|
||||
|
||||
项目不是单点 OCR 工具，而是面向警务实战的垂直智能体系统，能够显著提升资金核查效率、规范认定标准、减轻基层负担，具备较强的实战价值、推广价值和示范意义。
|
||||
|
||||
\section{推广前景}
|
||||
|
||||
本项目面向基层高频警务场景，具有显著的通用性和可复制性。系统能力不仅适用于电信诈骗受害人资金核查，还可扩展应用于涉诈资金链梳理、涉赌资金流水分析、经侦案件多账户资金归集等场景，具备在派出所、反诈中心、刑侦部门等多层级单位推广应用的潜力。
|
||||
|
||||
\section{后续计划}
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item 持续优化 OCR 与抽取准确率
|
||||
\item 扩展更多 APP 与页面类型的识别支持
|
||||
\item 深化资金路径分析与可视化
|
||||
\item 推进试点落地与效果数据采集
|
||||
\end{itemize}
|
||||
@@ -1,31 +0,0 @@
|
||||
% ============================================================
|
||||
% 附录 A：API 端点一览
|
||||
% ============================================================
|
||||
|
||||
\chapter{API 端点一览}
|
||||
\label{app:api}
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{系统主要 API 端点}
|
||||
\begin{tabular}{lll}
|
||||
\toprule
|
||||
\textbf{端点} & \textbf{方法} & \textbf{功能} \\
|
||||
\midrule
|
||||
/api/v1/cases & GET, POST & 案件列表 / 创建 \\
|
||||
/api/v1/cases/\{id\} & GET, PATCH & 案件详情 / 更新 \\
|
||||
/api/v1/cases/\{id\}/images & GET, POST & 截图列表 / 上传 \\
|
||||
/api/v1/images/\{id\} & GET & 截图详情 + OCR 结果 \\
|
||||
/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{tabular}
|
||||
\end{table}
|
||||
|
||||
API 文档可通过访问 \texttt{/docs} 获取交互式 Swagger 文档。
|
||||
@@ -1,23 +0,0 @@
|
||||
% ============================================================
|
||||
% 附录 B：数据库/模型简要说明
|
||||
% ============================================================
|
||||
|
||||
\chapter{数据库/模型简要说明}
|
||||
\label{app:models}
|
||||
|
||||
\section{核心数据模型}
|
||||
|
||||
主要数据模型包括：
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item \textbf{Case}：案件，含案件编号、状态、创建时间等
|
||||
\item \textbf{EvidenceImage}：证据截图，含来源 APP、页面类型、存储路径、OCR 状态
|
||||
\item \textbf{TransactionRecord}：交易记录，含时间、金额、方向、对手方、订单号、是否重复、是否中转等
|
||||
\item \textbf{TransactionCluster}：交易聚类，用于去重后的主记录关联
|
||||
\item \textbf{FraudAssessment}：被骗金额认定，含置信等级、认定金额、理由、复核状态
|
||||
\item \textbf{ExportReport}：导出报告，含类型（Excel/Word/PDF）、路径、版本、内容快照
|
||||
\end{itemize}
|
||||
|
||||
\section{案件状态流转}
|
||||
|
||||
案件状态包括：\texttt{draft}（草稿）、\texttt{analyzing}（分析中）、\texttt{reviewing}（复核中）、\texttt{closed}（已关闭）。
|
||||
@@ -1,36 +0,0 @@
|
||||
% ============================================================
|
||||
% 附录 C：图清单与占位说明
|
||||
% 供用户按图补充，对应评审维度：技术可行性
|
||||
% ============================================================
|
||||
|
||||
\chapter{图清单与占位说明}
|
||||
\label{app:figures}
|
||||
|
||||
以下为正文中需要用户提供的图片清单。请根据 \texttt{figures/README.md} 中的说明准备相应图片，并替换占位框。
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\caption{图清单与占位说明}
|
||||
\begin{tabular}{clp{5cm}}
|
||||
\toprule
|
||||
\textbf{图号} & \textbf{建议文件名} & \textbf{建议内容} \\
|
||||
\midrule
|
||||
图 2-1 & Fig-traditional-flow.pdf & 传统人工核账流程图 \\
|
||||
图 3-1 & Fig-user-usecase.pdf & 用户角色与用例示意 \\
|
||||
图 4-1 & Fig-architecture.pdf & 系统四层架构图 \\
|
||||
图 4-2 & Fig-agent-collab.pdf & 多智能体协作示意图 \\
|
||||
图 4-3 & Fig-business-flow.pdf & 核心业务流程 \\
|
||||
图 5-1 & Fig-extract-fields.pdf & 交易抽取字段与置信度示意 \\
|
||||
图 5-2 & Fig-dedup-transit.pdf & 去重与中转识别逻辑示意 \\
|
||||
图 7-1 & Fig-main-ui.png & 系统主界面截图 \\
|
||||
图 7-2 & Fig-review-ui.png & 分析/复核界面截图 \\
|
||||
图 7-3 & Fig-report-sample.png & 报告导出样例截图 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
将图片放入 \texttt{figures/} 目录后，可在对应章节中将 \texttt{\textbackslash placeholderfigure} 替换为：
|
||||
|
||||
\begin{lstlisting}
|
||||
\includegraphics[width=0.9\textwidth]{文件名}
|
||||
\end{lstlisting}
|
||||
@@ -1,34 +0,0 @@
|
||||
% ============================================================
|
||||
% 附录 D：初选录屏说明
|
||||
% 对应评审维度：技术可行性（录屏效果清晰）
|
||||
% ============================================================
|
||||
|
||||
\chapter{初选录屏说明}
|
||||
\label{app:video}
|
||||
|
||||
初选阶段需提交系统演示录屏。建议按以下规范准备，以体现架构合理、核心功能可实现、录屏效果清晰。
|
||||
|
||||
\section{建议时长}
|
||||
|
||||
总时长建议 3--5 分钟，覆盖「一案跑到底」的完整闭环。
|
||||
|
||||
\section{建议流程与关键时间点}
|
||||
|
||||
\begin{enumerate}[label=(\arabic*)]
|
||||
\item 新建案件（约 0:00--0:30）
|
||||
\item 批量上传多 APP 截图（约 0:30--1:00）
|
||||
\item 系统自动识别截图来源和页面类型（约 1:00--1:30）
|
||||
\item 自动抽取交易字段（约 1:30--2:00）
|
||||
\item 自动去重与中转识别（约 2:00--2:30）
|
||||
\item 生成资金路径与被骗金额初判（约 2:30--3:00）
|
||||
\item 对低置信记录进行人工复核（约 3:00--3:30）
|
||||
\item 一键导出被骗金额汇总和问询建议（约 3:30--4:00）
|
||||
\end{enumerate}
|
||||
|
||||
\section{录屏质量要求}
|
||||
|
||||
\begin{itemize}[leftmargin=*]
|
||||
\item 分辨率清晰，界面文字可辨认
|
||||
\item 操作连贯，无长时间黑屏或卡顿
|
||||
\item 关键步骤有适当停顿或标注，便于评审理解
|
||||
\end{itemize}
|
||||
@@ -1,31 +0,0 @@
|
||||
% ============================================================
|
||||
% 附录 E：答辩常见问题与建议回答
|
||||
% 对应评审维度：现场表现
|
||||
% ============================================================
|
||||
|
||||
\chapter{答辩常见问题与建议回答}
|
||||
\label{app:qa}
|
||||
|
||||
\section{与普通 OCR 的区别}
|
||||
|
||||
\textbf{问}：你这个项目和普通 OCR 报销系统有什么区别？
|
||||
|
||||
\textbf{答}：普通 OCR 系统解决的是「识别内容」，本项目解决的是「围绕案件目标认定被骗金额」。系统不仅做截图识别，还做跨平台关联、本人账户中转识别、认定理由生成、人工复核和证据化输出，核心是执法业务闭环而不是识别本身。
|
||||
|
||||
\section{为何采用多智能体}
|
||||
|
||||
\textbf{问}：为什么要做多智能体，不直接用一个大模型？
|
||||
|
||||
\textbf{答}：因为本场景同时包含视觉识别、结构化抽取、交易关联、规则推理、文书生成等异构任务。采用多智能体分工后，每一步更稳定、可解释、可替换，也更符合警务场景可管可控要求。
|
||||
|
||||
\section{识别错误的处理}
|
||||
|
||||
\textbf{问}：如果模型识别错了怎么办？
|
||||
|
||||
\textbf{答}：系统会输出置信度，并把低置信和争议记录交由民警复核；同时保留原始截图、抽取字段、认定理由和修正记录，确保结论不是黑箱生成，而是可追溯、可校正的。
|
||||
|
||||
\section{推广条件}
|
||||
|
||||
\textbf{问}：这个项目是否具备推广条件？
|
||||
|
||||
\textbf{答}：该项目面向基层反诈案件高频场景，流程标准、通用性强，并已具备前后端原型、案件流程、异步分析、报告导出等基础能力，可根据不同单位部署条件选择本地化或专网化落地，具备较强推广价值。
|
||||
@@ -1,43 +0,0 @@
|
||||
# 项目书图片占位说明
|
||||
|
||||
请将以下图片放入本目录，并在对应章节中替换占位框。图片需用户自行提供或制作。
|
||||
|
||||
## 图片清单与评审维度对应
|
||||
|
||||
| 文件名 | 对应图号 | 建议内容 | 对应评审维度 |
|
||||
|--------|----------|----------|--------------|
|
||||
| Fig-traditional-flow.pdf | 图 2-1 | 传统人工核账流程图 | 需求与场景适配 |
|
||||
| Fig-user-usecase.pdf | 图 3-1 | 用户角色与用例示意 | 需求与场景适配 |
|
||||
| Fig-architecture.pdf | 图 4-1 | 系统四层架构图 | 技术可行性、技术深度 |
|
||||
| Fig-agent-collab.pdf | 图 4-2 | 多智能体协作示意图 | 技术可行性、创新点 |
|
||||
| Fig-business-flow.pdf | 图 4-3 | 核心业务流程（上传→解析→分析→复核→报告） | 技术可行性 |
|
||||
| Fig-extract-fields.pdf | 图 5-1 | 交易抽取字段与置信度示意 | 技术深度 |
|
||||
| Fig-dedup-transit.pdf | 图 5-2 | 去重与中转识别逻辑示意 | 技术深度 |
|
||||
| Fig-main-ui.png | 图 7-1 | 系统主界面截图 | 应用价值、作品完整性 |
|
||||
| Fig-review-ui.png | 图 7-2 | 分析/复核界面截图 | 应用价值、作品完整性 |
|
||||
| Fig-report-sample.png | 图 7-3 | 报告导出样例截图 | 应用价值、作品完整性 |
|
||||
|
||||
## 替换说明
|
||||
|
||||
将图片放入本目录后，在对应章节的 `.tex` 文件中，将：
|
||||
|
||||
```latex
|
||||
\placeholderfigure{文件名}{图题}
|
||||
```
|
||||
|
||||
替换为：
|
||||
|
||||
```latex
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.9\textwidth]{文件名}
|
||||
\caption{图题}
|
||||
\label{fig:xxx}
|
||||
\end{figure}
|
||||
```
|
||||
|
||||
注意：`\graphicspath` 已配置为 `figures/`，直接使用文件名即可（如 `Fig-main-ui`）。
|
||||
|
||||
## 可选占位图
|
||||
|
||||
可放置 `placeholder.pdf` 作为统一占位图，在尚未准备好正式图片时使用 `\includegraphics{figures/placeholder}` 引用。
|
||||
@@ -1,78 +0,0 @@
|
||||
% ============================================================
|
||||
% 智析反诈 - 电信网络诈骗案件受害人资金核查多智能体系统
|
||||
% 全国「智慧+警务」AI智能体大赛 项目书
|
||||
% ============================================================
|
||||
|
||||
\input{preamble}
|
||||
|
||||
\begin{document}
|
||||
|
||||
% ------------------------------------------------------------
|
||||
% 封面
|
||||
% ------------------------------------------------------------
|
||||
\begin{titlepage}
|
||||
\centering
|
||||
\vspace*{2cm}
|
||||
|
||||
% 单位 logo 占位
|
||||
% 【占位：请在此处插入单位 logo，如 \includegraphics[height=2cm]{logo.png}】
|
||||
\vspace{2cm}
|
||||
|
||||
{\LARGE\bfseries 智析反诈}\\[0.5cm]
|
||||
{\Large 电信网络诈骗案件受害人资金核查多智能体系统}\\[1cm]
|
||||
{\large 多APP账单截图自动解析、资金路径分析与被骗金额认定智能体}\\[2cm]
|
||||
|
||||
{\large 项目书}\\[2cm]
|
||||
|
||||
\begin{tabular}{ll}
|
||||
申报单位： & 【占位：请填写】 \\
|
||||
团队成员： & 【占位：请填写】 \\
|
||||
完成日期： & \today \\
|
||||
\end{tabular}
|
||||
|
||||
\vfill
|
||||
{\small 全国「智慧+警务」AI智能体大赛}
|
||||
\end{titlepage}
|
||||
|
||||
% ------------------------------------------------------------
|
||||
% 摘要
|
||||
% ------------------------------------------------------------
|
||||
\chapter*{摘要}
|
||||
\addcontentsline{toc}{chapter}{摘要}
|
||||
|
||||
随着电信网络诈骗案件持续高发，基层民警在受害人报案受理、资金核查、笔录制作过程中，需要面对大量来自微信、支付宝、银行卡、短信通知等不同来源的账单截图。现有工作模式主要依赖人工逐张查看、登记、汇总、排重、计算，存在效率低、重复统计、认定不统一、证据整理负担重等问题。
|
||||
|
||||
本项目面向受害人资金核查实战，研发多智能体协同的截图证据解析与被骗金额认定系统。系统围绕案件目标，自动完成多APP账单截图识别、交易字段抽取、跨平台重复关联、本人账户中转识别、资金路径分析、被骗金额认定和证据化报告输出，并通过人工复核机制保障结果可信可控。项目不是单点OCR工具，而是面向警务实战的垂直智能体系统，能够显著提升资金核查效率、规范认定标准、减轻基层负担，具备较强的实战价值、推广价值和示范意义。
|
||||
|
||||
\vspace{0.5cm}
|
||||
\noindent\textbf{关键词：}多智能体协同；电信诈骗；资金核查；被骗金额认定；证据化输出；人机协同
|
||||
|
||||
% ------------------------------------------------------------
|
||||
% 目录
|
||||
% ------------------------------------------------------------
|
||||
\tableofcontents
|
||||
\clearpage
|
||||
|
||||
% ------------------------------------------------------------
|
||||
% 正文章节
|
||||
% ------------------------------------------------------------
|
||||
\input{chapters/01-introduction}
|
||||
\input{chapters/02-background}
|
||||
\input{chapters/03-demand-analysis}
|
||||
\input{chapters/04-architecture}
|
||||
\input{chapters/05-implementation}
|
||||
\input{chapters/06-innovation}
|
||||
\input{chapters/07-evaluation}
|
||||
\input{chapters/08-conclusion}
|
||||
|
||||
% ------------------------------------------------------------
|
||||
% 附录
|
||||
% ------------------------------------------------------------
|
||||
\appendix
|
||||
\input{chapters/appendix-a-api}
|
||||
\input{chapters/appendix-b-models}
|
||||
\input{chapters/appendix-c-figures}
|
||||
\input{chapters/appendix-d-video}
|
||||
\input{chapters/appendix-e-qa}
|
||||
|
||||
\end{document}
|
||||
@@ -1,80 +0,0 @@
|
||||
% ============================================================
|
||||
% 智析反诈 项目书 - LaTeX 导言区
|
||||
% ============================================================
|
||||
|
||||
% 文档类
|
||||
\documentclass[12pt,a4paper]{report}
|
||||
|
||||
% 中文支持（ctex 自动检测系统字体）
|
||||
\usepackage{ctex}
|
||||
|
||||
% 版式
|
||||
\usepackage[top=2.5cm,bottom=2.5cm,left=2.5cm,right=2.5cm,headheight=14pt]{geometry}
|
||||
\usepackage{fancyhdr}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
\fancyhead[C]{\small 智析反诈：电信网络诈骗案件受害人资金核查多智能体系统}
|
||||
\fancyfoot[C]{\thepage}
|
||||
\renewcommand{\headrulewidth}{0.4pt}
|
||||
|
||||
% 图表
|
||||
\usepackage{graphicx}
|
||||
\usepackage{float}
|
||||
\usepackage{caption}
|
||||
\usepackage{subcaption}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{multirow}
|
||||
\usepackage{longtable}
|
||||
\graphicspath{{./figures/}{../figures/}}
|
||||
|
||||
% 表格与列表
|
||||
\usepackage{array}
|
||||
\usepackage{multicol}
|
||||
\usepackage{enumitem}
|
||||
|
||||
% 链接与交叉引用
|
||||
\usepackage{hyperref}
|
||||
\usepackage{color}
|
||||
\hypersetup{
|
||||
colorlinks=true,
|
||||
linkcolor=blue,
|
||||
citecolor=blue,
|
||||
urlcolor=blue,
|
||||
pdfstartview=FitH,
|
||||
}
|
||||
|
||||
% 代码（可选）
|
||||
\usepackage{listings}
|
||||
\lstset{
|
||||
basicstyle=\ttfamily\small,
|
||||
breaklines=true,
|
||||
frame=single,
|
||||
numbers=left,
|
||||
numberstyle=\tiny,
|
||||
}
|
||||
|
||||
% 数学
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amssymb}
|
||||
|
||||
% 流程图（可选）
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes.geometric,arrows.meta,positioning,fit}
|
||||
|
||||
% 自定义命令：占位图
|
||||
\newcommand{\placeholderfigure}[2]{
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\fbox{\parbox{0.85\textwidth}{
|
||||
\centering\vspace{3cm}
|
||||
【占位：请在此处插入 #2】
|
||||
\par\vspace{0.5cm}
|
||||
\small 建议文件名：#1
|
||||
\vspace{3cm}
|
||||
}}
|
||||
\caption{#2}
|
||||
\end{figure}
|
||||
}
|
||||
|
||||
% 自定义命令：表格占位
|
||||
\newcommand{\placeholdercell}{\multicolumn{1}{c}{（待补充）}}
|
||||
@@ -1 +0,0 @@
|
||||
|
||||
@@ -1,324 +0,0 @@
|
||||
# 全国“智慧+警务”AI智能体大赛10页PPT大纲与讲稿
|
||||
|
||||
## 使用说明
|
||||
|
||||
本文档面向比赛路演场景设计，默认控制在 **8-10 分钟** 左右。
|
||||
每页内容分为三部分：
|
||||
|
||||
- **本页标题**：建议直接作为 PPT 页标题使用
|
||||
- **页面展示要点**：建议放在 PPT 上的文字内容
|
||||
- **讲稿**：建议现场讲解时口述的内容
|
||||
|
||||
整体讲述逻辑遵循：
|
||||
|
||||
**实战痛点 -> 方案提出 -> 智能体架构 -> 业务闭环 -> 创新亮点 -> 实战成效 -> 安全可信 -> 推广价值**
|
||||
|
||||
---
|
||||
|
||||
## 第1页 项目封面与核心定位
|
||||
|
||||
### 本页标题
|
||||
|
||||
**智析反诈：电信网络诈骗案件受害人资金核查多智能体系统**
|
||||
|
||||
副标题建议：
|
||||
|
||||
**多APP账单截图自动解析、资金路径分析与被骗金额认定智能体**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 面向电信网络诈骗案件受害人资金核查场景
|
||||
- 聚焦多APP截图自动识别、跨平台关联、金额认定、证据化输出
|
||||
- 项目定位：垂直警务智能体系统
|
||||
- 核心价值：更快、更准、更规范、更可追溯
|
||||
|
||||
### 讲稿
|
||||
|
||||
各位评委好，我们带来的项目是“智析反诈：电信网络诈骗案件受害人资金核查多智能体系统”。
|
||||
|
||||
这个项目来源于基层派出所电诈案件办理中的真实痛点。受害人往往会提供大量微信、支付宝、银行卡、短信通知等截图，民警需要逐张查看、逐笔登记、反复核对、人工计算被骗金额，不仅耗时，而且容易出现重复统计、遗漏统计和认定口径不一致的问题。
|
||||
|
||||
我们要解决的，不是单纯的截图识别问题，而是围绕案件办理目标，构建一个能够自动完成截图证据解析、跨平台交易关联、资金路径分析、被骗金额认定和证据化输出的多智能体协同系统，把传统人工核账模式升级为可复核、可解释、可出证的智能办案模式。
|
||||
|
||||
---
|
||||
|
||||
## 第2页 基层实战痛点与传统模式瓶颈
|
||||
|
||||
### 本页标题
|
||||
|
||||
**基层反诈资金核查面临的真实难题**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 截图来源杂：微信、支付宝、银行、短信、数字钱包混杂
|
||||
- 截图数量大：一案几十张到上百张截图
|
||||
- 重复统计风险高：同一笔交易跨平台多次出现
|
||||
- 中转情形复杂：本人账户过渡、充值提现、退款混杂
|
||||
- 人工整理负担重：核账、笔录、表格、报告反复重复劳动
|
||||
- 认定标准依赖经验：不同人、不同案件口径不一致
|
||||
|
||||
### 讲稿
|
||||
|
||||
基层民警在办理电诈案件时，一个非常高频但又非常繁琐的环节，就是受害人资金核查。
|
||||
|
||||
第一，截图来源非常杂。受害人提供的不只是一个平台，而是微信、支付宝、银行卡明细、短信通知，甚至还有数字钱包或者其他支付平台。
|
||||
|
||||
第二，截图数量很大。一些案件里，几十张截图是常态，复杂一点的案件上百张也很常见。
|
||||
|
||||
第三，重复统计风险非常高。同一笔交易，可能在转账详情页出现一次，在账单列表里出现一次，在银行短信里再出现一次。如果全靠人工核对，极易重复累计。
|
||||
|
||||
第四，本人账户中转、自充、退款、正常消费等情形夹杂其中，哪些该算被骗金额，哪些应该排除，既考验经验，也容易出错。
|
||||
|
||||
第五，核账完成以后，民警还要把结果继续整理到笔录、表格和报告中，重复劳动非常重。
|
||||
|
||||
所以，这个场景本质上是一个高频、刚需、耗时、易错的典型基层警务难题。
|
||||
|
||||
---
|
||||
|
||||
## 第3页 项目目标与总体解决思路
|
||||
|
||||
### 本页标题
|
||||
|
||||
**从“人工翻截图”到“智能体闭环核查”**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 目标不是识别截图，而是认定被骗金额
|
||||
- 建立“截图证据解析 -> 交易结构化 -> 关联分析 -> 认定复核 -> 报告输出”闭环
|
||||
- 以案件目标驱动，不以单点功能驱动
|
||||
- 保留人工最终确认权，构建人机协同模式
|
||||
|
||||
### 讲稿
|
||||
|
||||
针对上述痛点，我们提出的总体思路是，把零散的截图处理动作，重构成一条围绕案件目标运行的智能工作流。
|
||||
|
||||
这条工作流的核心不是“看懂一张图”，而是回答一个执法层面的关键问题，也就是：哪些交易可以认定为被骗金额，证据在哪里，理由是什么。
|
||||
|
||||
因此，我们将整个流程设计为五个连续阶段。首先是截图证据解析，其次是交易结构化抽取，然后是跨平台关联和资金路径分析，再往后是被骗金额认定和人工复核，最后输出能够直接服务办案的汇总表、问询建议和证据化报告。
|
||||
|
||||
这意味着项目从一开始就不是一个单点工具，而是一个面向案件办理闭环的警务智能体系统。同时我们强调，人机协同而不是全自动替代，AI负责高强度、高重复工作，民警保留最终确认权。
|
||||
|
||||
---
|
||||
|
||||
## 第4页 多智能体协同架构
|
||||
|
||||
### 本页标题
|
||||
|
||||
**多智能体分工协作，围绕案件目标持续行动**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 案件编排智能体：统一规划与调度
|
||||
- 截图理解智能体：识别APP、页面类型、有效性
|
||||
- 交易抽取智能体：提取标准化交易字段
|
||||
- 跨平台关联智能体：识别重复交易与映射关系
|
||||
- 资金路径分析智能体：识别本人账户中转和流转链路
|
||||
- 被骗金额认定智能体：进行纳入、排除、待复核判断
|
||||
- 文书生成智能体：输出问询建议和证据化报告
|
||||
- 人工复核协同智能体：承接低置信和争议记录
|
||||
|
||||
### 讲稿
|
||||
|
||||
本项目的核心创新之一，就是采用多智能体协同，而不是让一个模型完成所有任务。
|
||||
|
||||
最上层是案件编排智能体，它围绕案件目标进行任务规划和流程调度。它知道当前案件进行到哪一步，也知道什么时候应该调用识别能力，什么时候应该进入关联分析，什么时候应该把结果交由人工复核。
|
||||
|
||||
在它下面，是多个职责清晰的专业智能体。截图理解智能体负责判断这张图来自哪个APP、属于账单列表还是详情页；交易抽取智能体负责把截图转换成标准化交易记录；跨平台关联智能体负责识别同一笔交易在不同平台和不同截图中的重复呈现；资金路径分析智能体负责识别本人账户中转和链路节点；被骗金额认定智能体负责做纳入、排除和待复核判断；最后由文书生成智能体输出可直接用于办案的结果。
|
||||
|
||||
当系统遇到低置信或争议情况时，人工复核协同智能体会把最值得关注的问题提交给民警确认，形成完整闭环。
|
||||
|
||||
---
|
||||
|
||||
## 第5页 核心业务流程演示
|
||||
|
||||
### 本页标题
|
||||
|
||||
**一个案件如何在系统中跑完整个闭环**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
建议这一页配流程图：
|
||||
|
||||
- 新建案件
|
||||
- 批量上传多APP截图
|
||||
- 自动识别截图来源和页面类型
|
||||
- 自动抽取交易时间、金额、方向、对手方、订单号等字段
|
||||
- 自动去重、聚类、识别本人账户中转
|
||||
- 自动生成资金路径和被骗金额初判
|
||||
- 民警对低置信记录进行复核
|
||||
- 一键导出汇总表、问询建议、证据化报告
|
||||
|
||||
### 讲稿
|
||||
|
||||
这一页建议用一个案件跑通全流程，向评委展示系统的闭环能力。
|
||||
|
||||
首先，民警新建案件并上传受害人提供的多APP截图。系统接收到截图后，会自动判断截图来源和页面类型，识别哪些是有效账单截图，哪些可能是无效或重复截图。
|
||||
|
||||
接下来，系统会对有效截图进行结构化抽取，把交易时间、金额、收支方向、对手方名称、订单号、备注等字段统一标准化。标准化以后，系统开始做跨平台匹配和去重，避免同一笔交易重复累计，同时识别本人账户中转等不应直接计入被骗金额的情形。
|
||||
|
||||
然后，系统会输出被骗金额初判结果，并把结果按高、中、低置信度分层展示。民警只需要重点复核低置信和争议记录，而不必从头逐条核算。最后，系统可以一键导出被骗金额汇总表、笔录辅助问询建议以及 Word、Excel、PDF 报告，实现从截图到文书的完整办案闭环。
|
||||
|
||||
---
|
||||
|
||||
## 第6页 核心创新点
|
||||
|
||||
### 本页标题
|
||||
|
||||
**项目的四个核心创新**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 创新一：多智能体协同，不是单模型问答
|
||||
- 创新二：跨平台重复交易自动关联与去重
|
||||
- 创新三：围绕执法需求的被骗金额认定与理由生成
|
||||
- 创新四：从截图识别直达证据化报告输出
|
||||
|
||||
### 讲稿
|
||||
|
||||
如果从比赛评审视角总结，这个项目至少有四个核心创新点。
|
||||
|
||||
第一，是多智能体协同创新。我们不是做一个提示词很长的大模型问答，而是把截图理解、交易抽取、关联分析、认定判断、文书生成拆成多个专业智能体，由编排智能体统一调度。这种方式更稳定、更可解释，也更符合警务场景可管可控的要求。
|
||||
|
||||
第二，是跨平台资金证据关联创新。系统能够识别同一笔交易在不同APP、不同截图中的重复表达关系，避免重复统计，这是基层实战中极具价值的能力。
|
||||
|
||||
第三，是被骗金额认定创新。很多系统只能做到流水识别，但我们进一步把输出提升为执法层面的认定结论，包括纳入、排除、待复核三类结果，并给出每笔交易的认定理由和排除依据。
|
||||
|
||||
第四，是证据化输出创新。系统最终输出的不是一句结论，而是带有来源截图、结构化字段、认定说明和复核状态的可导出报告，能够直接服务笔录制作和案件材料整理。
|
||||
|
||||
---
|
||||
|
||||
## 第7页 为什么这是真正的AI智能体
|
||||
|
||||
### 本页标题
|
||||
|
||||
**本项目符合AI智能体的五个核心特征**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 目标导向：目标是被骗金额认定，不是单纯识图
|
||||
- 环境感知：理解多APP、多页面、多证据载体输入
|
||||
- 规划执行：完成分类、抽取、去重、分析、认定、输出
|
||||
- 工具调用：调用OCR、规则引擎、数据库、报告引擎
|
||||
- 反馈闭环：低置信结果进入人工复核与修正
|
||||
|
||||
### 讲稿
|
||||
|
||||
这一页是答辩时非常关键的一页，因为很多评委都会问一个问题：你这个项目为什么叫智能体，而不只是一个用了大模型的软件。
|
||||
|
||||
我们的回答很明确。第一，它是目标导向的，系统不是为识别而识别，而是围绕“被骗金额认定”这一案件目标持续行动。第二，它具备环境感知能力，能够理解来自不同APP、不同页面类型、不同证据载体的输入信息。第三，它会做规划和执行，把复杂任务拆分成分类、抽取、关联、推理、输出等多个步骤。第四，它会调用工具，不只是生成文字，而是要调用OCR、多模态模型、规则引擎、数据库和报表组件。第五，它具备反馈闭环，低置信结果不会直接当成结论，而是进入人工复核。
|
||||
|
||||
因此，本项目本质上不是“让模型回答问题”，而是让智能体围绕案件目标持续调度能力、完成证据核查闭环。
|
||||
|
||||
---
|
||||
|
||||
## 第8页 实战应用成效与价值
|
||||
|
||||
### 本页标题
|
||||
|
||||
**对基层民警、案件办理、智慧警务的三重价值**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 对基层民警：减负增效，减少机械性核账劳动
|
||||
- 对案件办理：提升认定规范性、完整性、可解释性
|
||||
- 对智慧警务：形成可复制、可推广的警务智能体范式
|
||||
- 典型成效表达：
|
||||
- 核查时间显著压缩
|
||||
- 重复统计风险明显下降
|
||||
- 民警从全量核对转向重点复核
|
||||
- 文书整理效率明显提升
|
||||
|
||||
### 讲稿
|
||||
|
||||
从应用价值看，这个项目至少有三层意义。
|
||||
|
||||
第一，对基层民警来说，它直接解决了高频、重复、机械的截图核账工作。过去大量时间耗在翻截图、记流水、对表格，现在可以把这些工作交给系统自动完成，民警只需要把精力放在重点复核和案件判断上。
|
||||
|
||||
第二，对案件办理来说，它提升的是认定规范性。系统会对每笔交易给出来源、字段、理由和状态，减少口径不统一、重复累计和遗漏统计的情况，使被骗金额认定更加完整、可解释、可追溯。
|
||||
|
||||
第三，对智慧警务来说，这不仅是一个场景应用，更是一种警务智能体建设范式。它证明AI不只是辅助问答，而是可以进入案件处理闭环，承接真实业务目标，形成可复制、可推广的实战能力。
|
||||
|
||||
如果现场允许，这一页也可以补充阶段性效果数据，例如核查耗时压缩比例、重复识别准确率、民警满意度等，让说服力更强。
|
||||
|
||||
---
|
||||
|
||||
## 第9页 安全可信与人机协同机制
|
||||
|
||||
### 本页标题
|
||||
|
||||
**坚持可解释、可复核、可追溯的警务AI原则**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 不追求黑箱全自动，强调人机协同
|
||||
- 高/中/低置信分层，低置信结果主动提交人工复核
|
||||
- 每笔认定可追溯至原始截图和结构化字段
|
||||
- 保留认定理由、排除依据、复核记录、版本快照
|
||||
- 支持按案管理、权限控制、本地化或专网部署
|
||||
|
||||
### 讲稿
|
||||
|
||||
在警务场景里，系统好不好，不只看智能不智能，更要看是否可信、是否可控、是否经得起复核。
|
||||
|
||||
所以我们从设计之初就没有追求黑箱式全自动，而是强调人机协同。系统会对结果进行置信度分层，把低置信和争议记录主动交给民警确认，确保不把不确定结论伪装成确定结论。
|
||||
|
||||
同时，系统对每一笔交易都保留原始截图来源、结构化抽取字段、认定理由、排除依据和人工修正记录，形成可回溯的证据链。对导出的报告，还可以保留版本快照，保证前后口径一致。
|
||||
|
||||
在部署层面，系统支持按案管理、权限控制，也支持本地化或专网化部署方向，符合警务数据安全和应用合规要求。
|
||||
|
||||
---
|
||||
|
||||
## 第10页 总结与推广前景
|
||||
|
||||
### 本页标题
|
||||
|
||||
**让AI真正进入警务业务闭环**
|
||||
|
||||
### 页面展示要点
|
||||
|
||||
- 项目来源于基层真实痛点，具有强实战价值
|
||||
- 项目不是OCR工具，而是多智能体警务系统
|
||||
- 项目实现了从截图到认定再到文书的全流程闭环
|
||||
- 可向反诈中心、刑侦、经侦等涉案资金场景推广
|
||||
- 结束口号建议：
|
||||
- 让截图证据自己开口，让被骗金额认定更快更准
|
||||
|
||||
### 讲稿
|
||||
|
||||
最后总结一下，这个项目最核心的价值，不是把截图识别出来，而是把基层民警在电诈案件中最繁琐、最易错、最依赖经验的资金核查工作，重构为一个由多智能体协同完成、由民警最终复核把关、并能够直接形成证据材料的智能办案系统。
|
||||
|
||||
它来源于基层真实需求，解决的是一线高频刚需问题；它不是单点OCR，而是围绕案件目标运行的警务智能体；它不是给出一个模糊答案，而是形成可解释、可复核、可追溯、可导出的办案结果。
|
||||
|
||||
未来，这套能力不仅可以服务电信诈骗受害人资金核查，还可以向反诈中心、刑侦、经侦以及其他涉案资金分析场景推广应用，形成更大范围的智慧警务实战价值。
|
||||
|
||||
我们的目标，是让AI不只停留在展示层，而是真正进入警务业务闭环。谢谢各位评委。
|
||||
|
||||
---
|
||||
|
||||
## 附：路演表达技巧建议
|
||||
|
||||
### 1. 时间分配建议
|
||||
|
||||
- 第1页：40秒
|
||||
- 第2页：60秒
|
||||
- 第3页：50秒
|
||||
- 第4页：70秒
|
||||
- 第5页：70秒
|
||||
- 第6页：70秒
|
||||
- 第7页：60秒
|
||||
- 第8页：60秒
|
||||
- 第9页：50秒
|
||||
- 第10页：40秒
|
||||
|
||||
总计约 9 分钟。
|
||||
|
||||
### 2. 讲解时要反复强调的三句话
|
||||
|
||||
- 我们解决的不是OCR识图问题，而是被骗金额认定问题。
|
||||
- 我们不是单模型问答，而是多智能体围绕案件目标协同工作。
|
||||
- 我们输出的不是一个答案，而是一套可复核、可追溯、可形成文书的证据结果。
|
||||
|
||||
### 3. 如果评委只记住一句话，建议让他记住
|
||||
|
||||
**把“人工翻截图、人工算金额、人工写理由”的传统核账模式，升级为“多智能体自动核查、民警重点复核、系统一键出证”的新型警务工作流。**
|
||||
|
||||
@@ -1,675 +0,0 @@
|
||||
# 全国“智慧+警务”AI智能体大赛参赛方案
|
||||
|
||||
## 一、项目定位
|
||||
|
||||
### 1. 项目名称建议
|
||||
|
||||
**智析反诈：电信网络诈骗案件受害人资金核查多智能体系统**
|
||||
|
||||
可选副标题：
|
||||
|
||||
- 多APP账单截图自动解析与被骗金额认定智能体
|
||||
- 面向反诈实战的截图证据解析、资金路径分析与证据化输出平台
|
||||
- 受害人资金核查场景下的警务协同智能体系统
|
||||
|
||||
### 2. 一句话介绍
|
||||
|
||||
本项目面向电信网络诈骗案件受害人资金核查场景，构建“截图证据解析 + 多平台账单关联 + 资金路径分析 + 被骗金额认定 + 证据化输出”的多智能体协同系统，将基层民警高频、繁琐、易错的人工核账流程，升级为可追溯、可复核、可出具文书的智能办案流程。
|
||||
|
||||
### 3. 参赛核心定位
|
||||
|
||||
从比赛评审视角，本项目不能只包装成“OCR识别工具”或“报表生成系统”，而应明确定位为：
|
||||
|
||||
**以案件目标为牵引、以证据链闭环为核心、以人机协同复核为保障的垂直警务智能体系统。**
|
||||
|
||||
这一定义非常关键，因为评审专家对“AI智能体”的关注点，不在于是否用了大模型，而在于是否具备：
|
||||
|
||||
- 明确目标驱动，而非单点识别
|
||||
- 多步骤自主协同，而非单轮问答
|
||||
- 可调用工具与规则，而非纯文本生成
|
||||
- 面向真实业务闭环，而非概念演示
|
||||
- 可审计、可解释、可复核，而非“黑箱结论”
|
||||
|
||||
## 二、从专家级评审视角看，本项目的真正亮点
|
||||
|
||||
### 1. 不是“识图”，而是“围绕案件目标的任务闭环”
|
||||
|
||||
传统OCR产品解决的是“看懂一张图”，而基层反诈场景真正要解决的是：
|
||||
|
||||
- 受害人提供了几十张甚至上百张不同APP截图
|
||||
- 同一笔资金可能跨微信、支付宝、银行卡、短信通知等多个载体重复出现
|
||||
- 其中夹杂本人账户中转、退款、充值、生活消费、无关流水
|
||||
- 民警最终必须回答一个执法问题：**哪些钱可以认定为被骗金额，理由是什么，证据在哪里**
|
||||
|
||||
因此，项目的核心不是图像识别能力，而是**以“被骗金额认定”这一执法目标为中心的智能体任务闭环**。这天然符合高水平AI智能体项目的评审标准。
|
||||
|
||||
### 2. 不是“一个大模型”，而是“多智能体分工协作”
|
||||
|
||||
项目最有竞争力的点，是可以清晰拆解为多个具备独立职责的专业智能体，由编排智能体统一调度，形成符合办案逻辑的协同链路。
|
||||
|
||||
建议在参赛材料中明确采用如下表述：
|
||||
|
||||
- **案件编排智能体**：接收案件目标，规划处理步骤，调度各子智能体
|
||||
- **截图理解智能体**：识别截图所属APP、页面类型、截图有效性
|
||||
- **交易抽取智能体**：将账单截图解析为标准化交易记录
|
||||
- **跨平台关联智能体**：识别同一交易在不同平台的重复呈现与映射关系
|
||||
- **资金路径分析智能体**：识别本人账户中转、分流、汇聚、链路节点
|
||||
- **被骗金额认定智能体**：结合规则与证据，对交易进行纳入/排除/待复核判定
|
||||
- **文书与笔录辅助智能体**：自动输出认定说明、问询建议、证据化报告
|
||||
- **人工复核协同智能体**：在低置信和争议场景下把案件退回人工确认，形成闭环
|
||||
|
||||
这样一来，评审看到的就不是一个“功能堆叠的软件”，而是一个**具备角色分工、任务衔接、状态流转和结果复核机制的智能体系统**。
|
||||
|
||||
### 3. 不是“生成答案”，而是“形成证据”
|
||||
|
||||
警务场景和一般政务、企业办公场景最大的不同，在于结果要进入证据体系、笔录体系、案件卷宗体系。
|
||||
所以本项目最大的专业亮点是：
|
||||
|
||||
- 输出不是一句“被骗金额大概多少”
|
||||
- 而是每一笔金额的来源截图、结构化字段、关联关系、认定理由、排除依据、复核状态
|
||||
- 最终还能导出 Excel、Word、PDF 等文书化结果
|
||||
|
||||
这代表项目具备**证据化输出能力**，而这正是智慧警务类评审会高度重视的差异化优势。
|
||||
|
||||
### 4. 不是“替代民警”，而是“人机协同增强”
|
||||
|
||||
在公安实战中，完全自动认定往往不可信，也不合规。
|
||||
所以本项目要强调的不是“AI自动判案”，而是：
|
||||
|
||||
- AI负责高强度、高重复、高耗时的信息抽取与初判
|
||||
- 民警保留最终确认权、补证权、修正权、解释权
|
||||
- 系统通过高/中/低置信分层，把最该人工关注的部分突出出来
|
||||
|
||||
这会让项目在评审中更可信、更成熟，也更符合警务智能化建设导向。
|
||||
|
||||
## 三、AI智能体本质与本项目的高度契合点
|
||||
|
||||
参赛答辩时，建议直接回应“什么是智能体，为什么你的项目是真正的智能体”。
|
||||
|
||||
### 1. 智能体的本质
|
||||
|
||||
从专家视角，AI智能体至少应具备以下五个特征：
|
||||
|
||||
1. **目标导向**：围绕清晰任务目标持续行动
|
||||
2. **环境感知**：能够理解输入环境中的多源信息
|
||||
3. **规划执行**：将复杂任务拆解为多步骤流程
|
||||
4. **工具调用**：调用OCR、规则库、数据库、图谱、报告引擎等外部能力
|
||||
5. **反馈闭环**：根据中间结果调整路径，并接受人工干预
|
||||
|
||||
### 2. 本项目如何符合智能体定义
|
||||
|
||||
本项目与上述五个特征一一对应：
|
||||
|
||||
| 智能体特征 | 本项目体现 |
|
||||
|---|---|
|
||||
| 目标导向 | 以“受害人被骗金额认定”而非单纯识别为目标 |
|
||||
| 环境感知 | 感知微信、支付宝、银行、短信等多源截图证据 |
|
||||
| 规划执行 | 依次完成分类、抽取、去重、关联、分析、认定、输出 |
|
||||
| 工具调用 | 调用OCR、多模态模型、规则引擎、数据库、报表导出组件 |
|
||||
| 反馈闭环 | 对低置信结果进入人工复核，并保留修正记录 |
|
||||
|
||||
建议在答辩中明确一句话：
|
||||
|
||||
**本项目不是“让大模型回答问题”，而是让智能体围绕案件目标，持续调用多种能力完成证据核查闭环。**
|
||||
|
||||
### 3. 为什么必须采用“多智能体”而不是“单模型”
|
||||
|
||||
因为该场景天然具备多任务异构特征：
|
||||
|
||||
- 截图识别是视觉理解问题
|
||||
- 交易标准化是结构化抽取问题
|
||||
- 跨平台合并是实体匹配问题
|
||||
- 中转识别是规则推理问题
|
||||
- 金额认定是业务决策问题
|
||||
- 问询建议与文书生成是语言生成问题
|
||||
|
||||
这些能力混在一个模型里，容易出现：
|
||||
|
||||
- 提示词过长，效果不稳定
|
||||
- 任务耦合，难以调试
|
||||
- 错误来源不清晰
|
||||
- 难以解释和复核
|
||||
|
||||
多智能体方案的价值就在于：
|
||||
|
||||
- 每个智能体只解决一类专业问题
|
||||
- 输出可结构化传递
|
||||
- 每一步可替换、可迭代、可追责
|
||||
- 更符合警务系统建设中的可管可控要求
|
||||
|
||||
## 四、项目痛点与业务价值
|
||||
|
||||
### 1. 一线实战痛点
|
||||
|
||||
基层民警在制作电诈受害人笔录和资金核查时，普遍面临以下问题：
|
||||
|
||||
- 截图来源杂，微信、支付宝、银行卡、短信、数字钱包混杂
|
||||
- 截图数量大，人工逐张登记极耗时间
|
||||
- 同一笔交易跨平台重复展示，易重复统计
|
||||
- 本人账户过渡、中转、充值提现等情形复杂，易错认
|
||||
- 认定理由依赖经验，标准不统一
|
||||
- 结果需反复整理为表格、笔录和报告，重复劳动重
|
||||
|
||||
### 2. 业务价值
|
||||
|
||||
建议用“提质、提效、减负、规范、留痕”五个词来概括：
|
||||
|
||||
- **提质**：减少重复统计、漏统、错统，提升被骗金额认定准确率
|
||||
- **提效**：将人工逐张核账变为批量自动处理，显著压缩办案时间
|
||||
- **减负**：减少基层民警在截图整理、表格汇总、笔录梳理上的机械劳动
|
||||
- **规范**：统一认定逻辑、输出格式和复核路径
|
||||
- **留痕**：保留截图来源、识别结果、认定依据、人工修正记录，满足审计追踪
|
||||
|
||||
### 3. 适用场景扩展
|
||||
|
||||
除典型电信诈骗案件外，还可扩展到：
|
||||
|
||||
- 帮信、洗钱案件中的资金流初筛
|
||||
- 网络赌博、刷单返利等案件的流水梳理
|
||||
- 经侦类案件中的多账户资金归集
|
||||
- 检法环节中的证据辅助核查
|
||||
|
||||
## 五、参赛方案的推荐总体叙事
|
||||
|
||||
### 1. 推荐主叙事
|
||||
|
||||
建议全程围绕一句核心表达：
|
||||
|
||||
**把“人工翻截图、人工算金额、人工写理由”的传统核账模式，升级为“多智能体自动核查、民警重点复核、系统一键出证”的新型警务工作流。**
|
||||
|
||||
### 2. 推荐价值主张
|
||||
|
||||
建议在材料中固定使用以下三层价值表达：
|
||||
|
||||
- **对基层民警**：减负增效，把时间从机械整理中释放出来
|
||||
- **对案件办理**：提升被骗金额认定的规范性、完整性和可解释性
|
||||
- **对智慧警务**：构建可推广、可复制、可沉淀的反诈资金核查智能体范式
|
||||
|
||||
### 3. 推荐比赛标签
|
||||
|
||||
可用于申报书、路演PPT、海报、短视频字幕：
|
||||
|
||||
- 多智能体协同
|
||||
- 警务垂直智能体
|
||||
- 证据智能解析
|
||||
- 资金路径分析
|
||||
- 被骗金额认定
|
||||
- 人机协同复核
|
||||
- 文书自动生成
|
||||
- 可解释可信AI
|
||||
|
||||
## 六、系统架构包装建议
|
||||
|
||||
### 1. 总体架构
|
||||
|
||||
建议在图示中体现“四层结构”：
|
||||
|
||||
1. **证据接入层**
|
||||
微信、支付宝、银行、短信、数字钱包等截图批量上传
|
||||
2. **智能体协同层**
|
||||
编排智能体统一调度各专业智能体
|
||||
3. **案件推理层**
|
||||
去重、关联、中转识别、认定评分、人工复核
|
||||
4. **结果输出层**
|
||||
资金流图、交易明细、认定结论、问询建议、证据化报告
|
||||
|
||||
### 2. 多智能体职责设计
|
||||
|
||||
#### （1）案件编排智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 接收案件处理请求
|
||||
- 判断当前案件状态和处理阶段
|
||||
- 规划执行顺序
|
||||
- 监控任务完成情况
|
||||
- 将异常或低置信结果提交人工复核
|
||||
|
||||
输入：
|
||||
|
||||
- 案件信息
|
||||
- 受害人截图集合
|
||||
- 基础案情说明
|
||||
|
||||
输出：
|
||||
|
||||
- 子任务清单
|
||||
- 执行状态
|
||||
- 汇总结果
|
||||
|
||||
#### （2）截图理解智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 判断截图来源APP
|
||||
- 判断页面类型
|
||||
- 识别无效截图、重复截图、非账单截图
|
||||
|
||||
价值：
|
||||
|
||||
- 解决“先分类再抽取”的前置问题
|
||||
- 为后续使用不同抽取策略提供依据
|
||||
|
||||
#### （3）交易抽取智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 对账单截图进行OCR和结构化字段提取
|
||||
- 标准化交易时间、金额、方向、对手方、订单号、备注等要素
|
||||
- 给出抽取置信度
|
||||
|
||||
价值：
|
||||
|
||||
- 将非结构化截图证据变成可计算、可关联的数据对象
|
||||
|
||||
#### （4）跨平台关联智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 识别同一笔交易在不同截图、不同APP中的重复表达
|
||||
- 建立交易聚类关系
|
||||
- 避免同一笔被骗资金重复累计
|
||||
|
||||
价值：
|
||||
|
||||
- 直接解决“重复统计”这一实战高频痛点
|
||||
|
||||
#### （5）资金路径分析智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 识别本人账户中转、自转、自充等非最终被骗路径
|
||||
- 判断是否存在汇聚账户、过桥账户、二跳转移
|
||||
- 输出资金流路径和关系图
|
||||
|
||||
价值：
|
||||
|
||||
- 将“金额汇总”升级为“路径分析”
|
||||
- 增强案件扩线和后续侦查价值
|
||||
|
||||
#### （6）被骗金额认定智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 结合规则、上下文和案件目标进行纳入/排除/待复核判断
|
||||
- 生成每笔交易的认定理由和排除依据
|
||||
- 输出高/中/低置信分层结果
|
||||
|
||||
价值：
|
||||
|
||||
- 这是最能体现警务专业性的核心智能体
|
||||
- 直接对应执法环节中的关键结论输出
|
||||
|
||||
#### （7）笔录与报告生成智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 生成受害人问询建议
|
||||
- 生成被骗金额汇总表
|
||||
- 输出 Word / Excel / PDF 等证据化文书
|
||||
|
||||
价值：
|
||||
|
||||
- 让智能体结果直接进入基层实战使用链路
|
||||
|
||||
#### （8）人工复核协同智能体
|
||||
|
||||
职责：
|
||||
|
||||
- 汇总低置信、矛盾、缺失字段记录
|
||||
- 以“最少干预”方式请求民警确认
|
||||
- 保存复核意见和修正轨迹
|
||||
|
||||
价值：
|
||||
|
||||
- 体现可信AI和警务合规理念
|
||||
- 将“全自动”风险转化为“可控智能增强”
|
||||
|
||||
## 七、结合当前项目实现，可重点包装的技术亮点
|
||||
|
||||
结合当前系统已有能力，建议重点突出以下内容：
|
||||
|
||||
### 1. 已具备较完整的案件处理链路
|
||||
|
||||
当前项目已经形成较完整流程：
|
||||
|
||||
- 案件创建与管理
|
||||
- 批量截图上传
|
||||
- OCR识别与字段抽取
|
||||
- 交易去重与聚类
|
||||
- 本人账户中转识别
|
||||
- 交易认定与理由生成
|
||||
- 人工复核
|
||||
- 报告导出
|
||||
|
||||
这说明项目不是停留在想法层面，而是已经具备原型系统基础。
|
||||
|
||||
### 2. 结构化输出而不是自由文本输出
|
||||
|
||||
系统将截图解析为标准交易字段，例如：
|
||||
|
||||
- 交易时间
|
||||
- 金额
|
||||
- 收支方向
|
||||
- 对手方名称/账号
|
||||
- 本方账户尾号
|
||||
- 订单号
|
||||
- 备注
|
||||
- 识别置信度
|
||||
|
||||
这一点对评审非常重要，因为结构化输出意味着：
|
||||
|
||||
- 可计算
|
||||
- 可追溯
|
||||
- 可比对
|
||||
- 可复核
|
||||
- 可进入业务系统
|
||||
|
||||
### 3. 规则引擎与模型推理结合
|
||||
|
||||
项目不是完全依赖大模型，而是采用“模型理解 + 规则约束”的路线：
|
||||
|
||||
- 模型负责复杂截图理解和字段抽取
|
||||
- 规则负责重复识别、中转识别、认定边界控制
|
||||
- 大模型辅助生成更规范的认定理由和问询建议
|
||||
|
||||
这是一条非常适合警务场景的技术路线，因为它兼顾：
|
||||
|
||||
- 智能性
|
||||
- 稳定性
|
||||
- 解释性
|
||||
- 可管控性
|
||||
|
||||
### 4. 支持证据化报告输出
|
||||
|
||||
系统可输出 Excel、Word、PDF 报告，这意味着：
|
||||
|
||||
- 结果可以直接服务笔录制作和案件材料整理
|
||||
- 不再停留在“屏幕上看一看”的演示阶段
|
||||
- 体现出“从识别到文书”的警务闭环
|
||||
|
||||
### 5. 支持人工复核闭环
|
||||
|
||||
高/中/低置信分层与人工确认机制，是项目成熟度的重要体现。
|
||||
评审往往很关注“错了怎么办”，你可以明确回答：
|
||||
|
||||
- 系统不会把不确定结果伪装成确定结论
|
||||
- 系统会把低置信结果主动交给民警确认
|
||||
- 人工复核结果可以反向修正最终认定
|
||||
|
||||
这会明显提升项目可信度。
|
||||
|
||||
## 八、参赛材料中必须突出的“重点分析维度”
|
||||
|
||||
### 1. 业务刚需性
|
||||
|
||||
要让评审相信：这不是“为了比赛设计的需求”，而是基层民警天天遇到的刚需问题。
|
||||
建议突出：
|
||||
|
||||
- 高发场景
|
||||
- 高频动作
|
||||
- 高耗时环节
|
||||
- 高易错环节
|
||||
|
||||
### 2. 智能体真实性
|
||||
|
||||
很多参赛项目容易被质疑为“套壳大模型”。
|
||||
你的项目要重点证明：
|
||||
|
||||
- 有任务目标，不是聊天问答
|
||||
- 有任务分工，不是一个提示词包打天下
|
||||
- 有状态流转，不是单次调用
|
||||
- 有工具调用，不是只会生成文本
|
||||
- 有人工闭环，不是输出即结束
|
||||
|
||||
### 3. 警务专业深度
|
||||
|
||||
评审会重点看项目是否真正理解公安业务。
|
||||
建议重点突出以下专业点：
|
||||
|
||||
- 同笔交易跨平台重复识别
|
||||
- 本人账户中转识别
|
||||
- 认定理由生成
|
||||
- 排除逻辑与复核逻辑
|
||||
- 证据索引与卷宗化输出
|
||||
|
||||
### 4. 可解释与可信
|
||||
|
||||
在警务场景里，“为什么认定这笔是被骗金额”比“模型分数高不高”更重要。
|
||||
因此必须强调：
|
||||
|
||||
- 每一笔认定均有来源截图
|
||||
- 每一笔认定均有结构化字段
|
||||
- 每一笔认定均有理由说明
|
||||
- 每一笔排除均有依据
|
||||
- 每一步都有人工复核入口
|
||||
|
||||
### 5. 工程落地能力
|
||||
|
||||
要让评审看到这是可以推广的系统，而不是实验室Demo。
|
||||
建议强调：
|
||||
|
||||
- 前后端完整系统
|
||||
- 支持案件、截图、分析、复核、报告全流程
|
||||
- 支持异步任务处理
|
||||
- 支持模型接口替换
|
||||
- 支持 mock 演示与真实模型配置切换
|
||||
|
||||
## 九、申报书建议写法
|
||||
|
||||
### 1. 项目背景
|
||||
|
||||
建议按以下逻辑写：
|
||||
|
||||
随着电信网络诈骗案件持续高发，基层民警在受害人报案受理、资金核查、笔录制作过程中，需要面对大量来自微信、支付宝、银行卡、短信通知等不同来源的账单截图。现有工作模式主要依赖人工逐张查看、登记、汇总、排重、计算，存在效率低、重复统计、认定不统一、证据整理负担重等问题。为破解该痛点，本项目面向受害人资金核查实战，研发多智能体协同的截图证据解析与被骗金额认定系统，实现多源截图自动识别、跨平台关联、资金路径分析、认定复核和文书化输出，服务电诈案件快速、规范、可追溯办理。
|
||||
|
||||
### 2. 建设目标
|
||||
|
||||
建议凝练成三项目标：
|
||||
|
||||
1. **自动化**：让截图证据从人工整理转向自动识别和结构化处理
|
||||
2. **规范化**：让被骗金额认定从经验判断转向规则化、可解释化输出
|
||||
3. **实战化**：让分析结果直接服务笔录制作、资金核查和案件材料生成
|
||||
|
||||
### 3. 创新点写法
|
||||
|
||||
建议至少写四个创新点：
|
||||
|
||||
1. **多智能体协同创新**
|
||||
将截图理解、交易抽取、关联分析、金额认定、文书生成拆分为专业智能体，由编排智能体协同调度，形成案件目标驱动的闭环处理流程。
|
||||
|
||||
2. **跨平台资金证据关联创新**
|
||||
面向微信、支付宝、银行卡、短信等多源截图，识别同笔交易的跨平台重复表达，实现资金证据自动关联和去重。
|
||||
|
||||
3. **被骗金额认定创新**
|
||||
不止识别流水，而是围绕执法需要，结合规则和上下文对每笔交易进行纳入、排除、待复核判断，并生成认定理由。
|
||||
|
||||
4. **证据化输出创新**
|
||||
将智能分析结果转化为可复核、可导出、可纳入案卷的报告和问询材料，构建从截图到文书的完整闭环。
|
||||
|
||||
### 4. 推广价值写法
|
||||
|
||||
建议写成：
|
||||
|
||||
本项目面向基层高频警务场景，具有显著的通用性和可复制性。系统能力不仅适用于电信诈骗受害人资金核查，还可扩展应用于涉诈资金链梳理、涉赌资金流水分析、经侦案件多账户资金归集等场景，具备在派出所、反诈中心、刑侦部门等多层级单位推广应用的潜力。
|
||||
|
||||
## 十、答辩和路演的最佳呈现方式
|
||||
|
||||
### 1. PPT建议结构
|
||||
|
||||
建议控制在 10 页左右：
|
||||
|
||||
1. 项目名称 + 一句话价值
|
||||
2. 基层实战痛点
|
||||
3. 现有模式的问题
|
||||
4. 项目总体方案
|
||||
5. 多智能体协同架构
|
||||
6. 核心业务流程演示
|
||||
7. 关键创新点
|
||||
8. 应用成效与指标
|
||||
9. 安全合规与可信机制
|
||||
10. 推广前景与总结
|
||||
|
||||
### 2. 演示脚本建议
|
||||
|
||||
建议按照“一个案件跑到底”的方式演示：
|
||||
|
||||
1. 新建案件
|
||||
2. 批量上传多APP截图
|
||||
3. 系统自动识别截图来源和页面类型
|
||||
4. 自动抽取交易字段
|
||||
5. 自动完成去重与中转识别
|
||||
6. 生成资金路径与被骗金额初判
|
||||
7. 对低置信记录进行人工复核
|
||||
8. 一键导出被骗金额汇总和问询建议
|
||||
|
||||
这样最能体现“智能体闭环”，而不是单点功能切换。
|
||||
|
||||
### 3. 现场讲解要点
|
||||
|
||||
建议重点讲三句话：
|
||||
|
||||
- **第一句**：我们解决的不是OCR问题，而是基层民警最耗时、最易错的被骗资金核查问题。
|
||||
- **第二句**：我们不是单模型问答，而是多智能体围绕案件目标协同工作。
|
||||
- **第三句**：我们输出的不是一个答案，而是一套可复核、可追溯、可形成文书的证据结果。
|
||||
|
||||
## 十一、建议准备的量化指标
|
||||
|
||||
如果要冲击高奖项，必须尽可能提供量化结果。即使是阶段性数据，也比纯定性描述更有说服力。
|
||||
|
||||
建议准备以下指标：
|
||||
|
||||
- 单案平均核查时间压缩比例
|
||||
- 单案人工录入工作量下降比例
|
||||
- 重复交易识别准确率
|
||||
- 本人账户中转识别准确率
|
||||
- 被骗金额认定一致性提升幅度
|
||||
- 报告生成时间缩短比例
|
||||
- 民警满意度或使用反馈
|
||||
|
||||
### 指标写法示例
|
||||
|
||||
可参考如下口径：
|
||||
|
||||
- 传统人工核查需 2 至 4 小时的案件，系统可在数分钟内完成初步结构化和归并分析
|
||||
- 多平台重复交易自动识别后，重复统计风险明显下降
|
||||
- 民警由“全量逐条核对”转为“聚焦争议记录复核”，工作重心明显优化
|
||||
|
||||
如果后续你有真实数据，建议替换为具体数字，如“平均耗时下降 70%”等。
|
||||
|
||||
## 十二、安全、合规与可信设计建议
|
||||
|
||||
警务类比赛中，这一部分非常重要，不能缺失。
|
||||
|
||||
### 1. 数据安全
|
||||
|
||||
建议强调：
|
||||
|
||||
- 案件数据按案管理，隔离存储
|
||||
- 证据图片、识别结果、报告文件全流程留痕
|
||||
- 支持本地化部署或专网部署
|
||||
- 支持模型接口按需切换
|
||||
|
||||
### 2. 权限与审计
|
||||
|
||||
建议强调：
|
||||
|
||||
- 不同角色区分上传、复核、导出权限
|
||||
- 保留分析时间、复核时间、复核人、修改记录
|
||||
- 导出报告保留版本快照，防止后续口径不一致
|
||||
|
||||
### 3. 可信AI
|
||||
|
||||
建议强调：
|
||||
|
||||
- 对低置信结果不直接下结论
|
||||
- 人工拥有最终确认权
|
||||
- 所有关键认定均有可解释理由
|
||||
- 结果可追溯至原始截图证据
|
||||
|
||||
## 十三、评审可能追问的问题与建议回答
|
||||
|
||||
### 1. 你这个项目和普通OCR报销系统有什么区别？
|
||||
|
||||
建议回答：
|
||||
|
||||
普通OCR系统解决的是“识别内容”，本项目解决的是“围绕案件目标认定被骗金额”。系统不仅做截图识别，还做跨平台关联、本人账户中转识别、认定理由生成、人工复核和证据化输出，核心是执法业务闭环而不是识别本身。
|
||||
|
||||
### 2. 为什么要做多智能体，不直接用一个大模型？
|
||||
|
||||
建议回答：
|
||||
|
||||
因为本场景同时包含视觉识别、结构化抽取、交易关联、规则推理、文书生成等异构任务。采用多智能体分工后，每一步更稳定、可解释、可替换，也更符合警务场景可管可控要求。
|
||||
|
||||
### 3. 如果模型识别错了怎么办？
|
||||
|
||||
建议回答：
|
||||
|
||||
系统会输出置信度，并把低置信和争议记录交由民警复核；同时保留原始截图、抽取字段、认定理由和修正记录，确保结论不是黑箱生成，而是可追溯、可校正的。
|
||||
|
||||
### 4. 这个项目是否具备推广条件？
|
||||
|
||||
建议回答：
|
||||
|
||||
该项目面向基层反诈案件高频场景，流程标准、通用性强，并已具备前后端原型、案件流程、异步分析、报告导出等基础能力，可根据不同单位部署条件选择本地化或专网化落地，具备较强推广价值。
|
||||
|
||||
## 十四、冲击高奖项的包装建议
|
||||
|
||||
如果目标不是“参赛即可”，而是争取更高奖项，建议在现有基础上强化以下表达：
|
||||
|
||||
### 1. 突出“实战首创性”
|
||||
|
||||
建议强调：
|
||||
|
||||
- 来源于基层民警真实办案需求
|
||||
- 在真实案件工作流中设计和应用
|
||||
- 不是从技术找场景，而是从痛点反推系统
|
||||
|
||||
### 2. 突出“执法专业性”
|
||||
|
||||
建议强调：
|
||||
|
||||
- 认定的是“被骗金额”，不是简单流水金额
|
||||
- 输出包含纳入、排除、待复核三类结果
|
||||
- 支持认定理由和排除理由说明
|
||||
|
||||
### 3. 突出“闭环可用性”
|
||||
|
||||
建议强调：
|
||||
|
||||
- 能上传
|
||||
- 能识别
|
||||
- 能分析
|
||||
- 能复核
|
||||
- 能出报告
|
||||
|
||||
比“模型准确率多高”更能打动警务评审。
|
||||
|
||||
### 4. 突出“可复制推广”
|
||||
|
||||
建议强调：
|
||||
|
||||
- 技术路线可复制
|
||||
- 场景边界清晰
|
||||
- 业务模板可复用
|
||||
- 可扩展到其他涉案资金场景
|
||||
|
||||
## 十五、建议的最终参赛口号
|
||||
|
||||
可任选其一：
|
||||
|
||||
- **让截图证据自己开口，让被骗金额认定更快更准。**
|
||||
- **从海量账单截图到一键证据报告，打造反诈资金核查智能体。**
|
||||
- **把基层民警从“翻截图、算金额、写材料”中解放出来。**
|
||||
- **以多智能体协同，重塑电诈案件资金核查新模式。**
|
||||
|
||||
## 十六、可直接用于申报书摘要的精炼版本
|
||||
|
||||
本项目聚焦电信网络诈骗案件受害人资金核查这一基层高频、耗时、易错场景，构建多智能体协同的截图证据解析与被骗金额认定系统。系统围绕案件目标，自动完成多APP账单截图识别、交易字段抽取、跨平台重复关联、本人账户中转识别、资金路径分析、被骗金额认定和证据化报告输出，并通过人工复核机制保障结果可信可控。项目不是单点OCR工具，而是面向警务实战的垂直智能体系统，能够显著提升资金核查效率、规范认定标准、减轻基层负担，具备较强的实战价值、推广价值和示范意义。
|
||||
|
||||
## 十七、结论：评审最容易被打动的核心表达
|
||||
|
||||
最终在所有材料和答辩中，建议把项目价值浓缩为下面这段话：
|
||||
|
||||
**这个项目最重要的，不是把截图识别出来，而是把基层民警在电诈案件中最繁琐、最易错、最依赖经验的被骗资金核查流程，重构为一个由多智能体协同完成、由民警最终复核把关、并能直接形成证据材料的智能办案系统。它体现的不是“AI会看图”，而是“AI真正进入警务业务闭环”。**
|
||||
|
||||
Reference in New Issue
Block a user