一、为什么纯向量检索不够向量检索Dense Retrieval语义理解强但有盲区场景 1用户问“GMV 排名”。向量检索把“GMV”embedding 成一个向量去向量库找最近邻。但 embedding 模型可能没见过“GMV”这个缩写把它映射到一个模糊的语义空间召回的全是“销售额”、“营收”相关的表——而真正定义了GMV SUM(revenue)的 knowledge_entry 反而召回不到。场景 2用户问“bb_product 表的商品销量”。向量检索会把整句 embedding但“bb_product”是精确表名向量检索可能召回包含“product”的其他表。这两个场景的共性是——精确关键词比语义理解更重要。BM25 就是干这个的。二、BM25 是什么BM25Best Matching 25是信息检索领域的经典算法1994 年提出至今仍是搜索引擎的基础。公式长这样不用记公式理解三个核心概念就行词频TF词 q 在文档 D 里出现次数越多得分越高。逆文档频率IDF词 q 在所有文档里越罕见得分越高“的”这种常用词 IDF 低“GMV”这种术语 IDF 高。文档长度归一化长文档天然更容易包含查询词BM25 用 b 参数惩罚长文档。在 Lucene 里BM25 是默认打分算法。我们用 Lucene 9.12 实现 BM25 检索。三、中文分词SmartChineseAnalyzerLucene 默认的 StandardAnalyzer 对中文不友好——它把中文按字符切分“销售记录”切成“销”、“售”、“记”、“录”四个单字。这种分词让 BM25 失去意义因为单字语义太弱。我们换成SmartChineseAnalyzer!-- pom.xml -- dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analysis-smartcn/artifactId version9.12.0/version /dependencySmartChineseAnalyzer 是 Lucene 官方中文分词器基于 HMM隐马尔可夫模型做中文分词。“销售记录”会被切成“销售”、“记录”两个词BM25 打分才有意义。在 IndexManager 里配置踩过的坑最初用 StandardAnalyzerBM25 检索“商品销量”召回的全是不相关结果。换成 SmartChineseAnalyzer 后召回准确率从 45% 提到 82%。四、Lucene 索引数据源隔离每个数据源一个独立索引目录这样设计的好处是检索时只扫一个目录性能稳定。看 FullTextSearchService.search 的优化优化点从 filterExpression 解析出 dataSourceId直接定向检索对应目录。如果不解析得遍历所有数据源目录性能随数据源数量线性下降。五、查询注入防御不用 QueryParserLucene 提供了 QueryParser 解析用户输入但绝对不能用。看代码注释为什么不用 QueryParserQueryParser 支持丰富语法AND、OR、*、?、范围查询等如果用户输入 * 这种通配符查询会让 Lucene 扫描所有文档类似 SQL 注入。安全做法手动分词 TermQuery 组合。每个分词结果是一个 TermQuery用 BooleanClause.Occur.SHOULDOR组合。过滤条件用 Occur.FILTER不影响打分只过滤。规约提醒阿里手册“SQL 安全”要求“禁止字符串拼接 SQL”。Lucene 查询同理——禁止用 QueryParser 解析用户输入必须用 API 构建查询对象。六、NRT 近实时检索Lucene 写入后不是立即可见的需要 refresh 或 commit。两者的区别commit把内存段刷到磁盘fsync。持久化但慢。refresh打开新段让检索可见。不 fsync快。FullTextSearchService 支持 NRTNear Real-Time模式NRT 模式默认maybeRefresh()不 fsync写入后下一次检索可见。性能好但应用崩溃可能丢最近几秒的索引。Immediate 模式每次写入都commit()。持久化但慢生产不推荐。我们用 NRT 模式 定时 commit 兜底。即使崩溃丢几秒索引下次用户查询时会触发重建。七、向量检索pgvector向量检索用 pgvectorPostgreSQL 扩展Spring AI 的 VectorStore 抽象屏蔽了底层数据库差异。我们配的是 pgvector距离类型用余弦距离COSINE_DISTANCE。文本 embedding 通常用余弦相似度因为它对向量长度不敏感。维度 1024DashScope text-embedding-v2 模型的输出维度。如果换成 OpenAI text-embedding-3-small维度是 1536需要改这里。八、RRF 融合两路结果怎么合并BM25 和向量检索各返回 Top-K 结果怎么融合成一份排序用 RRFReciprocal Rank Fusion算法为什么用 RRF 不用加权融合加权融合需要把两路分数归一化但 BM25 分数和向量相似度的尺度完全不同——BM25 可以到几十向量相似度在 0-1 之间。归一化方法选择本身就是个坑。RRF 只看排名不看绝对分数天然规避了归一化问题。这就是 RRF 的妙处——简单、鲁棒、效果不差。九、混合检索的完整流程为什么检索 topK2融合前多检索一些给 RRF 留余量。如果只检索 topK 条融合后可能不够 topK (两路结果不重叠的部分会被合并)。实测数据 (Schema 检索)表格策略Top-5 召回率Top-10 召回率纯 BM2578%89%纯向量82%91%混合RRF91%96%十、踩过的坑坑 1: SmartChineseAnalyzer 加载慢首次使用 SmartChineseAnalyzer 时它会加载 HMM 模型约 20MB耗时 2-3 秒。如果在第一次检索时才初始化用户会感觉到明显延迟。解决方案在 IndexManager 启动时预热分词器做一次空查询。Spring 的 PostConstruct 注解很适合干这个。坑 2IndexWriter 并发写入冲突最初 IndexWriter 不是单例每次写入都 new 一个结果 Lucene 报 LockObtainFailedException。解决方案每个 dataSourceId 一个单例 IndexWriter用 ConcurrentHashMap 管理private final ConcurrentHashMap contexts new ConcurrentHashMap();阿里手册“并发处理”要求“线程资源必须通过线程池提供”——但 IndexWriter 不是线程是资源对象。单例 自带的锁机制就够。坑 3SearcherManager 释放遗漏IndexSearcher 用完必须释放否则内存泄漏。最初我用 try-with-resources但 SearcherManager.release() 不实现 AutoCloseable写起来别扭。最后封装了一个 releaseSearcher 方法学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】