在法律AI应用场景中，大模型生成的摘要存在致命的幻觉问题。当系统输出如“法院认定合同有效”等关键结论时，若缺乏精确的原文引证，将直接导致三大痛点：
信任危机：毫无根据的摘要缺乏法律应用价值，律师与法官不敢轻易采信。
效率低下：用户仍需在动辄数十页的判决书原文中手动搜索对应段落，失去了AI辅助的意义。
责任风险：错误引用或虚假捏造可能导致严重的法律后果且无法追责。
基于此，本团队开展了本期系统的研发与迭代，核心目标是构建一套具备“精确溯源*能力的法律辅助阅读系统，并全面升级底层存储架构与前端交互体验。
一、 项目概述与技术栈
本系统旨在解决法律AI应用中的“幻觉”痛点，通过混合溯源、智能文本勘误及多维度阅读交互，提供高可信度的法律文档摘要与分析服务。
核心架构：Python 3.11 + FastAPI (后端) + Vue 3 (前端)
核心AI技术：LLM (GPT-4/GPT-3.5-turbo) + OpenAI Embedding (text-embedding-3-small)
数据存储：SQLite (关系型/批注/示例) + ChromaDB (向量) + JSON (历史记录)
二、 核心算法与模型优化
1. 基于混合语义的双通道溯源引擎
为解决大模型摘要的“幻觉”问题并实现精准溯源，系统实现了无需GPU的纯API双通道融合方案：
文档分块：将长文档拆分为带索引的文本块（Block），控制LLM上下文窗口。
通道一（LLM标注）：通过Prompt工程，要求LLM在生成关键要素时附加来源块编号（如
[来源: X, Y]）。通道二（语义相似度兜底）：将摘要要点与所有文档块进行Embedding向量化。计算余弦相似度，设定阈值为0.45，取Top-K作为补充来源，解决LLM漏标或错标问题。
融合策略：以语义匹配为基础，用LLM标注进行高置信度覆盖，去重后限制单一要点最多5个来源，前端区分标记“语义溯源”与“混合溯源”。
2. 规则抽取升级与OCR文本勘误
针对PDF解析及扫描件识别的脏数据问题，进行了专项治理：
正则抽取容错：优化案号等关键信息的正则表达式，引入
\s*处理PDF强制换行或字间插入空格的问题（如成功匹配( 2024 ) 鲁 0102...）。LLM智能勘误：利用GPT-3.5-turbo对OCR识别结果进行分批次（Batch=10）语义勘误。通过严格的Prompt约束模型仅修复错别字和标点（如“争焦点”修正为“争议焦点”），杜绝模型发散或插入多余解释。
三、 后端架构与数据持久化
1. 存储层重构
废弃了早期依赖浏览器LocalStorage的方案，实现了全流程的后端持久化与RESTful API对接：
历史记录：存入后端的
history.json，保留最新50条，增加毫秒级时间戳。批注数据：迁移至SQLite数据库（
annotations表），按文档ID隔离，支持多用户并发与增删改查。为解决时间戳显示异常，统一在存储时转为UTC时间（timezone.utc），交由前端解析为本地时区。模型校验：在
schemas.py引入Pydantic Validator强类型校验，修正了因时间戳字段非必填导致的422 Unprocessable Entity拦截错误。
2. 文件去重与生命周期同步
MD5秒传机制：在文件上传接口加装MD5哈希校验。若底层已存在该文件，直接拦截全套大模型解析流程，实现“秒传”并跳转。
级联删除同步：在
vector_store实现delete_chunks功能。当用户删除原文档时，系统会同步清理 ChromaDB 中的向量数据、历史记录 JSON 以及 SQLite 中的绑定批注。
3. 自定义示例库管理
数据库扩展：SQLite新增
custom_samples表，通过doc_id与原文档保持生命周期绑定。若原文档删除，示例同步失效。零延迟加载：针对已存在的文档转化为“示例”，系统不再走二次上传与解析流程。前端直接通过固定ID和路由跳转缓存加载，使示例切换耗时降至0秒。
四、 前端视图与交互体验
1. 双栏交互式阅读空间
布局重构：
ReaderView.vue实现左侧原文内容、右侧批注与分析面板的独立分栏。划线批注：监听
mouseup与window.getSelection()事件，用户在左栏选中文字后，右侧自动弹出带当前文本的批注表单，支持颜色分类与实时保存。
2. 溯源高亮与平滑滚动
点击即溯源：在摘要面板点击任意带溯源标签的要点，系统自动切换至“原文块”标签页。
焦点追踪：通过
scrollIntoView({ behavior: 'smooth', block: 'center' })自动滚动至目标段落，并运用CSS动画（pulse）对目标段落进行4秒的背景高亮闪烁，提升审查直觉。
五、 系统性能与稳定性保障
API防熔断设计：针对Embedding和大模型纠错接口，引入指数退避（Exponential Backoff）重试机制，设定最大重试3次与30秒总超时，大幅降低因网络波动引发的提取中断。
批处理优化：Embedding请求合并为100条/批，OCR大模型纠错合并为10条/批并增加请求延时（1秒），有效避免触发OpenAI API的并发限流（Rate Limit）。
内存级缓存：构建字典级Embedding缓存，对频繁出现的重复文本块跳过请求，单个文档缓存开销控制在360KB左右。
| 模块 | 技术方案 | 关键参数 |
|---|---|---|
| 文档分块 | 按语义边界切分，编号从0开始 | max_blocks=60 |
| 通道1：LLM标注 | Prompt注入来源标注指令 | 格式[来源: X, Y] |
| 通道2：语义匹配 | OpenAI Embedding + 余弦相似度 | threshold=0.45,top_k=3 |
| 融合策略 | LLM结果覆盖语义结果，去重取前5 | 标记来源方法（hybrid/semantic/llm） |
| 功能模块 | 技术实现 | 解决的问题 |
|---|---|---|
| 历史记录持久化 | JSON文件 + RESTful API | 跨浏览器/设备同步 |
| 批注存储 | SQLite + Pydantic校验 | 支持批量导出与多用户 |
| ChromaDB同步删除 | delete_chunks()函数 | 文档删除时清理向量 |
| 双栏阅读 | ReaderView.vue+ 文本选中联动 | 边读边批注 |
| 自定义示例库 | SQLite新增custom_samples表 | 用户可保存常用文书模板 |
| 示例加载优化 | 直接路由跳转 + 固定ID缓存 | 加载时间从数秒降至接近0 |
| MD5文件去重 | 上传时计算哈希比对 | 避免重复解析消耗资源 |
| 问题 | 解决方案 | 效果 |
|---|---|---|
| PDF文本中插入额外空格导致正则匹配失败 | 正则表达式兼容\s*（如[（(]\s*\d{4}\s*[）)]） | 案号抽取成功率从65%提升至92% |
| OCR识别错别字、漏字 | 大模型文本勘误（GPT-3.5-turbo） | “争焦点”→“争议焦点”等 |
| 大模型响应超时 | 添加重试机制（最多3次，指数退避） | 稳定性提升 |
| API速率限制 | 批处理（batch_size=10）+ 1秒间隔 | 避免限流 |
问题解决
| 问题 | 责任人 | 解决方案 |
|---|---|---|
| 历史记录保存422错误 | 成员jyx | 将timestamp字段设为可选默认值 |
| 批保存字段名不一致 | 成员jyx | API返回前统一selectedText与selected_text |
| 批注时间显示少8小时 | 成员jyx | SQLite UTC时间明确时区，前端toLocaleString转换 |
| 自定义示例无法随文档删除 | 成员jyx | 为custom_samples表新增doc_id外键 |
| LLM忘记标注来源（30-40%概率） | 成员lxj | 语义匹配通道兜底 |
| 正则无法匹配带空格的案号 | 成员zzx | 正则表达式增加\s*兼容空格 |
总结
本次迭代中，团队成功落地了兼顾精度与工程可行性的无GPU架构混合溯源方案，彻底解决了系统数据的后端持久化问题，并通过双栏联动、MD5秒传、示例ID缓存等一系列深度优化，将系统的响应延迟与操作顺滑度提升到了新的台阶。团队在跨端API对接、并发状态管理以及提示词工程上的协作默契也得到了显著增强。
