基于RAG与大模型的法律AI助手：国家赔偿案件全流程智能处理实践

1. 项目概述：一个为法律从业者设计的国家赔偿AI助手

在行政与司法实践中，国家赔偿案件的处理往往涉及复杂的法律适用、繁琐的程序计算以及海量的文书检索。对于律师、法务工作者乃至法律研究者而言，每一个案件都像是一次精密的“法律工程”，需要将《国家赔偿法》的抽象条文，转化为具体的赔偿请求、计算清单和程序策略。传统的工作模式高度依赖个人经验与手动检索，效率瓶颈明显，且容易因细节疏漏影响案件结果。

“zhang-state-compensation”这个项目，正是瞄准了这一痛点。它并非一个简单的法律条文数据库，而是一个旨在覆盖国家赔偿“全流程”的AI助手。其核心目标，是运用人工智能技术，辅助法律从业者完成从案件初步分析、赔偿项目与金额计算，到相关法律依据与文书模板检索等一系列工作。简单来说，它试图成为律师在处理国家赔偿案件时的“副驾驶”，将从业者从重复性、机械性的信息处理工作中解放出来，让他们能更专注于案件的核心法律争点与策略构建。

这个工具特别适合以下几类人群：一是初入行的青年律师或实习律师，可以通过它快速建立对国家赔偿案件处理的系统性认知，减少学习成本；二是业务繁忙的资深律师，可以用它来提升案件前期准备和文书起草的效率，确保计算和引用的准确性；三是法学院校的师生，可以将其作为教学与研究的辅助工具，进行案例模拟与法律适用分析。

2. 核心功能与设计思路拆解

2.1 功能模块全景图

这个AI助手的设计，紧紧围绕国家赔偿案件处理的真实工作流展开。我们可以将其核心功能拆解为三个相互关联的模块：

1. 智能案情分析与初步指引模块：这是流程的起点。用户输入案件的基本事实（例如，涉及的是行政拘留、刑事扣押还是司法拍卖错误），AI助手需要能够理解案情，并初步判断可能适用的赔偿类型（行政赔偿、刑事赔偿、非刑事司法赔偿）、赔偿义务机关，以及核心的赔偿请求事项（如人身自由赔偿金、生命健康赔偿金、财产损失等）。这个模块的关键在于对自然语言描述的案件事实进行准确的“法律定性”。

2. 精细化赔偿计算引擎模块：这是工具的核心价值所在。国家赔偿的计算，尤其是人身自由赔偿金和生命健康赔偿金，有明确但复杂的计算公式，且每年标准（上年度职工日平均工资）都在变化。此模块需要：

   • 自动关联标准：能自动获取并应用最新的国家统计局发布的“全国城镇非私营单位就业人员日平均工资”数据。
   • 多项目协同计算：支持对同一案件中多项赔偿请求的并行计算。例如，一个案件可能同时涉及错误羁押（人身自由赔偿）、致伤（医疗费、误工费、残疾赔偿金）和财产被违法没收（直接损失、利息）。引擎需要能分别计算并汇总。
   • 参数化与可解释性：所有计算过程应对用户透明，允许用户调整关键参数（如羁押天数、伤残等级、医疗费票据金额等），并清晰展示每一步的计算公式、数据来源和最终结果。

3. 法律依据与文书智能生成模块：在完成分析和计算后，最终要落地为法律文书。此模块应能：

   • 精准推送法条：根据案情和计算项目，自动关联并列出《国家赔偿法》、《国家赔偿费用管理条例》以及相关司法解释（如最高人民法院关于审理行政赔偿案件若干问题的规定）的具体条款。
   • 生成文书草稿：提供《国家赔偿申请书》、《赔偿计算清单》等核心文书的标准化模板，并能将前两个模块的分析结果和计算数据自动填充到模板的相应位置，形成一份内容详实、格式规范的初稿，供律师复核和润色。

2.2 技术路径与工具选型考量

要实现上述功能，项目的技术栈选择至关重要。从项目关键词“openclaw”和“skill”推测，它很可能基于某个开源的法律AI框架或工具集进行开发。一个合理的选型思路是：

