企业官网建设流程全解析

简介：《法务合规风控平台接入AI+大模型设计方案.pdf》是一份面向企业法务、合规与IT架构团队的系统性设计文档，针对传统风控平台难以应对海量数据与复杂法规的问题，提供AI大模型落地的完整思路。内容涵盖平台功能概述、现有技术架构梳理、大模型需求分析，以及系统架构、数据接口、模型训练调优等具体实施环节，并延伸到语义分析、风险评估、合规规则库建设、数据安全与隐私保护等模块，兼顾落地性与合规性。资源为单个PDF文件，压缩包大小997KB，章节组织清晰，适合需要构建或升级智能法务合规能力的中高级产品、研发与合规管理人员参考。目前已有85人在CSDN学习下载，可用于方案设计、项目申报或内部技术预研的场景参考。

1. 法务合规风控平台接入AI+大模型：先写设计方案，不是流程主义而是保命

“法务合规风控平台接入AI+大模型设计方案”这个标题，听起来像一份会在共享盘里落灰的立项文档，但它实际是整个项目的第一道保险。我见过太多团队把大模型直接怼到合同审查流程里，demo阶段跑得飞快，一进生产就被法务总监一句“这个结论依据在哪”问哑。法务风控的AI化，难点从来不在“会不会调API”，而在“回答能不能留痕、引用能不能溯源、业务边界能不能守住”。这份设计方案真正要回答的就是这三件事。后面我会把模型选型、知识库构建、提示词工程、部署架构和验收方法串起来讲，适合负责法务数字化落地的技术经理、合规产品经理，以及想把大模型落到业务系统里的后端工程师。

2. 选型与架构：把大模型放进法务体系里的正确位置

2.1 通用大模型与私有化部署：选型的分水岭在“数据出门”

法务平台里存着未公开的合同全文、劳动仲裁记录、资产收购条款。这些内容一旦离开内网，安全上就没法交代。所以选型第一问不是“哪个模型聪明”，而是“数据能不能出门”。我一般按三个档位来做部署决策。

选型第二问才是模型能力。开源底座里，基于Llama和Qwen两条技术线衍生出的模型在中文法律文本上各有优劣，评测榜单只能当参考。我惯用的做法是拿公司最近三年的脱敏合同做一组盲测，把“违约金条款找漏了”这类错误率直接量化，再决定底座。别迷信榜单，法务场景只信脱敏样本的实测结果。

私有化部署还有一个工程参数要提前定下来：70B量级的模型做AWQ 4bit量化后，权重占用约40GB显存。单张A100 80G能跑，但并发超过五路就会排队；如果预算只够两张4090，那就要接受低并发，或者上vLLM这类推理加速框架，用连续批处理和前缀缓存把吞吐拉上去。多模态模型不是必选项，只有合同扫描件、图片证据这类需求明确时再引入，否则推理成本直接翻倍。

2.2 从RAG到Agent：法务风控场景的三种落地形态

大模型在法务平台上常见的落地形态有三种，我按风险从低到高排成下面这样。

第一种是RAG增强生成，解决“制度问答”和“条款检索”。做法是把集团制度、合同模板切块后做向量化，用户提问时先检索再生成。这种形态回答带原文依据，是唯一可以直接上线的形态。

第二种是Agent多步流程，解决“合同审查”。把“条款抽取 → 风险比对 → 等级判定 → 修改建议”串成多步任务，每一步都能落日志。Agent在法务场景必须“有限自主”：模型只负责草拟结果，不允许直接盖章或发送，任何对外动作都要经过人工确认。

第三种是微调模型，只用于文书风格生成这一窄场景，比如律师函、合规意见书的初稿。注意，微调永远替代不了知识库，原因很直接：知识库今天更新制度，明天检索就生效；微调一次要攒数据、训模型、做回归，流程跑完公司制度早变了。

我常跟团队讲一个硬约束：没有“依据引用”的大模型回答，一律不允许出现在法务系统里。这条规则会贯穿整个设计方案。

2.3 最小可用架构：隔离区部署与SSE流式输出

架构设计上我倾向分成四层：接入层、应用层、模型服务层、数据层。接入层是法务门户和OA审批流；应用层跑合同审查、合规问答、风险预警；模型服务层放在隔离区，用内部域名提供服务，不直接暴露公网；数据层用向量库存切片，关系库存审查记录和审计日志。

模型服务层的部署有几个关键决策：模型推理服务与业务服务分机部署，避免大模型把CPU和内存吃满后拖垮业务应用；所有进出模型服务的日志完整落盘，包括请求原文、生成结果、耗时、命中的证据片段；对外接口统一走SSE流式返回。流式输出能让法务看到答案逐字出现，体感上比干等几十秒“转圈”好太多，同时前端连接断开时后端能即时中止生成，省GPU算力。

