单纯地扔给用户一个“黑盒”式的AI回答Yi经hen难满足挑剔的企业级需求了。想象一下当你向系统询问一份复杂的技术报告细节时AI若只是冷冰冰地吐出一段文字，却无法告诉你这结论源自何处，那种不信任感是不是瞬间就涌上心头？这正是RAG技术试图解决的核心痛点，而今天我们要聊的，不仅仅是RAG，geng是如何利用Spring AI框架，为你的智Neng问答系统装上“溯源”的眼睛，让每一个回答dou有据可查。

hen多开发者在ZuoRAG系统时往往只关注“怎么搜得准”，却忽略了“怎么找得着”。其实溯源Neng力的根基，完全取决于你把数据喂进向量库的那一刻。Ru果你在入库阶段没有把来源信息精心地“埋”进Document的元数据里那后续的检索就成了无源之水，根本无从谈起。

这里有个非常关键的设计决策：我们需要在元数据中预留几个“保留字段”。为了防止和用户自定义的业务字段打架，我们统一约定以下划线开头的三个字段：_sourceType_sourceTitle以及_sourceId。这种约定虽然简单，但在后续的数据流转中却Neng省去无数的麻烦。

来kankan具体的落地代码。在保存文本知识时我们不仅要保存实体本身，还要同步构建一个Document对象写入向量库：

@Override
@Transactional
public void saveNew {
    AiKnowledge entity = AiKnowledge.INSTANCE.toEntity;
    save;
    // 将知识库内容与元数据写入向量库
    Map metadata = JacksonUtils.toMap, String.class, Object.class);
    metadata.put;
    metadata.put);
    metadata.put);
    vectorStore.add(Collections.singletonList(
        new Document, entity.getContent, metadata)
    ));
}

这段代码的逻辑其实hen直白：先把业务数据落库，然后提取出关键信息塞进Map里Zui后连同文本内容一起丢给vectorStore。这里有个小细节，Document的ID我们采用了“类型_主键”的格式，这样Zuo的好处是全局唯一，以后万一要删除或者重建向量，通过ID就Neng精准定位，完全不用担心误伤友军。

当然文件上传的场景也是大同小异。只不过_sourceType变成了“file”，标题变成了文件名而Yi。这种统一的数据结构设计，让后续的检索逻辑变得异常清爽，不管是文本还是文件，在向量眼里dou只是带着不同标签的数据块罢了。

知识库从来dou不是一成不变的死水。业务文档在geng新，政策在调整，Ru果你的向量库还停留在旧版本，那AI给出的答案必然是过时的。所以我们必须处理好数据的geng新逻辑。

Zui稳妥的方案是“先删后写”。当用户修改知识条目时先根据ID把旧的向量数据删掉，geng新业务库后再重新跑一遍入库流程。虽然这听起来有点笨重，但在Embedding模型升级或者数据批量修复时这种“全量重建”的策略反而是Zui安全的。毕竟在数据准确性面前，那一点点性Neng损耗完全Ke以忽略不计。

当用户的问题从前端飞过来时后端的ChatServiceImpl就开始忙碌了。这可是整套系统的“大脑”，它要负责把用户的自然语言转化成向量，去海量的数据库里捞取Zui相关的碎片，然后再把这些碎片拼凑成一个有逻辑的Prompt喂给大模型。

这个过程Ke以拆解成几个清晰的步骤。我们得构建一个检索请求。这里不仅要考虑用户的问题，还要根据配置动态调整TopK和相似度阈值。Ru果后台配置了自定义的过滤表达式，比如只想搜某个特定部门的文档，也要在这里一并加上。

紧接着就是执行向量检索。Spring AI封装得hen好，我们只需要调用similaritySearch，剩下的余弦相似度计算全交给框架去搞定。拿到结果后千万别急着直接发给LLM，因为这里面可Neng存在重复或者高度相似的内容。我们需要Zuo一个简单的去重处理，把重复的文本过滤掉，同时收集好所有的来源信息。

这里有个专门的collectSource方法，它的任务就是从Document的元数据里把之前埋好的“雷”挖出来：

private void collectSource {
    Map meta = doc.getMetadata;
    String sourceType =  meta.get;
    String sourceTitle =  meta.get;
    Object sourceIdObj = meta.get;
    if  {
        return;
    }
    String uniqueKey = sourceType + "_" + sourceIdObj;
    if ) {
        ChatSourceDTO source = new ChatSourceDTO;
        source.setSourceType;
        source.setSourceTitle;
        source.setSourceId));
        source.setContent);
        sources.add;
    }
}

注意kan那个uniqueKey，我们用“类型+ID”作为去重的依据。这意味着，哪怕某段内容被检索到了好几次在Zui终的来源列表里它也只会出现一次。这种细节处理对于用户体验来说至关重要，谁也不想kan到一堆重复的链接刷屏。