• 核心AI能力层：优先考虑使用经过中文法律文本精调的大语言模型（LLM）。例如，基于开源模型如 ChatGLM、Qwen 或 Baichuan，使用大量的法律判决文书、法律法规条文进行指令微调（Instruction Tuning），使其具备专业的法律语义理解和推理能力。直接使用通用大模型（如GPT系列）虽然方便，但在专业法律术语的准确性、对中国法律体系的理解深度上可能存在风险，且涉及数据出境与合规问题。采用国内开源方案并进行领域适配，是更稳妥、可控的选择。
• 知识库与检索层：仅靠大模型的“记忆”无法保证法律依据的准确性和时效性。必须构建一个本地的、可更新的法律知识库，包含《国家赔偿法》及所有相关行政法规、司法解释、典型案例。当需要进行法条引用或案情比对时，采用“检索增强生成”（RAG）技术。即先通过向量数据库（如 Milvus, Chroma）快速检索出与用户问题最相关的法律条文和案例片段，再将检索结果作为上下文提供给大模型，让其生成最终答案。这能极大提高回答的准确性和可追溯性。
• 计算与业务逻辑层：赔偿计算部分有严格的数学公式，不适合完全交给概率性的大模型处理。这部分应采用确定性的编程逻辑来实现。可以用 Python 编写核心计算函数，封装成独立的服务或模块。大模型负责理解用户意图并提取计算所需的参数（天数、金额、等级），然后调用这些确定性函数进行计算，最后将结果整合进回复中。这样既利用了AI的理解能力，又保证了计算结果的绝对准确。
• 前端交互层：考虑到用户主要是法律专业人士，界面应设计得清晰、专业、高效。一个Web应用是合适的选择，采用 Vue.js 或 React 框架构建。界面可划分为：案情描述输入区、交互式问答分析区、赔偿计算表单与结果展示区、法律依据引用区以及文书生成预览区。良好的交互设计能引导用户一步步完成全流程操作。

注意：数据安全与合规性。处理法律案件信息涉及高度敏感的客户隐私和案件细节。所有数据应在客户端或部署在律师自有服务器上进行处理，避免上传至不可控的第三方云端。项目设计之初就必须将“数据本地化处理”作为核心原则，这也是获得法律从业者信任的基石。

3. 核心功能实现细节与实操解析

3.1 赔偿计算引擎的精确实现

赔偿计算是国家赔偿案件的核心，也是最容易出错的环节。下面以最常见的“人身自由赔偿金”和“残疾赔偿金”为例，拆解其实现逻辑。

人身自由赔偿金计算：公式为：赔偿金额 = 上年度全国职工日平均工资 × 侵犯人身自由的天数。

• 关键数据“上年度日平均工资”：这个数据每年由最高人民法院根据国家统计局数据发布。实现时，必须在系统内维护一个权威数据源表，并能自动或手动更新。计算函数需要根据赔偿决定作出时的“上年度”来匹配正确的日工资标准。例如，2025年审理2024年发生的侵权案件，应适用2023年的日平均工资标准。
• 天数计算：需要处理拘留、逮捕、服刑等不同情形的起止日期。实现一个健壮的日期计算函数至关重要，需考虑跨年、闰年、刑期折抵等复杂情况。在交互界面上，应提供日历组件供用户选择日期，并自动计算出精确天数。

残疾赔偿金计算：公式为：赔偿金额 = 上年度全国职工年平均工资 × 劳动能力丧失程度系数（伤残等级系数）× 法定赔偿年限。

• 伤残等级与系数映射：需要根据《人体损伤致残程度分级》标准，建立伤残等级（十级至一级）与劳动能力丧失程度系数（通常从10%到100%）的映射表。这个系数是计算的关键，必须确保其权威性和准确性。
• 赔偿年限：根据《国家赔偿法》，残疾赔偿金给付年限有明确规定（如部分丧失劳动能力的最高为20年）。计算引擎需要能根据伤残等级自动判断适用的赔偿年限规则。
• 多项目叠加：残疾赔偿金往往与医疗费、护理费、误工费等并列计算。引擎需要支持在一个案件实例中，同时维护和计算多个赔偿项目，并生成清晰的总计清单。

实操界面设计建议：计算界面不应只是一个输入框。理想的设计是一个动态表单：

1. 用户首先选择赔偿类型（如人身自由、生命健康、财产）。
2. 根据选择，界面动态渲染出对应的输入字段（如“羁押开始日期”、“结束日期”、“伤残等级鉴定书编号”、“医疗费票据总额”）。
3. 用户填写或选择后，界面实时显示计算过程和中间结果。
4. 最终生成一份结构化的《赔偿请求计算明细表》，包含项目、计算公式、参数、结果，方便用户核对和直接粘贴到文书里。

3.2 法律依据的智能检索与关联

单纯罗列法条意义不大，关键是要“精准关联”。这依赖于高质量的“法律知识图谱”和RAG技术。

知识库构建：

1. 数据源：收集《国家赔偿法》、相关行政法规、最高人民法院发布的所有关于国家赔偿的司法解释、批复、指导案例，以及各省高院的实施细则。数据格式需统一处理为结构化的文本。
2. 向量化：使用文本嵌入模型（如 BGE、m3e），将每一条法律条文、每一个案例摘要转换为高维向量。这个向量代表了文本的语义信息。
3. 存储与索引：将这些向量存入专门的向量数据库（如 Chroma DB）。同时，保留原始文本及其元数据（如发文机关、文号、生效日期、所属章节）。