关于推理加速，我在生产里常用的组合是“AWQ量化 + vLLM”。AWQ把权重压到4bit，vLLM负责调度和连续批处理。这一套对法务这类高并发问答场景够用，但要注意：量化会损失一点精度，所以判决依据、法律条文这类关键内容，我不会让模型裸输出，而是强制走检索引用，在提示词里就堵住自由发挥的口子。

3. 让大模型读懂法务语言：知识库构建与提示词工程

3.1 制度、合同与判例的切分策略

知识库是法务大模型的命根子，而切分策略决定了知识库的质量。法务文档不能按固定512字符机械切块，不同文档类型要用不同策略。

制度文件按章节切。以“差旅管理办法”为例，每个章节标题作为切片边界，切分时把“制度名+章节号”拼进文本内容里，避免向量化时条款失去归属。切片大小我控制在800字符左右，重叠窗口设200字符，目的是让跨段语义不丢。

合同按条款编号切。每一条款作为独立切片，overlap尽量小，50字符就够，因为合同条款本身是强边界，跨条款切块反而会让检索结果混乱。判例按“争议焦点+裁判要旨”来切，不要一整份判决书丢进去，那样向量会被案由、事实认定这些次要信息稀释。

这里值得引入专门的知识抽取框架，比如OneKE这类工具，把条款里的“主体、义务、时限、金额”抽出来做成结构化字段，再灌进检索系统。这样用户问“保密义务最长多久”时，匹配的不只是文本相似度，还能命中结构化字段，召回质量差一个量级。切片入库的统一元数据格式如下：

{ "source": "采购合同模板-2024版", "clause": "7.2", "category": "违约责任", "effective_date": "2024-01-01", "department": "供应链管理部" }

这段JSON是每个切片必须携带的元数据。检索时按effective_date过滤过期制度，按category限定条款类型，按department区分子公司规则，能解决掉大量“制度更新了但模型还在答旧版”的问题。

3.2 提示词模板：把“合规审查”拆成可执行指令

给业务部门直接用的提示词必须固定成模板，不能让每个法务自己发挥。我设计了一套面向合同审查的提示词模板，效果比较稳定：

你是集团法务合规审查助手。你的工作只基于【上下文】中的原文条款， 禁止依据常识或记忆推断。没有依据时，直接回答“未检索到相关条款”。 审查点： 1. 合同主体是否完整，是否具备签约资格； 2. 付款节点与验收节点是否对应； 3. 违约金比例是否超过法定上限； 4. 保密义务是否有明确期限和违约责任。 输出格式，必须是JSON： { "risk_points": [ { "clause": "原文条款编号", "risk": "风险描述", "suggestion": "修改建议", "basis": "依据的原文片段" } ], "conclusion": "通过/需修改" }

模板设计有三个关键原则。第一，审查点必须显式罗列，让模型按清单办事，而不是“帮我看看这份合同”这种万能指令。第二，输出必须JSON化，方便下游风控引擎直接解析，不需要再做一遍文本清洗。第三，加入“没有依据就直说”的约束，这是对抗幻觉的最后一道闸门。

配套参数上，temperature必须调到0.1，top_p在0.3以下。法务审查不是创作，模型在这里的自由发挥都是事故。很多人翻车就是把默认的0.7拿过来直接用，结果模型把“应当”改成了“可以”，一个字的差别法律责任完全变味。

3.3 上下文工程：长度控制与关键证据召回

上下文工程的核心不是把模型窗口塞满，而是把预算花在刀刃上。我的分配方式是四段式：系统指令固定占0.5k token，检索证据最多占5k token，用户原文控制在2k token以内，最后预留1k token给模型输出。假设底座上下文是8k，那证据部分就不要超过5k，超长就截断或减少条目。

证据条目的数量也是调出来的：问答场景top_k设5，合同审查场景设8，超过10条相关证据时，模型反而会被不相关信息干扰，出现“对的证据被淹没”的情况。所以我一般会在向量召回后加一步重排，用bge-reranker这类模型把真正相关的条款顶到前面，再进上下文窗口。

这里要给一个具体计算习惯：中文场景下，1个汉字约合1到2个token，准备上下文时按2倍预算比较稳。比如你要塞进去一份3000字的合同条款原文，先按6000 token占位，其他部分就要压缩。宁可多轮调用模型分段审查，也不要硬塞完整合同。

4. 落地路径：合同审查、合规问答与微调边界

4.1 合同审查功能的实现：抽取要素与风险标注

落地时先做最小闭环：选一个合同类型，把提示词模板和条款原文拼装，调用本地模型服务，解析JSON结果。以OpenAI兼容的HTTP接口为例，实现如下：

