导语

30天，我们从AI是什么，一路学到了如何建立AI工作流、如何进行模型微调、如何设计评测体系、如何防御Prompt Injection。知识已经足够多，但”知道”和”做到”之间，还差一个完整的项目。

纸上得来终觉浅，绝知此事要躬行。今天，我们将用一个完整的实战项目，把30天学到的所有知识串联起来。

这个项目是：为一个律所构建AI法律咨询助手。

从需求分析开始，到工具选型、模型微调，开发实现、安全加固、上线部署、效果评测——我们将走完一个AI项目从0到1的完整生命周期。

一、需求分析：从真实痛点出发

1.1 背景介绍

我们服务的客户是一家中等规模的律师事务所，有20名律师、10名助理、5名行政人员。律所的主要业务包括：企业常年法律顾问、民事诉讼、知识产权、婚姻家庭等。

他们的痛点是：律师们每天要花大量时间回答客户的简单咨询问题，比如”合同应该怎么写”、”这个条款有没有法律风险”、”我们这种情况能起诉吗”。这些简单问题占据了律师30%以上的时间，但收费却很低。

老板的需求是：用AI来回答这些简单法律咨询，让律师专注于高价值的法律服务。

1.2 需求拆解

接到这个需求，我们不能直接开始开发。第一步是把笼统的”AI法律咨询”拆解成具体的功能点。

功能需求：

第一，常见法律问题问答。如劳动纠纷、合同审查、知识产权保护等常见问题，AI能够给出准确的法律建议。

第二，合同条款分析。用户上传合同文本，AI能够识别其中的风险点并给出修改建议。

第三，法律文书生成。根据用户需求，AI能够生成简单的法律文书框架，如起诉状、答辩状等。

第四，案例检索。当用户描述案情时，AI能够检索相关的法律条文和参考案例。

非功能需求：

第一，准确率要求。涉及法律的内容，准确率必须达到95%以上。

第二，响应速度。用户等待时间不超过3秒。

第三，安全合规。必须符合《生成式人工智能服务管理暂行办法》的要求。

第四，可审计。所有AI生成的内容都必须有记录，方便后续追溯。

1.3 边界定义：什么不能做

在AI应用在法律领域，边界定义比功能定义更重要。

AI不能替代律师。这是一个根本原则。AI给出的所有回答都必须明确标注”仅供参考，不构成法律意见，如有需要请咨询专业律师”。

AI不能给出具体法律结论。比如用户问”我这种情况能赢吗”，AI只能分析相关的法律因素和可能的走向，不能直接预测案件结果。

AI必须有人工复核机制。对于涉及金额超过一定阈值、或涉及重大权益的咨询，必须有人工律师复核后才能输出给用户。

二、工具选型：如何选择合适的技术方案

2.1 模型选择

基于法律咨询的场景特点，我们来选择合适的模型。

核心考量因素：

准确性是第一位。法律领域对错误信息的容忍度极低，一个错误的法律条文引用可能导致严重的法律后果。

中文能力很重要。法律文书有特殊的语言表达方式，需要模型有较强的中文能力。

上下文长度需要支持长文本。合同分析、案例检索都需要处理大量文本。

推理能力要强。法律问题往往需要多步推理，模型需要能够进行复杂的逻辑分析。

候选模型对比：

GPT-5.2：准确率高，中文能力高，上下文200K，推理能力极强，成本高。

Claude-4：准确率高，中文能力高，上下文200K，推理能力强，成本中高。

Kimi-Plus：中文能力极高，上下文1M，推理能力中强，成本中。

通义千问2.5：中文能力高，上下文128K，推理能力中，成本低。

考虑到准确率要求高、但预算有限，我们选择DeepSeek-V4作为主力模型，它在中文法律语料上表现优秀，推理能力强，成本可控。对于需要更长上下文处理大型合同的场景，Kimi-Plus作为补充。

2.2 技术架构

系统的技术架构设计如下：

接入层：微信公众号、网页端API、企业微信三个入口，统一接入。

业务逻辑层：包括意图识别模块（判断用户问题类型）、法律知识检索模块（基于RAG技术）、回答生成模块（调用大模型）、合规检查模块（确保输出符合要求）。

数据层：包括法律知识库（以向量数据库存储）、历史会话存储、合规日志记录。

安全层：包括Prompt Injection过滤器、敏感信息识别、人工复核工作流。

