法律咨询助手RAG落地记 - 我把每个咨询的响应成本压到了三毛钱

为什么选这个场景

一个做法律科普的朋友找我帮忙：他想做一个面向普通人的法律咨询助手，用户输入“房东不退押金怎么办”这类问题，系统给出基于真实法条的参考意见。他是独立开发者，预算有限，人手就他自己。

这类场景的核心矛盾很典型：通用大模型对法律条文一知半解，容易编造不存在的法条（幻觉问题在法律场景是致命的）；而微调模型对独立开发者来说成本高、周期长、数据也凑不齐。检索增强生成（RAG）几乎是唯一现实的选择——把《民法典》等法条文本切块、向量化、检索后拼进提示词，让模型“开卷考试”。

业务痛点：时间、成本、风险三座山

动手前我们先算了一笔账，这也是本文的效率视角主线：

痛点一：幻觉风险带来的人工校验成本。 早期直接调通用模型做测试，十条回答里约有三条引用了错误的法条编号或凭空出现的“司法解释”。朋友不得不逐条人工核对，处理一条咨询的有效时间约8分钟。如果按一天200条咨询估算，光核对就要占用近27小时人工——根本不可能商业化。

痛点二：多模型试错成本高。 落地RAG需要反复对比模型：检索重排、答案生成、摘要压缩，不同环节适合不同模型。如果每个模型都单独申请Key、单独写适配代码，每接入一个新模型的开发+调试时间约半天，一旦某模型涨价或限流，切换又是半天。

痛点三：延迟直接影响用户体验。 法律咨询用户提问往往很长，早期端到端响应超过25秒，跳出率肉眼可见地高。

架构设计

最终架构分五层，全部跑在一台2核4G的云服务器上：

用户提问
   │
   ▼
┌─────────────┐
│ 意图澄清层   │ 小模型：判断问题类型、补全省略主语
└──────┬──────┘
       ▼
┌─────────────┐
│ 检索层       │ 向量库（法条切片，512 token/片）
└──────┬──────┘  + BM25混合检索 + 重排模型
       ▼
┌─────────────┐
│ 生成层       │ 大模型：只基于检索到的法条作答，
└──────┬──────┘  强制要求标注条文出处
       ▼
┌─────────────┐
│ 校验层       │ 规则引擎：校验引用的条文编号真实存在
└──────┬──────┘
       ▼
结构化回答（结论 + 法条依据 + 行动建议 + 免责声明）

两个关键设计决策：

1. 法条切片按“条”为单位，不按固定长度切。法律条文的完整性优先于向量检索的均匀性，这一步让检索准确率明显提升。
2. 生成与校验解耦。引用校验用规则引擎而不是再调一次大模型——条文编号是否存在于法条库，一次字符串匹配就能完成，省掉了不必要的token开销。

关键实现步骤

第一步：语料准备（约2天）。 收集《民法典》劳动、租赁、消费维权等高频领域的条文，共约1.2万条，按条切分并附加领域标签。清洗过程中发现原语料有3%的乱码和重复条目，这步不能省。

第二步：建向量索引（半天）。 用嵌入模型批量向量化，混合检索（向量+关键词）解决纯语义检索对精确条文编号不敏感的问题。

第三步：提示词与生成链路（1天）。 核心提示词约束：

PROMPT = """你是一个法律咨询助手。请严格遵循以下规则：
1. 只能基于下方提供的法条片段回答，禁止引用未出现在片段中的条文
2. 每个结论后用【条文：第X条第X款】标注出处
3. 如果检索到的法条不足以回答问题，明确说"根据现有资料暂无法回答"，并建议咨询律师
4. 结尾必须附上"本回答仅供参考，不构成法律意见"

法条片段：
{retrieved_chunks}

用户问题：{question}"""

第四步：统一AI API网关接入（关键效率决策）。 所有模型调用——意图澄清的小模型、嵌入模型、重排模型、生成的大模型——统一走一个AI API网关。这一步是整个项目维护成本的分水岭：

• 一处配置，处处生效。应用代码里只写网关地址，换模型只需在网关后台改路由配置，代码零改动。实测切换一个生成模型从原来的半天降到10分钟以内。
• 统一计费与监控。所有调用在一个后台看消耗，哪个环节烧钱一目了然，不用登录五六个平台对账。
• Key不再散落。应用服务器上只有一个网关Key，泄露风险面大幅收窄。
• 多模型对比零成本。做A/B测试时，同一个请求改个模型名参数即可，不用为每个候选模型单独申请账号、充值、写适配层。

第五步：压延迟与压成本（2天）。 前后对比数据：

成本下降的三个来源：意图澄清和摘要交给便宜的小模型（占调用量60%）；检索片段做过相关性重排，只送最相关的5条进提示词，上下文token减少近一半；高频问题（如“试用期辞职”）加了语义缓存，命中后直接返回。

踩过的坑

一是重排模型不是必需的，在1.2万条的小库上，纯混合检索+简单打分已经够用，加重排反而多一次网络调用、多0.8秒延迟。二是免责声明必须写在提示词里强制输出，法律场景的合规底线，别指望模型自觉。

写在最后

这个项目从立项到可对外服务，一个人、六个工作日。回头看，最划算的决策不是选了多强的模型，而是把模型层统一收敛到AI API网关——它让后面所有的模型替换、成本实验、多模型分工都变成了改配置而非改代码。对独立开发者来说，省下的每一次“改适配代码”，都是可以拿去做新功能的时间。

如果你也在准备落地自己的RAG应用，可以先注册一个统一的AI API网关试试：https://api.thistoken.ai/register

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。