# 合同审查：把合同原文与审查提示词拼成请求 import os import json import requests # 本地模型服务地址（隔离区内部域名，不直接暴露公网） LLM_URL = os.getenv("LLM_URL", "http://model-svc.internal:8000/v1/chat/completions") # SYSTEM_PROMPT 对应3.2节的提示词模板，工程里从配置文件读取 SYSTEM_PROMPT = open("prompts/contract_review.txt", encoding="utf-8").read() def review_contract(clause_text: str) -> dict: messages = [ # 系统指令固定，不随用户输入变化 {"role": "system", "content": SYSTEM_PROMPT}, # 每次只审查一条条款，避免整份合同导致上下文超长 {"role": "user", "content": f"请审查以下条款：\n{clause_text}"}, ] payload = { "model": "local-llama3-70b-awq", "messages": messages, "temperature": 0.1, # 审查任务要低随机性，防止条款被模型改写 "top_p": 0.3, "max_tokens": 1024, "response_format": {"type": "json_object"}, } resp = requests.post(LLM_URL, json=payload, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这段代码有两个值得注意的地方。第一，系统指令固定不变，用户输入只放当前审查的条款，这样能保证上下文窗口不被整份合同占满，模型也能聚焦到这一条上。第二，temperature=0.1是审查类任务的硬约束，很多翻车案例就是默认参数导致模型自由发挥。timeout设到60秒，大模型在长输入下首token有时要等十几秒，别因为超时设置太短误杀请求。

4.2 合规问答与检索增强：召回、重排与SSE流式输出

合同审查是单点式调用，合规问答则要先把证据捞出来，再带着证据去生成。结合SSE流式输出，完整逻辑是“检索 → 重排 → 拼接上下文 → 流式生成”。工程简化版如下：

# 合规问答：检索召回 + 流式生成，前端可中断 import json import requests def qa_retrieval(question: str): # 1. 向量召回，候选放宽到10条 docs = vector_search(question, top_k=10) # 2. 重排只保留最相关的5条，避免上下文被噪声填满 reranked = rerank(question, docs, top_n=5) context = "\n\n".join(f"[{d['source']}]\n{d['text']}" for d in reranked) payload = { "model": "local-llama3-70b-awq", "messages": [ {"role": "system", "content": "只依据上下文回答，没有依据就回答不知道。"}, {"role": "user", "content": f"上下文：\n{context}\n\n问题：{question}"}, ], "stream": True, # 开启SSE流式输出 "temperature": 0.2, } with requests.post(LLM_URL, json=payload, stream=True, timeout=120) as r: for line in r.iter_lines(): if not line: continue line = line.decode("utf-8") if not line.startswith("data:"): continue data = line[5:].strip() if data == "[DONE]": break token = json.loads(data)["choices"][0]["delta"].get("content", "") # 前端EventSource逐字渲染，用户断开时自动中止生成 yield token

逻辑上先宽召回再精排，是因为向量召回在前几轮往往会漏掉关键词精确命中的条款，重排模型能把真正相关的证据顶到前面。stream=True之后生成结果变成token流，前端用EventSource就能做实时渲染，法务觉得系统“快”，其实是首token返回快。用户关闭页面时连接断开，后端自动停止生成，省下来的GPU资源留给下一路请求。

提示：vector_search和rerank需要按你们向量库和重排模型的接口单独封装，上面只展示它们在问答链路里的位置。上线前要重点压测retrieval这一段的P95延迟，这一步通常比模型生成更影响体感。

4.3 微调的边界：什么时候必须微调、什么时候千万别碰

法务场景里80%的需求用RAG就能解决，不用碰微调。必须微调的只有两类：固定格式文书生成，比如律师函、合规意见书，要求开头、正文、落款格式严格一致；以及要素抽取的特殊字段体系，比如公司内部审批码、供应商等级这种外部模型没见过的枚举值。

微调方案我推荐LoRA，冻结底层权重只训适配器。数据量别指望500条就够，我的实际经验是最少攒2000条高质量指令-输出对，且每条都要经过法务复核。训练超参上，学习率设在1e-4附近，训练轮数控制在3个epoch以内，超过这个范围会出现灾难性遗忘，模型把原本会做的通用任务也丢了。GPU资源单卡A100 80G能跑7B到14B量级的LoRA，70B模型建议多卡并行。

微调前把旧模型快照留好，这是后悔药。微调和RAG不是二选一，更常见的做法是并行执行：RAG负责给模型喂证据，微调负责管输出格式。这样即使微调后的模型变笨了，证据链路还在，不会彻底失控。

5. 法务合规场景的五大踩坑实录：现象、原因与解法

5.1 现象：回答“看起来专业但完全跑偏”