2.3 工具链清单

以下是项目使用的核心工具：

模型服务：使用硅基流动API调用DeepSeek-V4和Kimi-Plus。

向量数据库：使用Milvus存储法律条文和案例的向量表示。

后端框架：使用FastAPI构建RESTful API服务。

部署平台：使用阿里云PAI进行模型服务和API的部署。

三、数据准备：构建法律知识库

3.1 法律知识库的内容

法律知识库是系统的核心。一个好的法律知识库应该包含以下内容。

法律法规：包括民法典、劳动合同法、公司法、知识产权法等基础法律，以及各地方的实施条例。

司法解释：最高法、最高检发布的各类司法解释，这些在实际判决中往往比法条更重要。

指导案例：最高人民法院发布的指导案例汇编，这些案例对同类案件有参考价值。

律所经验：律所过往服务中积累的成功案例和文书模板，这些是最贴近实际业务的知识。

3.2 数据处理流程

收集到原始数据后，需要经过以下处理流程才能入库。

第一步：清洗。去除HTML标签、乱码、特殊字符，统一格式。

第二步：分段。法律条文通常很长，需要按章节、条款进行分段。每段应该是一个独立的语义单元。

第三步：向量化。使用Embedding模型将每段文本转换为向量。Embedding模型选择paraphrase-multilingual-MiniLM-L12-v2，支持中文，效果良好。

第四步：入库。将分段的文本和对应的向量存储到Milvus数据库中。

3.3 知识库质量保障

知识库的质量直接决定了系统的回答质量。我们建立了一套质量保障机制。

准确性审核：所有入库的法律条文必须有明确来源，人工审核确认。

时效性更新：法律条文会随政策变化而更新，需要定期更新知识库。

用户反馈：当用户指出回答错误时，标记对应条文进行复核。

四、模型微调：让AI更懂法律

4.1 微调的必要性

通用大模型虽然强大，但在法律专业场景下仍有不足。

法律有特殊的表达方式，比如”意思表示”、”善意第三人”、”除斥期间”这些专业术语，通用模型可能理解不准确或者表达不专业。

法律有严格的逻辑链条，比如合同效力的判断，需要从主体资格、意思表示真实、不违反强制性规定等多个维度分析。

法律有本地的特殊性，比如不同地区的法院对某些问题可能有不同的裁判规则。

因此，我们需要对模型进行微调，让它更好地适应法律场景。

4.2 微调数据准备

我们准备了约5000条法律问答数据作为微调数据。

数据来源：律师人工标注的常见法律问答，律所历史咨询记录（脱敏后）。

数据格式：采用Instruction格式，包含任务描述、输入（用户问题）、输出（律师回答）。

质量控制：所有数据由资深律师审核确认，确保准确性和专业性。

4.3 LoRA微调实施

使用LoRA方法对DeepSeek-V4进行微调。

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj", "k_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)

model = get_peft_model(base_model, lora_config)

使用单张A100进行训练，耗时约8小时。

五、开发实现：从原型到生产

5.1 系统架构实现

系统的核心逻辑如下：

async def legal_consult(user_input: str) -> str:
    # 1. 意图识别
    intent = await identify_intent(user_input)
    
    # 2. 知识检索
    if intent == "法律问答":
        relevant_docs = await retrieve_knowledge(user_input)
    
    # 3. 生成回答
    prompt = build_prompt(intent, user_input, relevant_docs)
    response = await call_model(prompt)
    
    # 4. 合规检查
    safe_response = await safety_check(response)
    
    # 5. 添加免责声明
    final_response = add_disclaimer(safe_response)
    
    return final_response

5.2 RAG实现

检索增强生成（RAG）是系统的关键技术。

async def retrieve_knowledge(query: str, top_k: int = 5) -> list:
    # 1. 向量化查询
    query_vector = await embed_text(query)
    
    # 2. 向量检索
    results = milvus.search(
        collection_name="legal_knowledge",
        vector=query_vector,
        limit=top_k
    )
    
    # 3. 重排序
    reranked = await rerank_results(query, results)
    
    return reranked

5.3 Prompt Injection防御

针对法律场景的特殊性，我们实现了多层Prompt Injection防御。

输入过滤：对用户输入进行敏感词检测，拦截明显的注入尝试。

指令分离：系统指令和用户输入严格分离，用户输入被标记为”用户提供的内容”而非”可执行指令”。