检索与生成流程：当用户描述案情或提出具体问题时（例如：“违法刑事拘留37天，如何计算赔偿？”）：

1. 问题向量化：将用户问题同样转换为向量。
2. 语义检索：在向量数据库中，查找与问题向量最相似的若干条法律条文和案例（例如，检索出《国家赔偿法》第十七条、第三十三条，以及最高人民法院关于日赔偿金计算标准的通知）。
3. 上下文构建：将检索到的相关法律文本，作为“上下文”或“参考依据”，与用户原始问题一起，提交给大语言模型。
4. 生成答案：指令大模型：“请基于以下法律依据，回答用户的问题：...”。模型会生成一个融合了具体法条内容和案件分析的答案，如：“根据《国家赔偿法》第三十三条，侵犯公民人身自由的，每日赔偿金按照国家上年度职工日平均工资计算。您的情况涉及37天违法刑事拘留，首先需确定作出赔偿决定时的‘上年度’是哪一年，然后查询该年度的日平均工资标准，两者相乘即可得出具体金额。计算时需注意...”。

这种方式生成的答案，不仅有结论，更有明确的法律出处，可信度和实用性大大增强。

3.3 文书生成的模板化与智能化

文书生成不是简单的填空，需要理解文书的结构和不同部分所需的要素。

模板设计：系统应内置多种经过验证的国家赔偿文书模板，如《国家赔偿申请书》、《赔偿计算清单》、《证据目录》、《代理词》要点提纲等。这些模板应是Markdown或富文本格式，其中包含大量的“变量占位符”，例如{赔偿请求人姓名}、{侵犯人身自由天数}、{赔偿金计算结果}、{引用法条1}。

智能填充：在前述案情分析和计算完成的基础上，系统自动将已结构化的事实信息、计算数据、检索到的法条，填充到模板的对应占位符中。例如：

• 将用户输入的当事人信息填充到文书首部。
• 将案情分析模块归纳的事实概要填充到“事实与理由”部分。
• 将计算引擎输出的明细表格，整体嵌入到“赔偿请求”部分。
• 将RAG模块检索并精炼后的法条引用，插入到“法律依据”部分。

生成初稿后，必须提供显著的编辑区域，允许律师自由修改、增删。系统生成的永远是“草稿”，最终的定稿权和责任必须由律师本人掌握。一个好的设计是提供“版本对比”功能，让律师能清晰看到AI修改了哪些部分，方便复核。

4. 开发部署实践与核心环节

4.1 技术栈选型与项目初始化

基于上述设计，一个可行的现代技术栈组合如下：

• 后端：Python + FastAPI。Python在AI生态和科学计算方面有巨大优势，FastAPI能提供高性能、易于构建的API接口，非常适合作为AI服务的后端框架。
• 核心AI服务：使用 LangChain 或 LlamaIndex 等框架来编排大模型调用、知识库检索和工具调用（计算函数）的整个流程。这比从零开始编写控制逻辑要高效得多。
• 大模型：在本地或私有云部署一个经过法律文本精调的中文大模型。例如，使用开源的 Qwen-7B-Chat 或 ChatGLM3-6B 模型，并利用最高人民法院发布的裁判文书进行进一步的指令微调（SFT），使其更擅长法律推理。
• 向量数据库：选用轻量且易用的 Chroma DB，它易于集成，适合存储法律条文和案例的向量数据。
• 前端：Vue 3 + TypeScript + Element Plus。Vue框架学习曲线平缓，组件丰富，能快速构建出专业且交互良好的管理界面。TypeScript能提升代码健壮性。
• 部署：使用 Docker 进行容器化封装。可以编写docker-compose.yml文件，将后端API服务、前端Web服务、向量数据库服务等编排在一起，实现一键部署。这对于律师事务所在自有服务器上部署至关重要。

项目初始化实操步骤：

1. 创建项目目录，使用git init初始化仓库。
2. 分别创建backend/和frontend/目录。
3. 在backend/下，使用pipenv或poetry创建虚拟环境，安装fastapi,langchain,chromadb,sentence-transformers等核心依赖。
4. 在frontend/下，使用npm create vue@latest脚手架创建Vue项目，并安装axios（用于网络请求）、element-plus（UI组件库）。
5. 编写后端的核心路由（如/api/analyze,/api/calculate,/api/generate_doc）和前端的对应页面组件。

4.2 知识库构建与更新流程

知识库不是一次性的，需要持续维护和更新。