法务问“集团对供应商账期的最长限制是多少”，大模型给出一个条文，内容读起来通顺，但对应的是另一家子公司的采购制度，结论完全不适用。这是典型的幻觉场景——模型把相近文本拼成了答案。

原因是检索阶段没有命中正确切片，重排又把相似但错误的制度排到了前面，而生成阶段没有强制“引用原文编号”。解决：第一，回答格式里增加“依据”字段，要求模型必须输出命中的制度名和条款编号；第二，给检索相似度设阈值，低于0.6直接拒绝回答；第三，重排阶段引入元数据过滤，按子公司维度先缩小区间再排序。

5.2 现象：制度库明明有答案，模型却答不出来

知识库里明明有“差旅报销标准”的全文，用户问“出差住宿上限”，模型说“未检索到相关信息”。第一个排查点是切分策略：如果整份制度被当成一个块塞进向量库，块太大会导致查询向量和整块文本的相似度被稀释，等于大海捞针。

解决方法是改成按章切块，每章带“制度名+章节号”前缀；再把BM25关键词检索和向量检索做混合，关键词精确命中优先。我在生产环境里把“关键词命中权重”调高到0.6，效果立竿见影。同时元数据里维护生效日期，检索时默认只召回当前有效版本，避免新旧制度混答。

5.3 现象：合同审查漏掉关键条款

合同里违约金明显超过法定上限，但模型给出的风险点里完全没有这一条。原因是审查提示词写得太宽泛，“帮我看一下这份合同有没有风险”这种万能指令给了模型太多自由发挥空间，它只会挑显眼的问题说。

解决思路是把审查点做成结构化清单，每个审查点单独成一个任务，并行调用模型，最后汇总结果。比如“付款节点比对”是一个任务，“违约金比例”是另一个任务，每个任务只聚焦一个维度。并发数翻了三倍，但漏报率从35%降到了不足5%。法务审查宁可慢一点，不能漏。

5.4 现象：回答延迟高，法务觉得“不如不接”

模型生成的完整答案要十几秒甚至更久，法务反馈“我还不如自己翻制度”。原因通常有两个：确认前端没有走流式接口，必须等模型全部生成完才展示；确认模型服务没有开启连续批处理，多路请求排队等待。

解决：上线前第一件事就是确认SSE流式输出链路通不通，让用户看到首token在1秒内出现；模型服务端开启vLLM的连续批处理和前缀缓存，相同制度提问的重复前缀不再重复计算。这一步能省掉一半的延迟，成本比换GPU低得多。

5.5 现象：微调后模型“学坏”了

微调前合同审查准确率还行，微调后新的文书风格有了，但模型开始把“应当”回答成“可以”，风险条款的判定也变松了。原因大概率是训练数据里混入了错误标签，模型学到了错误映射；或者全参微调把底座原本的能力覆盖掉了。

解决：第一，训练数据必须逐条法务复核，错误标签直接导致模型跑偏；第二，改用LoRA冻结底座权重，只训练适配器；第三，学习率降到1e-4、epoch控制在3以内。最关键的是微调完成后必须跑一遍回归测试集，把“应当/可以”这类易错点做成专项用例，一条不过都不能上生产。

6. 用红队测试集守门：上线前的验证与一条进阶技巧

6.1 构造红队测试集：三类问题与三个通过指标

上线前最值得投入的工作是做一套红队测试集。别只看模型的回答顺不顺，要看结构化指标。我的测试集分成三类：正常问题、对抗问题、超范围问题。对抗问题就是有意把相近但不同的制度条文放在一起，看模型会不会张冠李戴；超范围问题则是问薪酬、问未公开并购这类不该答的内容，看模型会不会越界。

三个指标里，我卡得最严的是幻觉率。正常回答可以错漏，但编造制度条款是零容忍。测试集不是一次性资产，每月要拿新制度、新合同样本扩充，否则模型一更新测试集就过期了。

6.2 一条进阶技巧：大模型输出先进“人工确认队列”

最后分享一个让法务团队接受度翻倍的技巧：大模型的输出不要直接落业务系统。AI生成审查意见后，先写入待确认队列，法务在界面上做一键确认或修改，确认后才进入正式审批流。

这样做的价值不只是“留痕可审计”，更重要的是降低法务的使用心理防线。他们知道系统只是助手，最终决定权还在人手里，采纳率反而大幅上升。整个方案的成功不取决于模型多聪明，而取决于整个链路里每一环都给业务留了控制权。

早期我为了赶进度跳过红队测试，直接让法务试用，结果被法务总监一句“依据第几条”问住。后来我把红队测试集当作版本发布门禁，过了才允许上测试环境。这个行业最怕的不是模型笨，而是方案把边界画得太乐观。希望帮到你。

本文还有配套的精品资源，点击获取