基础能力与元数据过滤
核心概念
定义：从外部知识源检索信息注入LLM，提升回答事实准确性
基础流程
文档预处理
分块向量化
向量库入库
相似度检索
提示词增强
大模型生成
元数据过滤
作用：缩小检索范围，精准限定知识库
Spring AI 实现
基于 QuestionAnswerAdvisor
参数名：`qa_filter_expression`
优化技术 —— 问题重写
核心目标
将自然语言提问转化为更适合检索的查询
解决模糊、缺失、上下文依赖等问题
四大主流策略
分解
原理：复杂多跳问题拆解为独立子问题
适用场景：多跳推理、多实体对比
示例：Kafka和RocketMQ的异同点
富化
原理：补充上下文、消除指代、补全限制条件
适用场景：指代消除、历史对话补充
多样化
原理：生成多个语义相近的查询变体
适用场景：文档表述风格不一
回溯提示
原理：从具体问题抽象出通用原理
适用场景：问题过于具体，难以直接匹配
组合策略实现
执行流程：回溯提示 → 问题分解 → 子问题多样化
代码封装：QuestionRewriteService
优化技术 —— 查询路由
核心思想
根据问题类型，智能分发到最合适的处理链路
提升检索精准度，避免全量检索
数据源路由
适用场景：多类型知识库并存
三类典型数据源
向量数据库：语义检索、非结构化文档
图数据库：关系查询、知识图谱
关系型数据库：结构化查询、精确匹配
实现逻辑：LLM意图识别 → 路由到对应数据库
Prompt 路由
适用场景：多业务场景、不同角色定位
原理：根据问题意图选择对应系统提示词
示例：医疗AI助手（医生/药师角色）
优化技术 —— 查询构造
核心能力：自然语言转SQL
定义：将自然语言查询自动转换为SQL语句
价值：降低非技术人员数据查询门槛
实现原理
输入：表结构DDL + 用户问题 + 当前日期
输出：符合语法的只读SQL查询语句
Prompt 设计要点
严格限定仅查询，禁止增删改
强制使用上下文中提供的表名和字段名
工程实现
封装 SqlQueryService
结合 JdbcTemplate 执行SQL并返回结果
优化技术 —— 问题澄清
核心价值
当问题模糊时，主动交互获取补充信息
避免因信息缺失导致回答不准确
适用场景
需求规划类：旅行规划、方案定制
多参数查询：需要时间、地点、预算等
实现方案
两阶段设计：信息收集阶段 + 规划生成阶段
对话原则：自然询问，避免审问感
优化技术 —— HyDE假设文档嵌入
核心思想
先让大模型生成假设答案，再用其检索真实文档
解决词汇不匹配、问题简短模糊
优势
弥补用户提问与知识库表述的词汇鸿沟
假设答案上下文更丰富，提升匹配精准度
优化技术 —— 混合检索
核心原理
并行双路召回：关键词检索 + 向量检索
结果融合排序：合并后统一排序
目标：兼顾召回率与精准度
融合算法
加权求和
公式：最终得分 = α × 向量得分 + (1−α) × 关键词得分
RRF倒数排名融合
公式：`RRF Score = Σ(1/(K + rank_i))`
特点：仅依赖排名、鲁棒性强
框架实现
LangChain / LlamaIndex
组件：EnsembleRetriever / QueryFusionRetriever
Spring AI 实现
方案：PGvector向量库 + Elasticsearch关键词库
优化技术 —— 重排序
核心价值
对粗召回的候选文档做二次精细排序
提升Top结果相关性，优化上下文窗口利用率
两类实现方案
RRF 算法重排序
定位：轻量级融合排序
优势：实现简单、性能开销极小
ReRank 模型重排序
定位：深度语义排序
原理：基于Cross-Encoder类专用模型
特点：排序精度高，有额外API调用开销
应用建议
两阶段架构：先粗召回，再精排
优先采用RRF，精度要求高再引入ReRank
优化技术 —— Graph RAG
核心思想
将非结构化文本转化为知识图谱
基于图结构做检索与推理
核心概念
知识图谱：以三元组形式存储的结构化知识库
图数据库：主流推荐 Neo4j
核心优势
多跳推理能力强
实体关系清晰，天然去重
全局视角，支持关联知识挖掘
实战实现
部署：Docker 部署 Neo4j
数据模型：节点与有向关系
典型查询：多跳路径查询
模块化 RAG —— Spring AI 实现
核心组件：RetrievalAugmentationAdvisor
定位：可插拔组件式架构
完整流程：查询转换 → 扩展 → 检索 → 合并 → 提示增强
可插拔组件详解
QueryTransformer查询预处理
压缩、改写、翻译
QueryExpander查询扩展
实现类：MultiQueryExpander
DocumentRetriever文档检索
核心实现：VectorStoreDocumentRetriever
DocumentJoiner文档合并
默认实现：ConcatenationDocumentJoiner
QueryAugmenter提示增强
默认实现：ContextualQueryAugmenter
模块化 RAG —— LangChain4j 实现
核心组件：DefaultRetrievalAugmentor
定位：模块化RAG核心，能力丰富
完整流程：查询转换 → 路由 → 检索 → 聚合 → 注入
核心组件详解
ContentRetriever内容检索
向量数据库检索
联网搜索检索
QueryTransformer查询转换
压缩与扩展
QueryRouter查询路由
固定路由
LLM智能路由
ContentAggregator内容聚合/重排序
基于RRF算法融合
基于专业打分模型重排序
工程简化工具
EmbeddingStoreIngestor：一键完成文档处理
AiServices 注解式开发
多模态 RAG
核心原理与流程
内容提取与定位
多模态识别：图片生成文本描述
内容排序整合
结构化输出
衔接标准RAG流程
多模态大模型调用
Spring AI 原生方式
Spring AI Alibaba 方式
PDF 多模态处理实现
基础工具：Apache PDFBox
自定义 UnifiedContentStripper
坐标系转换
图片标签设计
文档分块特殊处理
保证<image>标签完整性
图片块前后增加overlap
对象存储支撑MinIO
作用：存储图片，提供可访问URL
部署：Docker单机部署
工程实践与选型总结
文档处理能力对比
文档解析：LangChain4j支持格式更全
文档分块：两者均支持，LangChain4j更丰富
文档清洗：Spring AI 支持元数据增强
框架选型建议
Spring 生态企业项目：优先 Spring AI
复杂RAG需求、多组件扩展：优先 LangChain4j
优化落地原则
从简到繁：先实现基础RAG，再叠加优化
效果优先：每个优化点需验证收益
性能平衡：控制大模型调用次数
