RAG 与向量数据库集成：Spring Boot 中的检索增强生成架构实战

一、大模型的知识边界：为什么"参数化记忆"不够用

大模型的知识来源于训练数据，存在三个根本性限制：其一，训练数据有截止日期，模型无法回答训练之后发生的事件；其二，模型对专业领域知识（如企业内部文档、行业法规）的掌握深度不足；其三，模型可能产生"幻觉"——自信地编造不存在的事实。

检索增强生成（Retrieval-Augmented Generation, RAG）通过在推理时动态检索外部知识库，将相关文档注入 Prompt 上下文，弥补模型的知识盲区。但 RAG 的工程实现远不止"查向量数据库 + 拼接到 Prompt"这么简单——文档切分策略、Embedding 模型选型、检索精度优化、上下文窗口管理，每个环节都直接影响最终效果。

二、RAG 架构：从文档摄入到检索增强生成

完整的 RAG 系统包含两条链路：离线的文档摄入管线和在线的检索生成管线。

flowchart LR
    subgraph 离线摄入
        A[原始文档] --> B[文档解析<br/>PDF/Word/HTML]
        B --> C[文本切分<br/>Chunk Strategy]
        C --> D[Embedding 向量化]
        D --> E[写入向量数据库]
    end

    subgraph 在线检索
        F[用户查询] --> G[查询向量化]
        G --> H[向量相似度检索]
        H --> I[结果重排序<br/>Reranking]
        I --> J[上下文组装]
        J --> K[调用大模型生成]
        K --> L[返回增强响应]
    end

    E -.-> H

关键设计决策在于 Chunk 策略和检索策略的配合。Chunk 过大导致检索精度下降（无关信息稀释关键内容），Chunk 过小导致语义不完整（关键信息被切断）。检索策略需要平衡召回率和精度——召回太少可能遗漏关键文档，召回太多会超出上下文窗口。

三、生产级代码实现：文档摄入、向量检索与上下文组装

3.1 文档摄入管线

@Service
public class DocumentIngestionService {

    private final DocumentParser parser;
    private final ChunkStrategy chunkStrategy;
    private final EmbeddingModel embeddingModel;
    private final VectorStore vectorStore;

    @Async("ingestionExecutor")
    public CompletableFuture<Void> ingest(Resource document,
                                           Map<String, Object> metadata) {
        // 1. 解析文档为纯文本
        String text = parser.parse(document);

        // 2. 按语义边界切分
        List<TextChunk> chunks = chunkStrategy.split(text,
            new ChunkConfig(500, 50));  // 500 Token, 50 Token 重叠

        // 3. 向量化并存储
        List<Document> documents = chunks.stream()
            .map(chunk -> {
                float[] embedding = embeddingModel.embed(chunk.getText());
                Document doc = new Document(chunk.getText(), metadata);
                doc.setEmbedding(embedding);
                return doc;
            })
            .toList();

        vectorStore.add(documents);
        return CompletableFuture.completedFuture(null);
    }
}

3.2 语义切分策略

@Component
public class SemanticChunkStrategy implements ChunkStrategy {

    private final EmbeddingModel embeddingModel;

    @Override
    public List<TextChunk> split(String text, ChunkConfig config) {
        // 先按段落切分
        List<String> paragraphs = Arrays.asList(text.split("\n\n+"));

        List<TextChunk> chunks = new ArrayList<>();
        StringBuilder currentChunk = new StringBuilder();
        int currentTokens = 0;

        for (String para : paragraphs) {
            int paraTokens = estimateTokens(para);

            if (currentTokens + paraTokens > config.getMaxTokens()
                    && currentTokens > 0) {
                chunks.add(new TextChunk(currentChunk.toString().trim()));
                // 保留重叠部分，避免语义断裂
                String overlap = getOverlap(currentChunk.toString(),
                    config.getOverlapTokens());
                currentChunk = new StringBuilder(overlap);
                currentTokens = estimateTokens(overlap);
            }
            currentChunk.append(para).append("\n\n");
            currentTokens += paraTokens;
        }

        if (currentTokens > 0) {
            chunks.add(new TextChunk(currentChunk.toString().trim()));
        }
        return chunks;
    }
}

3.3 检索与上下文组装

@Service
public class RAGService {

    private final VectorStore vectorStore;
    private final EmbeddingModel embeddingModel;
    private final ChatClient chatClient;
    private final PromptTemplateService promptTemplateService;

    public String query(String userQuery, int topK) {
        // 1. 向量检索相关文档
        List<Document> relevantDocs = vectorStore.similaritySearch(
            SearchRequest.query(userQuery)
                .withTopK(topK)
                .withSimilarityThreshold(0.75)
        );

        // 2. 组装上下文
        String context = relevantDocs.stream()
            .map(Document::getContent)
            .collect(Collectors.joining("\n---\n"));

        // 3. 渲染 Prompt 模板
        Map<String, Object> variables = Map.of(
            "context", context,
            "question", userQuery
        );
        String prompt = promptTemplateService.render(
            "rag-qa-template", variables);

        // 4. 调用大模型
        return chatClient.call(prompt);
    }
}

四、RAG 架构的精度瓶颈与工程权衡

检索精度的不确定性：向量相似度检索基于 Embedding 空间的距离度量，但语义相似不等于问题相关。用户问"如何配置 SSL 证书"，检索可能返回"SSL 握手原理"的文档而非"SSL 证书配置步骤"。Reranking 模型（如 Cohere Rerank）可以提升精度，但增加了额外的推理延迟和成本。

上下文窗口的容量限制：检索到的文档加上用户查询和系统 Prompt，总长度可能超出模型上下文窗口。简单的截断策略可能丢失关键信息，需要根据文档与查询的相关性排序后，从高到低填充直到窗口上限。

Embedding 模型的领域适配：通用 Embedding 模型（如 text-embedding-3-small）在专业领域（如法律、医疗）的语义表达能力有限，可能导致检索精度下降。领域适配需要微调 Embedding 模型，但标注数据获取成本高，且微调后的模型可能丧失通用能力。

文档更新的实时性：向量数据库中的文档与源文档之间的同步存在延迟。当源文档更新后，需要重新摄入并替换旧的向量，这个过程的延迟取决于摄入管线的吞吐量。对于实时性要求高的场景（如新闻资讯），需要设计增量更新机制。

五、总结

RAG 的本质是将"参数化记忆"扩展为"参数化记忆 + 外部知识库"的混合架构，通过检索弥补模型的知识盲区。本文方案的核心链路为：文档解析 → 语义切分 → 向量化存储 → 检索重排序 → 上下文组装 → 模型生成。落地时需重点关注三个参数：Chunk 大小（建议 300-500 Token）、检索 topK 值（建议 3-5）、相似度阈值（建议 0.7-0.8）。建议从高质量的小规模知识库（如 FAQ 文档）开始验证，逐步扩展到大文档库，并在每个阶段评估检索准确率和生成质量。