1. 数据爬取与清洗：编写Python脚本，从最高人民法院官网、中国政府网等权威渠道，定期爬取最新的法律法规和司法解释。使用正则表达式和文本解析库（如BeautifulSoup）清洗HTML，提取纯文本和元数据。
2. 文本分割：法律条文很长，不能整个存入向量数据库。需要根据语义进行智能分割，例如按“条”、“款”、“项”进行分割，确保每个片段有完整的语义。
3. 向量化与入库：编写脚本，加载文本分割后的片段，使用嵌入模型（如BGE-zh）进行向量化，然后将[向量, 文本, 元数据]对批量存入Chroma DB集合中。
4. 更新策略：建立定时任务（如每周一次），自动执行爬取、清洗、分割、向量化、入库流程。对于更新的法律，需要同时处理新条文的添加和旧条文的失效标记（可通过元数据中的生效/废止日期字段实现）。

4.3 前后端协同与API设计

前后端通过RESTful API进行通信，关键API接口设计如下：

前端在用户进行操作时，调用对应的API，并将返回的结果实时展示在界面上，形成流畅的交互体验。

5. 潜在挑战、常见问题与避坑指南

在实际开发和应用此类法律AI工具时，会遇到诸多挑战。以下是一些关键问题的实录与应对思路。

5.1 技术实现层面的挑战

1. 大模型“幻觉”与事实性错误：这是最大的风险。大模型可能会生成看似合理但完全错误的法律条文或计算方式。
   • 应对策略：严格限定AI的“发挥”空间。核心计算必须用确定性函数；法律依据必须通过RAG从权威知识库中检索，并强制模型在回答中引用原文；在最终输出时，对关键结论（如赔偿金额、引用法条号）进行高亮或标记，提示用户务必复核。
2. 法律知识库的覆盖度与时效性：法律体系庞杂且不断更新，知识库难免有遗漏或滞后。
   • 应对策略：建立明确的更新机制和来源清单。同时，在系统界面提供“反馈”入口，允许用户标注信息缺失或错误。更重要的是，必须在系统显著位置添加免责声明：“本工具生成内容仅供参考，不构成正式法律意见，使用者应以最新官方法律法规为准。”
3. 复杂案情的理解局限：国家赔偿案件有时非常复杂，涉及多行为、多机关、法律竞合等问题，当前的大模型可能难以完全厘清。
   • 应对策略：设计分步骤、引导式的交互。不要指望用户一次性输入所有复杂信息。通过多轮问答的形式，引导用户厘清侵权机关、行为性质、损害后果等关键要素，逐步构建案件画像。

5.2 用户体验与工作流融合

1. 输入门槛高：让律师用自然语言完整描述案情，本身就需要时间，且描述质量影响分析结果。
   • 避坑指南：提供结构化的输入表单作为备选。例如，提供“赔偿请求人信息”、“赔偿义务机关”、“侵权行为类型（下拉选择）”、“损害后果（复选框）”等字段。结构化数据更利于AI准确处理，也符合律师填写法律文书的习惯。
2. 输出结果难以直接使用：生成的文书草稿格式混乱，或计算过程不够透明。
   • 避坑指南：输出必须是“律师友好型”。计算部分提供清晰的明细表；文书生成支持导出为.docx格式，并尽量保持与法院要求一致的排版样式。允许用户一键复制计算结果到剪贴板。

5.3 安全、合规与伦理考量

1. 数据隐私：案件信息极度敏感。
   • 核心原则：默认所有数据处理在用户本地设备或其完全控制的服务器上进行。如果提供云端服务，必须采用端到端加密，并明确告知数据存储策略，提供数据删除功能。最佳模式是提供可私有化部署的解决方案。
2. 责任界定：AI工具出错导致律师工作失误或当事人损失，责任谁负？
   • 必须明确：工具是“助手”，律师是“决策者”。在用户首次使用时，必须强制阅读并同意一份详细的免责协议，明确工具的辅助性质，强调最终结果必须由持证律师专业判断和复核。所有AI生成的内容都应带有“此为AI生成建议，请谨慎核对”的水印或提示。
3. 技术依赖与能力退化：过度依赖AI可能导致年轻律师基础技能生疏。
   • 设计思考：在工具中融入“学习模式”。例如，在展示计算结果的同时，可以提供一个“查看计算原理”的折叠按钮，详细解释公式和标准来源。在引用法条时，可以链接到该法条的完整上下文和关联案例。让工具同时成为学习平台。

开发这样一个专业工具，最大的体会是必须在“AI能力”与“人的掌控”之间找到精妙的平衡。技术再强大，也无法替代法律工作者专业的判断力和责任感。工具的价值在于处理那些确定、繁琐的部分，从而释放出人的精力，去专注于案件中那些真正需要创造性思维、价值权衡和情感沟通的核心环节。最终，一个成功的法律AI工具，不是要成为律师，而是要成为律师手中最得心应手的那支“笔”，让法律服务的质量和效率，都能向前迈进扎实的一步。