简介：基于RAG架构的智能法律问答系统项目，定位于法律咨询场景下的智能问答实现，面向自然语言处理、法律信息化方向的开发者、科研人员及高校学生。项目整合检索与生成两条技术路径，先在大规模法律文档库中检索相关片段，再驱动模型生成回答，兼顾专业性与响应效率，能够帮助阅读者快速理解RAG在专业领域问答中的落地方式。压缩包共217个文件，约2.35MB，以178个txt文本为主体，涵盖法律知识库语料、项目说明与配置细节；另有9个Python脚本承担核心逻辑，HTML、CSS、JS文件共同构成前端界面，辅以YAML配置、License等文件，整体目录层次清晰，便于按模块查阅。当前已有92人学习下载。资源提供完整可读的极简说明与代码骨架，包含知识库编辑、上传、注册登录等页面实现，以及检索生成流程的模块划分，并附有前端样式与交互配套，便于复现基础流程、核对关键步骤，也为后续扩展新功能提供了清晰的起点。
1. 智能法律问答为什么绕不开RAG：先想清楚再动手
用户在对话框里打出“帮信罪和掩饰隐瞒犯罪所得罪怎么区分”，普通大模型会流畅地给出几句四平八稳的答案，但你追问“依据是哪一条司法解释”时，它可能就开始含糊其辞。这正是法律咨询场景里最危险的事——法律条文是白纸黑字的硬约束，说错一个罪名构成要件，后果不是“答得不够好”，而是“把用户带进沟里”。基于RAG架构的智能法律问答系统，核心思路就是不让大模型凭空记忆法条，而是先从法律知识库里检索出相关条文，再让模型基于检索结果组织回答。这套方案解决的是大模型幻觉与法律精确性之间的根本矛盾，适合正在做法律AI产品、企业法务助手或政务咨询系统的开发者。读完你会知道RAG在这条赛道里怎么落地、参数怎么调、坑在哪里。
2. 把RAG架构拆开看：检索、增强、生成三段各管什么
2.1 检索增强生成的三段式：先检索再作答的流程
RAG架构全称Retrieval-Augmented Generation，中文叫检索增强生成。它把回答一个问题拆成三步：第一步是检索，从预先构建的知识库里找出与用户问题相关的文本片段；第二步是增强，把检索到的片段拼进提示词，作为大模型的“参考资料”；第三步是生成，大模型只看参考材料来组织答案，不依赖自己记忆里的法律知识。就这三步，硬生生把“凭记忆答题”变成了“开卷答题”。
这个架构最核心的价值在于：知识是外挂的，不是模型背下来的。法律条文更新、司法解释出台、地方性法规差异，都不需要重新训练模型，只需要更新知识库。传统微调方案遇到法条修订就得重新跑一遍训练流程，而RAG方案改一条法律条文，在知识库里改一个文档就行。对法律这种高频变动、地域差异大的领域来说，这个特性决定了RAG几乎是唯一务实的选择。
2.2 为什么法律场景必须走RAG而不是直接问大模型
大模型的训练数据有截止日期，而法律条文是持续变动的。比如某部法律在2023年修订后的新条款，大模型如果训练数据截止在2022年，它会理直气壮地给出旧版答案。更麻烦的是，法律条文之间的关联是链式的——一个罪名可能散落在刑法分则、司法解释、量刑指导意见多个文件中，大模型在生成时很难记住这些文件之间的引用关系。
法律问答还有一个特殊要求：回答必须可溯源。用户问“劳动法第几条规定的N+1赔偿”，哪怕模型答对内容，没有标注具体条款号，用户也没法拿去跟HR对峙。RAG天然适合做溯源，因为生成时喂给模型的检索片段里自带出处，Prompt里可以强制要求模型在回答中标注引用来源。这是普通大模型对话做不到的，也是法律问答系统必须用RAG的根本原因。
2.3 系统模块划分：从文档入库到答案返回的完整链路
一个完整的RAG法律问答系统，在部署形态上可以拆成离线与在线两条链路。离线链路负责知识库构建：法律文本清洗、条文切分、向量化、建立索引，这一部分按批次运行，比如每天晚上跑一次增量更新。在线链路负责实时问答：用户提问、检索召回、重排序、拼接Prompt、调用大模型、返回答案。两条链路共用同一个知识库存储层。
模块划分用一张表能看得很清楚：
| 模块 | 职责 | 常见实现 |
|---|---|---|
| 文档解析 | 把PDF/Word格式的法律文本转成结构化文本 | OCR + 格式清洗 |
| 文本切分 | 把长文档切成适合检索和嵌入的片段 | 按条、款、项切分 |
| 向量化 | 把文本片段转成稠密向量 | Embedding模型 |
| 索引存储 | 存向量和原文，支持相似度检索 | 向量数据库 |
| 混合检索 | 向量召回 + 关键词召回合并 | BM25 + 向量检索 |
| 重排序 | 对召回结果重新打分 | Rerank模型 |
| Prompt组装 | 把检索结果嵌入提示词模板 | 模板引擎 |
| 大模型生成 | 基于检索结果生成答案 | LLM API或本地部署 |
这套模块设计里，最容易低估的是文档解析环节。法律文本的原始格式千奇百怪，有扫描版的政府公报、有排版混乱的司法解释、有带修订说明的条文汇编。如果源头解析不干净，后面所有环节都会跟着错。我一般会在解析环节加一层人工抽检，随机抽10%的文档检查切分结果，这一步看着笨，但比任何智能清洗都好用。
3. 构建法律知识库：条文切分、向量化与索引
3.1 法律文本的切分策略：按条款而不是按字数硬切
知识库构建的第一步是切分。很多RAG教程里默认按固定字数切分，比如每500字切一段，重叠50字。这套做法在新闻、博客类文本上没问题，但法律文本这么切就是灾难。一条刑法条文经常超过500字，硬切会把“构成要件”和“刑罚规定”切成两段，检索时只召回前半段，模型只看到构成要件没看到量刑，答出来的东西轻则缺项，重则误导。
法律文本的正确切分单位是“条”和“款”。我常用的策略是先做结构解析：把文本按“第X条”拆成条款块，再在条款内部找“第X款”“第X项”作为子块。切分完成后，每个块保持独立的语义完整性，同时记录它的上级结构信息——比如“刑法第二百六十六条 诈骗罪”这个块，要存住它所属的编、章、节路径。
这里有一个参数要特别说明：chunk_size和chunk_overlap。即使按条款切分，有些超长条款还是需要二次切分，这时候chunk_size可以设到800到1200字，overlap设100字左右。overlap的作用是防止句子在切分边界被截断，法律术语里“以上”“以下”这种限定词如果被截到上一段末尾，模型会误读范围。
3.2 向量化模型的选择：通用Embedding在法律场景的偏差
切分完的条文要转成向量才能做语义检索。这里有个坑：通用中文Embedding模型在训练语料上见过大量新闻、百科、社交文本，但对法律文本的语义把握明显偏弱。“故意伤害”和“故意杀人”这两个罪名，通用模型算出的向量相似度可能很高，因为它们在通用语料里经常出现在同一篇文章里，但在法律语境里这是两个天差地别的罪名。
解决思路有两个方向。第一，选在法律语料上做过领域适配的Embedding模型，现在有不少面向中文法律的开源模型，效果比通用模型好一截。第二，如果只能选通用模型做基线，就一定要搭配关键词检索做混合召回，用BM25把“故意伤害罪”这类精确匹配的条文捞回来，弥补向量检索的语义模糊问题。这属于RAG实战里最典型的组合策略——稠密检索管语义泛化，稀疏检索管精确匹配，两者互为兜底。
3.3 混合检索：向量召回加BM25关键词召回的代码示例
混合检索是法律问答系统召回阶段的推荐做法。下面给一个最小可运行的实现框架，用Python写，具体逻辑是：向量检索召回Top N结果，BM25召回Top N结果，合并后按融合分数排序。你可以在自己的环境里直接改成异步版本或者换成具体的向量库客户端。
# 混合检索：BM25 + 向量召回融合 # 依赖：rank_bm25, numpy, 以及你选用的向量库客户端 import numpy as np from rank_bm25 import BM25Okapi def hybrid_search(query, doc_chunks, chunk_embeddings, embed_model, top_k=10, bm25_weight=0.3, vector_weight=0.7): """ query: 用户问题文本 doc_chunks: 知识库片段列表（按条款切分后的文本） chunk_embeddings: 所有片段对应的向量矩阵 embed_model: 用于把query转向量的Embedding模型 top_k: 最终返回的片段数 """ # 1. 向量召回：算query向量，对所有片段求余弦相似度 query_vec = embed_model.encode([query])[0] # 假设chunk_embeddings是L2归一化后的矩阵，点积即余弦相似度 vector_scores = np.dot(chunk_embeddings, query_vec) # 2. BM25召回：对query做分词，对原文打分 tokenized_corpus = [chunk.split() for chunk in doc_chunks] bm25 = BM25Okapi(tokenized_corpus) bm25_scores = bm25.get_scores(query.split()) # 3. 分数归一化后加权融合 vec_norm = (vector_scores - vector_scores.min()) / \ (vector_scores.max() - vector_scores.min()) bm25_norm = (bm25_scores - bm25_scores.min()) / \ (bm25_scores.max() - bm25_scores.min()) fused_scores = vector_weight * vec_norm + bm25_weight * bm25_norm # 4. 取Top K，返回原文和分块元数据 top_indices = fused_scores.argsort()[-top_k:][::-1] results = [] for idx in top_indices: results.append({ "text": doc_chunks[idx], "score": float(fused_scores[idx]), "vector_score": float(vec_norm[idx]), "bm25_score": float(bm25_norm[idx]) }) return results这段代码的逻辑说明：先算query的向量表示，跟知识库所有片段做点积得到向量相似度；再用BM25做词面匹配，处理那些向量模型没学好的精确术语；两个分数各自归一化到0到1，加权相加。权重参数bm25_weight和vector_weight是经验值，我一般从0.3和0.7起步，词面匹配要求高的场景可以调成0.5和0.5。
参数说明：top_k控制召回数量，法律问答场景一般设10到20，太少容易漏条款，太多会把不相关的内容塞进上下文噪声里。两个权重里，vector_weight偏向语义理解，bm25_weight偏向精确匹配。如果发现“同类罪名混淆”的坏case变多，就调高vector_weight；如果发现“精确条款号检索不到”，就调高bm25_weight。
4. 检索与生成的关键参数：让系统回答更准的调参路径
4.1 检索参数：top_k、相似度阈值与Rerank的必要性
检索参数直接决定喂给大模型的材料质量。这个环节做过RAG的人都懂一个道理：检索质量决定上限，生成质量决定下限。材料检索错了，大模型再聪明也答不对。top_k不是越大越好，法律文本里相邻条款内容相近，召回太多会导致上下文窗口里塞满重复信息，模型反而分不清主次。
相似度阈值是一个需要小心调的参数。设太高，用户换个说法提问就直接拒答；设太低，不相关的条文全都进来了。我实践下来，法律场景的向量相似度阈值一般设在0.45到0.55之间，具体数值取决于你用的Embedding模型分布。建议先在验证集上跑一遍，把所有query的召回分数分布画出来，再决定阈值，不要拍脑袋。
Rerank这一步在RAG架构里容易被新手跳过，但在法律场景里我劝你加上。初召回的Top 10里可能有3条是真正可用的，其余是语义相近但不够精确的条文。用一个Rerank模型对候选集重新打分，能把“第二百六十六条诈骗罪”排到“第二百六十六条之一”前面，这种精准度是纯向量检索做不到的。Rerank模型从0.5秒到2秒的推理延迟，在线问答场景里可以接受。
4.2 生成参数：temperature、max_tokens与提示词模板
生成阶段参数直接影响答案的确定性。法律回答要求严谨，temperature要压低，我一般设0.1到0.3，再高模型就开始自由发挥了。max_tokens要结合法律答案的特点来设——法条原文加司法解释的回答可能超过800字，max_tokens设太小会被截断在关键位置，设太大又拖慢响应。经验值是1600到2000，具体看你上游检索片段最长多少。
提示词模板是RAG系统里最简单但最容易被忽视的部分。我给一个基础模板的写法：把检索到的条文按编号放进去，明确告诉模型只能使用下列资料，并且回答必须带引用标注。模板里还要留一个空位给“用户问题”，以及一个“如果资料无法回答，请明确说不知道”的约束。这最后一句很关键，它比任何参数都能有效遏制幻觉。
# Prompt模板示例（伪代码，实际使用时替换为你的模板引擎语法） prompt_template = """ 你是智能法律问答助手。请严格依据以下法律资料回答用户问题。 禁止使用资料之外的任何法律知识作答。如果资料不足以回答问题，明确回复"资料不足"。 参考资料： {context_chunks} 用户问题：{user_query} 要求： 1. 答案必须出自参考资料； 2. 每条结论后用[条款编号]标注来源； 3. 如果参考资料包含新旧条款冲突，以发布时间最新的为准； 4. 不要解读立法意图，只解释条文内容。 """参数说明：context_chunks是混合检索合并后的Top K片段，按分数降序排。user_query是用户输入。条款编号标注用的是检索时保留的元数据，不是让模型自己编。这个模板的核心逻辑是“限制性生成”而不是“开放性写作”。如果大模型生成时总爱加戏，就在系统提示词里追加一条：“当且仅当资料中有明确对应条文时才能回答。”
4.3 引用溯源：法律回答必须带出处，否则等于没答
引用溯源是法律问答系统区别于通用问答的特征功能。实现方式不复杂：检索阶段保留每个片段的文档名、条款号、版次信息；生成阶段在模板里强制要求模型在每条结论后标注来源；最后做一个后处理校验，检查模型输出的引用标注是否真的存在于检索片段中。
后处理校验这一步建议用正则加白名单实现。白名单是当前检索片段里的条款编号集合，模型输出的引用编号不在白名单里，就判定为幻觉引用，做一轮纠正或直接截断该条结论。这个校验逻辑简单粗暴但有效，它拦截了模型最常见的“编造条款号”行为。
这里可以多说一句知识库升级路径。纯文本片段做检索有个天然缺陷——它不知道“诈骗罪”和“合同诈骗罪”之间的从属关系。如果想让系统具备“根据上位法推断下位法效力”的解释能力，就要把文本知识库升级为结构化的知识图谱（KG）表示，把罪名、法条、司法解释之间的关系显式建模。这是从“能查到”迈向“能推演”的一步，工程量大很多，但法律场景的长尾价值就在这里。
5. 法律问答系统的避坑记录：我踩过的5个坑
5.1 坑1：按字数切分把一条法条切成两半
现象：用户问“寻衅滋事罪的量刑标准”，系统只返回了前半段“构成要件”，没有返回后半段“处五年以下有期徒刑、拘役或者管制”。答案看起来答非所问。
原因：初版按固定500字切分，一条刑法条文被拦腰截断，检索时只命中了包含“寻衅滋事”关键词的前半段，后半段“处X年”没有被召回。
解决：改成按“第X条”先做结构切分，把一条条文作为一个最小单位，如果长度超过Embedding模型的max_token限制，再做句级二次切分并保留父条目引用。这个改动上线后，量刑类问题的准确率提升非常明显。
5.2 坑2：只靠向量检索，常见罪名检索不到
现象：用户问“盗窃罪判几年”，向量检索返回的全是“抢劫罪”“诈骗罪”相关条文，BM25关键词召回一关，盗窃罪的原文档瞬间就排上来了。
原因：通用向量模型在语义空间里把“盗窃”“偷窃”“扒窃”这几个词拉得很近，但对法律术语“盗窃罪”与“抢劫罪”之间的边界不敏感。这是典型的rag瓶颈——语义相似不等于法律等价。
解决：召回阶段强制加入BM25或ES的match查询，对“罪名全称”“条款编号”“法条标题”这类高精确字段做词面匹配，并与向量分数加权融合。混合检索不是可选项，是法律RAG的必选项。
5.3 坑3：相似度阈值设太高，用户换句话就拒答
现象：用户说“我朋友被拘留了能取保候审吗”，系统回复“资料不足”。同一个问题换成“取保候审的条件是什么”就能正常回答。
原因：阈值定在0.7，口语化表达和法条原文在字面上差太远，向量相似度只有0.55，直接被过滤了。阈值不是越高越好，它是召回精度和召回率的平衡杆。
解决：把阈值降到0.5，同时增加一个兜底逻辑——低于阈值但BM25命中关键词的，先走Rerank模型二次判断，不要直接丢弃。这个兜底逻辑比阈值本身更管用。
5.4 坑4：检索到了但生成时模型不按资料走
现象：检索片段里明确写着“处三年以下有期徒刑”，模型回答里却写“处三年以上五年以下有期徒刑”。内容对不上参考材料。
原因：大模型在生成时倾向于“把答案补全成一段流畅的话”，参考材料里没写到的东西它会用训练记忆里的知识补上。这就是RAG系统里最常见的幻觉残留。
解决：临时把temperature降到0.1，然后在模板里追加“如果参考资料没有明确提供该信息，请直接回复未知”。再上升一步，做引用后处理校验，对模型输出的每一条结论与检索片段做匹配检查，发现问题时用检索片段重写输出。
5.5 坑5：新旧条文冲突，系统不说话
现象：某地方性法规在2024年修订后删除了旧条款，但知识库里同时还保留着旧版文件。用户问“XX市出租车管理条例第一条规定”，系统把新旧两版条文都召回了，模型自己都不确定该用哪个。
原因：法律知识库没有建立版本管理，同一个条款号对应了多个版本。模型无法判断优先级，只能含糊其辞。
解决：入库时给每个片段打上生效日期与失效日期标签，检索时对日期做过滤——只保留用户提问时间点当前有效的版本。如果新旧版本并存，强制按“新法优于旧法”的规则排序，并在引用里显示“2024修订版”字样。
6. 把RAG法律问答做扎实：一个值得做的验证框架
系统上线后最怕的是今天改了个参数，明天效果变差，还找不到原因。我的做法是建一个固定评估集，每次改动都跑一遍对比。评估集的关键不是数量大，而是覆盖三类典型问题：法条精确查询（“刑法第二百六十六条是什么”）、语义泛化查询（“借钱不还算不算诈骗”）、案件要素查询（“工作三个月被辞退有赔偿吗”）。每组各准备20到30条，手写标准答案并标注所引条文。
评估指标要跟踪三个：条文召回准确率——标准答案里的法条是否出现在召回Top 5里；引用准确率——模型输出的引用标注是否真实存在于召回段落中；拒答率——不该答的问题有没有明确拒绝。我做完一个项目，例行实操是先跑一遍旧版本基线，再跑新版本，对比三个指标的差值，差距超过两个百分点的改动才允许上线。用这个框架测过就会明显感觉到，调温度再大胆都不过分——因为引用还行，摘要也没乱改。最后一次调参里最有用的一个改动是把向量检索的top_k从10提到15，混合检索的时候bm25权重抬到0.4，整体准确率稳定提升而且跑了很多轮都一样。希望这个思路对你有用，也希望你踩过的坑比我少。
本文还有配套的精品资源，点击获取