Zui后一步，就是Prompt的组装了。我们通常会定义一个RAG模板，里面包含{context}和{query}两个占位符。把去重后的上下文片段拼在一起，替换掉{context}，再把用户的问题填进{query}，一个完美的Prompt就诞生了。这时候再调用大模型的流式接口，就Nengkan着它一点点吐出答案了。

大模型生成内容是流式的，而我们的来源检索是瞬间完成的。这就带来了一个有趣的技术挑战：怎么把这两者打包发给前端？Ru果等生成完了再发，那用户体验太差；Ru果分两个接口发，又增加了前端的复杂度。

答案就是SSE。我们在Controller层定义了一个ChatStreamResult，里面既有内容的流Flux，也有来源列表List。

在返回的时候，我们玩了个小花招。内容片段使用默认的SSE事件发送，而来源信息和关闭信号则使用命名事件。通过concatWithValues，我们保证了来源事件一定会排在所有内容片段之后。这样，无论大模型生成得有多慢，来源信息douYi经老老实实地在队列里排队等着了绝对不会丢。

@GetMapping
public Flux chatStream {
    ChatStreamResult result = chatService.chatStream;
    String sourcesJson = JacksonUtils.toJson);
    return result.getContentStream
            .map.data.build)
            .concatWithValues(
                ServerSentEvent.builder.event.data.build,
                ServerSentEvent.builder.event.data.build
            );
}

这种设计非常优雅。前端只需要监听同一个流，就Neng拿到所有数据。而且，内容生成和来源展示在逻辑上是完全解耦的，互不干扰。

后端把数据发出来了前端的戏码才刚刚开始。在Vue3的世界里我们用Pinia来管理状态，用TypeScript来保证类型安全。当SSE流源源不断地涌来时我们需要把这些碎片拼成完整的故事。

核心的逻辑封装在useCustomerService这个组合式函数里。当收到默认的onmessage事件时我们把它当作文本片段拼接到当前消息的content上；而当收到名为sources的事件时我们解析JSON，直接把来源数组挂载到消息对象上。

eventSource.addEventListener => {
    try {
        const sources = JSON.parse as ChatSource
        if  {
            customerServiceStore.updateMessage
        }
    } catch  {
        console.warn
    }
})

得益于Pinia的响应式特性，一旦sources字段被geng新，界面上的消息气泡就会立刻发生变化，那些来源标签就像变魔术一样弹了出来。这种即时反馈的感觉，真的非常丝滑。

我们的ChatMessage接口定义得hen清晰，sources是可选的，只有AI助手的回复才会有。而且我们还加了个status字段，从sending到streaming再到done，完整记录了一条消息的生命周期。这对于控制UI状态非常有帮助。

Zui后所有的数据dou要汇聚到MessageBubble.vue组件上。这个组件不仅要渲染Markdown格式的文本，还要负责画出那些精致的来源标签。

我们在消息内容的下方加了一个bubble-sources区域。这里会遍历message.sources数组，为每一个来源生成一个小标签。Ru果是文件类型的来源，就显示个文档图标；Ru果是知识库，就显示个笔记本图标。这种视觉上的区分，Neng让用户一眼就kan出答案的出处。

geng绝的是这些标签是Ke以点击的！我们在ChatSource接口里预留了content字段，里面存着原文内容。当用户点击标签时直接弹出一个Dialog把原文展示出来。用户不需要再去翻阅厚厚的文档，点击一下就Nengkan到AI引用的原始段落，这种体验简直不要太爽。

    参考来源：
    

        
            
                
                
            
            {{ source.sourceTitle }}
        
    

技术再牛，Ru果界面丑陋，用户也不会买账。我们在样式上也下了一番功夫。来源标签采用了轻量化的设计，背景色使用了Element Plus的CSS变量，这样就Neng自动适配明暗主题。在暗黑模式下标签的颜色会自动变淡，不会显得突兀。

当鼠标悬停在标签上时我们会触发一个过渡动画，边框颜色变为主题色，背景色也随之加深。这种微交互虽然不起眼，但却Neng给用户传递一种“这里Ke以点击”的心理暗示。

.source-tag {
    display: inline-flex;
    align-items: center;
    gap: 4px;
    padding: 2px 8px;
    border-radius: 4px;
    background: var;
    border: 1px solid var;
    font-size: 12px;
    transition: all .2s;
    &.clickable {
        cursor: pointer;
        &:hover {
            color: var;
            border-color: var;
            background: var;
        }
    }
}

你kan，连CSSdou写得这么有层次感。这就是为什么我们说Zuo产品不仅仅是写代码，geng是在雕琢体验。

回过头来kan，这套基于Spring AI的RAG方案，其实并没有用什么黑科技。它只是把向量检索、流式传输、响应式前端这些成熟的技术点，用一种非常巧妙的方式串联了起来。特别是那个“溯源”的设计，虽然增加了一些开发量，但换来的却是用户对系统的信任。

谁Neng解决“信任”问题，谁就Neng笑到Zui后。