输出过滤：AI输出经过安全检查，过滤可能的敏感信息和不当内容。

六、效果评测：科学验证系统价值

6.1 评测方案设计

系统上线前，我们需要进行严格的效果评测。

评测维度：准确率（法律条文引用是否正确）、专业性（表达是否规范）、有用性（回答是否能解决用户问题）、安全性（是否有合规风险）。

评测方法：由资深律师对100个测试case进行人工评分，每个case从四个维度打分1-5分。

6.2 评测结果

经过评测，系统取得了以下结果：

6.3 AB测试设计

上线后，我们进行了为期两周的AB测试。

A组使用AI辅助（当前版本），B组不使用AI（传统人工回复）。

结果显示，AI辅助组用户满意度提升15%，问题解决率（无需人工介入）达到72%，律师花在简单咨询上的时间减少了60%。

七、部署上线：从0到1的最后一公里

7.1 部署架构

生产环境部署在阿里云PAI上，采用以下架构：

API服务：3个实例，负载均衡，单实例4核8G。模型服务：2个实例，部署DeepSeek-V4和Kimi-Plus，GPU配置A10×1。数据库：RDS MySQL（结构化数据）、Milvus（向量数据）、Redis（缓存）。

7.2 监控告警

建立了完善的监控体系：

系统指标：CPU、内存、GPU使用率、API响应时间。

业务指标：日活跃用户、会话数、问题解决率。

安全指标：异常请求检测、注入攻击拦截统计。

设置了三级告警：warning（需要关注）、error（需要处理）、critical（需要立即响应）。

7.3 运维保障

数据备份：每日全量备份，每周增量备份。

故障恢复：制定了四级故障响应预案，最严重故障的RTO是30分钟。

合规记录：所有AI生成的对话内容保存180天，满足监管要求。

八、30天进阶总结

8.1 我们学到了什么

回顾这30天的进阶之路，我们从AI是什么开始，一路学到了：

基础能力：AI大模型的基本原理、提示词工程的核心技巧、上下文窗口的管理方法。

进阶技术：模型微调的LoRA/QLoRA方法、检索增强生成（RAG）的实现、评测体系的设计方法。

安全实践：Prompt Injection的攻击与防御、AI安全的系统性思考。

效率提升：AI工作流的建立方法、工具链的整合策略。

8.2 如何继续深入

30天只是一个开始。如果你想继续深入，以下是推荐的学习路径：

方向一：AI Agent开发。学习如何构建能够自主执行复杂任务的AI Agent，包括工具调用、多Agent协作、长期记忆等。

方向二：AI系统架构。深入学习如何在生产环境中部署和维护AI系统，包括模型服务化、性能优化、成本控制等。

方向三：AI安全工程。系统学习AI安全，包括对抗样本、模型安全、数据隐私等。

8.3 最后的建议

第一，立即动手。看完文章不等于学会，真正的学习发生在实践中。今天就开始用AI工具处理你的真实工作。

第二，建立自己的工作流。不要用别人的工作流直接套用，根据自己的场景调整优化。

第三，保持开放心态。AI领域变化极快，今天的最佳实践可能明天就过时了。保持学习的习惯，持续关注最新发展。

第四，安全第一。AI能力越强，安全风险越大。在追求效率的同时，时刻牢记安全底线。

结语

30天，我们一起走过了AI进阶的完整旅程。

从一个对AI好奇的新手，到能够独立完成AI项目的实践者——这个转变不是靠天赋，而是靠每天一点一滴的积累。

现在，轮到你了。去用AI解决真实的问题，去创造属于你的价值。

记住：AI不会取代你，但会用AI的人会取代你。

感谢这30天的陪伴。祝你在AI之路上越走越远。

互动话题：30天进阶之路结束了，你的下一步计划是什么？是继续深入某个方向，还是开始自己的第一个AI项目？欢迎在评论区分享你的想法和计划。

全系列回顾：

• Day1-10：提示词工程基础与进阶
• Day11-15：RAG、知识库与向量数据库
• Day16-20：AI Agent开发与架构
• Day21-25：AI Agent深度话题
• Day26：模型微调实战
• Day27：评测体系设计
• Day28：安全攻防
• Day29：效率工作流
• Day30：完整项目实战

感谢关注，欢迎转发给需要的朋友！