定完了大模型底座、想清楚了走 RAG 还是微调,私有化法律 AI 落地时还有一个绕不开的技术决定:用哪套向量库和检索引擎,去接住那 1.5 亿裁判文书、把律师真正要的类案精准找出来?这一层就是 RAG 的「检索」,它决定了 AI 回答有没有据可查、能不能回链、准不准。很多团队一上来就纠结「上 Milvus 还是 Qdrant」,却忽略了两个更要命的问题:法律检索能不能只用向量?检索准不准到底由什么决定?本文把这一层讲透:向量检索和关键词检索谁更适合法律、为什么法律 RAG 几乎一定要做混合检索、Milvus / Qdrant / pgvector / Elasticsearch 这几套主流可私有化方案怎么按五个维度比、检索层最容易埋的坑,以及一份可以直接照用的检索引擎选型自查清单。
一、先纠一个最贵的误区:法律检索不能只靠向量
检索层选型最常见、也最贵的一个错,是把「做 RAG」直接等同于「上一个向量库」,以为语义向量检索就是全部。对法律 AI 来说,这个思路会埋大雷,因为法律检索天然是「语义」和「精确」两种需求并存:
- 需要语义检索的场景:类案检索。律师描述一个案情大意,想找「事实和争议焦点相近」的历史裁判——这里用词千差万别、同义表达极多,靠向量的语义相似度才能召回意思接近但字面不同的文书。这正是向量检索的强项。
- 必须精确检索的场景:某条法条编号、某个具体案号、某个当事人或公司全称、某个特定罪名或案由。这些是「一字不差才算命中」的需求,靠语义相似度反而容易漏、容易召回一堆「差不多」的错项,必须靠关键词/全文精确检索(BM25 那一类)来兜底。
只上纯向量库,后一类需求会成片失灵。想象一下:律师给了准确案号,系统却因为「语义相似度不够高」查不出来,或者把一堆无关的「相似」文书排在前面——这种事发生一次,律师对整套系统的信任就崩了。所以法律 RAG 几乎一定要做混合检索:向量召回语义相近的,关键词召回精确命中的,再做融合排序。检索引擎选型的第一原则,不是「选哪个向量库」,而是「这套方案能不能优雅地把向量和关键词合在一起」。
一句话原则:法律检索是「大意找相似 + 关键找精确」的组合拳。把检索层设计成向量 + 关键词的混合,而不是二选一——这是法律 AI 检索区别于通用 RAG 最关键的一点。
二、检索层在 RAG 里到底是什么位置
先把检索层放回整条链路里看。一个法律 RAG 系统,从文书到答案,大致是这样几步,而向量库只是其中一环:
| 环节 | 它决定什么 | 选错的代价 |
|---|---|---|
| 数据切分(分块) | 每条文书怎么切成检索单元——决定召回的准确度上限 | 大——切砸了后面全糊 |
| Embedding 模型 | 把文本算成向量,中文法律语料上准不准——决定「语义相近」判得对不对 | 大——直接影响召回质量 |
| 向量库 / 检索引擎 | 把向量和关键词索引存起来、快速找出候选——决定检索快不快、扛不扛得住规模 | 中——影响性能与运维,但换得动 |
| 融合排序 / 重排 | 把向量和关键词的结果合并、重新排序——决定最终排在前面的对不对 | 中——可迭代调优 |
这张表要传达一个反直觉但很重要的判断:决定「检索准不准」的,主要是切分和 embedding;向量库主要决定「快不快、扛不扛得住规模」。换句话说,向量库是承接切好、算好的向量的「容器」,它选得好能让检索又快又稳,但它不能替你把切砸的分块和不适配的 embedding 救回来。所以这一节的意思不是「向量库不重要」,而是提醒你:选检索引擎的同时,必须同步把切分策略和中文法律 embedding 定好,否则选型选得再对,检索质量也上不去。下面第三节讲向量库/引擎本身怎么比,第四节回来讲最容易被忽略的混合检索与性能。
三、主流可私有化检索方案:Milvus / Qdrant / pgvector / Elasticsearch 怎么比
目前能完全私有化、离线部署的主流检索方案,大致分三类,各有侧重,没有绝对的「谁最好」,只有「谁更适配你的约束」:
| 方案 | 定位与擅长 | 比较适合的场景 |
|---|---|---|
| pgvector(PostgreSQL 扩展) | 给已有的 PostgreSQL 加向量能力,和结构化数据同库 | 切片在百万级、已经在用 PG、想少维护一个组件、结构化过滤需求重 |
| Milvus / Qdrant(专业向量库) | 为大规模向量检索而生,索引类型丰富、并发和性能强 | 切片千万到亿级、高并发、要精细调索引和带过滤的向量检索 |
| Elasticsearch / OpenSearch | 传统全文关键词检索的王牌,新版也支持向量与混合检索 | 关键词是主力、向量是补充,且要复杂过滤、聚合、高亮 |
选型别看名气或某个跑分,按下面五个维度对着自己的场景逐条比:
| 选型维度 | 看什么 / 为什么重要 |
|---|---|
| ① 数据规模与检索性能 | 你的文书切片到底是百万级还是亿级?规模决定要不要上专业向量库;别拿玩具级 demo 的表现推断亿级生产的表现 |
| ② 混合检索与结构化过滤 | 能否原生支持向量 + 关键词融合,以及按法院/年份/案由精确过滤——法律离不开这一条(见第四节) |
| ③ 私有化与信创适配 | 能否完全离线部署、数据不出内网;有信创要求时能否在国产芯片/操作系统上稳定跑 |
| ④ 运维复杂度与团队能力 | 专业向量库是分布式组件,多维护一套的成本别低估;团队扛不扛得住,决定选「省心」还是「够猛」 |
| ⑤ 生态与长期维护 | 社区活跃度、文档、和你技术栈的契合度;私有化一用就是几年,别选一个会断更的 |
为什么强调「按维度比」而不是直接给结论?因为一份写死「A 一定比 B 好」的推荐,换个数据规模、换个团队能力就不成立了。可复用的是这套方法,不是某个具体排名。务实的比法是:先用第③④②三个「硬约束」(私有化/信创、团队运维能力、必须支持混合检索)把不合格的直接筛掉,圈定 1-2 个候选;再用你真实的数据量和真实查询做一轮压测,别信厂商 demo 或社区跑分。一个常被忽略的务实结论:如果你的文书切片规模没到千万级、团队又不想多养一套分布式系统,pgvector 这类「和主数据库同库」的方案,往往比硬上 Milvus 更省心、更好维护。规模真上去了、并发压力大了,再迁到专业向量库不迟——检索层比底座好换得多。
四、真正要花心思的地方:混合检索与性能调优
选定了方案,检索层真正决定成败的两件事是混合检索怎么做和性能怎么调——这两件才是律师体感差异的来源。
混合检索:向量召回相似,关键词兜住精确,再融合排序
如第一节所说,法律检索必须同时要「语义相近」和「精确命中」。落地上,混合检索通常是:一路走向量检索召回语义相近的文书,一路走关键词/全文检索(BM25 那一类)召回法条号、案号、当事人、案由精确命中的文书,再把两路结果融合重排成最终列表。这里有两个要点:一是结构化过滤要前置——先按法院、审级、年份、案由把候选集缩小,再在小集合里做向量和关键词检索,又快又准;二是融合排序要能调,不同任务(类案检索 vs 精确查条文)向量和关键词的权重不一样。选检索引擎时,把「原生支持带过滤的向量检索 + 关键词检索 + 可调融合」当成硬指标,而不是事后自己拿两套系统硬拼。这也是为什么很多法律 RAG 最后是向量 + 关键词一起上,而不是纯向量。
性能:亿级文书查得慢,多半是工程调优不是选型
亿级法律文书检索慢,常见原因往往不是「向量库选错了」,而是几个容易忽略的工程点:
| 常见性能坑 | 怎么排/怎么调 |
|---|---|
| 索引参数没调 | 专业向量库有 HNSW、IVF 等多种索引,精度和速度要按数据量与查询量权衡;默认参数常非最优 |
| 没做结构化预过滤 | 先按法院/年份/案由缩小候选集再做向量检索,远快于全量暴力算——要求引擎支持带过滤的向量检索 |
| 缺融合排序 | 只靠单路召回,要么不全要么排序差,律师反复查;补上混合检索的融合重排 |
| 内存/资源不足 | 大向量索引常需常驻内存,不够就换入换出拖慢响应;按索引规模配够内存 |
排查顺序建议:先确认有没有做结构化预过滤、索引参数是否按规模调过,再看硬件与内存,最后才考虑是不是要换一套向量库。多数「查得慢」是调优问题,不是选型问题——别一遇到慢就急着推翻重选,先把手里这套调对。
五、检索引擎是容器,真正拉开差距的是里面的数据
最后泼一盆冷静的水:检索引擎选得再好、调得再快,它也只是把数据高效找出来的容器,决定类案检索到底好不好用的,是里面那套裁判文书数据本身。同一套 Milvus 或混合检索方案,接一套覆盖全、结构化(法院/审级/年份/案由/当事人字段齐全)、能回链原文、跟得上法规更新的裁判文书库,和接一套残缺、无结构、无法回链的数据,产出的可用性天差地别——因为结构化字段正是「按法院/年份/案由精确过滤」能不能做的前提,而这一步直接决定混合检索快不快、准不准。这也是我们反复强调的:法律 AI 的护城河在数据,不在检索组件。向量库大家都能装,数据底座的覆盖广度、结构化深度和可回链性,才是别人抄不走的那一层。选检索引擎时别只盯着「Milvus 还是 Qdrant」,更要同步想清楚:它索引的那套文书数据,够不够全、够不够结构化、能不能回链?
六、给信息化负责人的一页纸检索引擎选型自查清单
定检索方案、或评审供应商给的 RAG 检索架构前,把这份清单逐条过一遍:
- 不只向量:方案是不是混合检索(向量 + 关键词),而不是纯向量库?法条号、案号、当事人的精确匹配靠什么兜?
- 结构化过滤:能不能按法院 / 审级 / 年份 / 案由做精确过滤,并且过滤能前置到向量检索之前?
- 规模匹配:选的方案在你真实的文书切片规模(百万级?亿级?)和目标并发下,压测过吗?没到千万级是不是 pgvector 更省心?
- 私有化 / 信创:能完全离线部署、数据不出内网吗?有国产化要求的话,在目标国产芯片/系统上验证过吗?
- 切分与 embedding:文书切分策略定了吗?embedding 模型在中文法律语料上实测过吗?(这两步比选哪个向量库更决定准确度)
- 融合排序:向量和关键词结果的融合重排能不能按任务调权重?类案检索和精确查条文用不用同一套排序?
- 运维成本:这套方案多养的组件,团队运维扛得住吗?出问题查得到解法吗?
- 可回链:检索结果能不能回链到原文书、支撑律师核验和 AI 引证?(这是法律的硬要求)
- 数据底座:引擎索引的那套文书数据够不够全、够不够结构化、跟不跟得上法规更新?
把这九项做成选型前的固定动作,检索层这一步就从「跟风上个向量库」变成「按法律场景真实需求选出来、能长期用的检索底座」。记住:法律 AI 的检索,向量决定「找得像」,关键词决定「找得准」,数据决定「找得到、靠得住」——三者缺一不可,而选型只是把这三件事装进一个跑得动、维护得起的容器里。
七、常见问题
Q:法律 AI 的 RAG 用纯向量库够不够?
A:不够。法律检索既要「语义相近」(类案检索,靠向量)又要「一字不差精确命中」(法条号、案号、当事人、案由,靠关键词)。只上纯向量库,精确匹配会成片丢失,律师一发现给了准确案号却查不到,信任就崩。法律 RAG 几乎一定要做向量 + 关键词的混合检索。
Q:Milvus、Qdrant、pgvector、Elasticsearch 到底选哪个?
A:没有绝对最好,只有更适配你约束的。按五维度对着自己场景比:数据规模与性能、是否原生支持混合检索与结构化过滤、私有化与信创适配、运维复杂度与团队能力、生态与长期维护。先用「私有化/信创 + 团队运维能力 + 必须支持混合检索」筛掉不合格的,再用真实数据量压测。没到千万级、不想多养分布式系统,pgvector 常更省心。
Q:类案查得慢,是不是要换向量库?
A:多半不用。亿级文书查得慢常见原因是索引参数没按规模调、没做结构化预过滤、缺融合排序、内存不足,这些都是工程调优问题。排查顺序:先看结构化过滤和索引参数,再看硬件内存,最后才考虑换引擎。别一遇到慢就急着推翻重选。
检索引擎你来选,能被检索的好数据我们来供
文书查提供 1.5 亿+ 结构化裁判文书私有化部署——法院、审级、年份、案由、当事人字段齐全,天生适配混合检索的结构化过滤,支持回链原文。无论你的检索层用 Milvus、Qdrant、pgvector 还是 Elasticsearch,我们负责把那套覆盖全、结构化、能回链、可更新的法律数据喂进去,而且数据不出内网。检索引擎是容器,数据才是真正拉开类案检索差距的那一层。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情 · API/MCP 定价
相关阅读:类案检索:语义向量 vs 关键词 · 法律 AI 大模型底座选型 · RAG 还是微调?技术路线怎么选 · 律所 RAG 知识库搭建 · 律所内网大模型 GPU 选型 · 法律数据底座对比 · 律所 AI 私有化部署指南