AiCat 为什么需要 RAG、Embedding 与向量数据库

作者
Post Views: 67

大模型可以阅读代码、总结文档，也可以根据自然语言生成架构图。但当项目从几十个文件增长到几千个文件，或者资料从一份 PDF 增长到多个代码仓库和文档集合时，一个问题会越来越明显：我们不可能把所有内容都塞进一次模型请求。

这正是 RAG（Retrieval-Augmented Generation，检索增强生成）要解决的问题。

本文结合 AiCat 当前已有的知识图谱、课程化详解、项目问答和开发者图形能力，讨论三个问题：AiCat 现在是否已经使用了 RAG，引入 Embedding 与向量数据库能带来什么，以及应该如何在不推翻现有架构的前提下逐步升级。

RAG 到底是什么

一个最小的 RAG 流程可以概括为：

用户问题
  ↓
从外部知识中检索相关内容
  ↓
将检索结果放入模型上下文
  ↓
大模型根据问题和证据生成答案

它和“直接问大模型”的主要区别，是回答不再只依赖模型训练阶段记住的知识，而是依赖系统在请求发生时提供的真实材料。

因此，RAG 并不等于向量数据库。只要系统包含“检索、增强、生成”这三个阶段，就可以称为广义 RAG。向量数据库只是实现语义检索的一种重要方式。

AiCat 现在已经用到 RAG 了吗

答案是：已经具备广义 RAG，但还不是典型的向量 RAG。

开发者图形中的源码检索

在生成开发者图形时，AiCat 会先读取项目资源目录，让模型根据用户目标规划需要查看的文件；随后读取这些真实源码，把源码内容作为证据交给模型重建业务流程，并最终生成 D2、PlantUML 或 Mermaid 图形。

这条链路已经包含了：

  1. 从项目资源中选择相关文件；
  2. 读取被选中的源码；
  3. 将源码加入提示词上下文；
  4. 让模型生成分析结果和图形。

它属于基于目录规划和文件读取的源码 RAG。

知识点问答中的结构化检索

用户针对知识点提问时，AiCat 会读取当前节点、相邻节点、原文证据、已有课程详解以及历史问答，然后将这些信息组合成上下文交给模型。

这不是从向量库中查找相似文本，而是从知识图谱和业务数据库中精确读取相关结构，因此可以称为结构化 RAG 或 Graph RAG 的初级形态。

知识图谱生成中的分块抽取

当用户上传 PDF、Word、Markdown、文本或 Git 仓库时，AiCat 会将正文切成带重叠的文本块，分别抽取知识节点、关系和原文证据，然后进行跨分块合并和关系整理。

这一过程更接近 Map-Reduce 式大模型分析，而不是面向用户问题的检索。它解决的是“如何完整分析一份大材料”，而不是“如何从材料库中召回最相关内容”。

当前方案的边界

现有方案对于中小型项目是有效的，但随着资料规模增长，会逐渐暴露几个限制。

首先，文件规划依赖目录名、文件名和模型判断。如果真正相关的实现隐藏在命名不明显的工具类或基础模块中，就可能被漏掉。

其次，同一份大型资料可能被反复读取和分析。即使用户只问其中一个局部问题，系统仍可能处理大量无关内容，增加响应时间和 Token 消耗。

再次，关键词不同但语义相同的内容不容易被发现。例如用户搜索“防止重复提交”，实际代码可能使用的是“幂等键”“唯一约束”“事件去重”或“消息重投”等术语。

最后，当前系统没有统一的跨项目语义检索层，难以回答“哪些项目都实现了类似权限控制”这类跨仓库问题。

Embedding 和向量数据库分别做什么

Embedding 模型负责把文本、代码或知识节点转换成一组高维数字，也就是向量。语义相近的内容，其向量在空间中的距离通常也更接近。

向量数据库负责保存这些向量，并根据一个查询向量快速找出最相似的内容。

例如，用户提出：

用户登录后，权限菜单是如何生成的？

系统可以将问题转换成向量，然后从代码索引中召回登录接口、Token 解析、用户角色查询、权限计算、菜单树构建和前端动态路由等代码块。即使这些文件没有完全相同的关键词，只要语义相关，就有机会被检索出来。

引入向量 RAG 后能获得什么提升

支持更大的代码仓库和文档集合

资料入库时完成解析、切块和向量化，提问时只召回最相关的少量内容。模型不需要反复阅读整个项目，因此能够支持更大的仓库、更长的文档以及更多并行项目。

降低 Token 消耗和响应时间

假设一个仓库包含几十万行代码，但某个问题只涉及其中十几个函数。向量检索可以先将范围缩小，再将相关片段交给模型。上下文更小，调用成本和等待时间都会下降。

提高源码召回率

目录规划擅长发现命名清晰的文件，向量检索擅长发现“名字不同但职责相近”的实现。两者组合后，可以减少关键文件遗漏。

为回答和图形提供可追溯证据

每个向量块可以记录文件路径、页码、章节、类名、函数名、代码行号、Git commit 和内容哈希。模型生成答案或图形时，页面可以同时显示真实来源。

这会让用户知道一条调用关系为什么存在，也方便开发者定位模型分析错误。

实现跨文档和跨项目问答

建立统一索引后，用户可以搜索多个 PDF、多个 Git 仓库、历史知识图谱、已生成图形和历史问答。例如：

哪些项目使用了 JWT，它们的刷新机制有什么区别？

系统可以先按用户权限筛选项目，再从多个项目中召回证据并生成比较结果。

可以落地哪些新功能

1. 面向源码的智能问答

开发者可以直接提出：

  • 这个接口的数据从哪里来？
  • 修改用户角色会影响哪些模块？
  • 订单状态有哪些流转路径？
  • 某个异常可能在哪些文件中产生？
  • 哪些地方处理了文件上传安全校验？

回答不仅给出结论，还可以附带文件、符号和代码位置。

2. 证据驱动的图形生成

用户描述想查看的业务关系，系统先进行混合检索，再生成调用链图、时序图、数据流图、类图、ER 图、权限流程图或异常传播图。

相较于单纯让模型根据目录选择文件，向量检索能够为图中的节点和连线提供更完整的源码证据。

3. 知识图谱增量更新

通过文件哈希和向量索引识别新增、修改和删除的内容，只重新分析受影响的文本块和知识节点，而不是每次重建整张图谱。

这样可以保留未受影响的节点、人工布局、学习状态和课程详解。

4. 语义搜索

语义搜索不要求用户输入和源码完全一致的关键词。“重复提交”可以召回幂等、去重、唯一索引和消息重试；“用户身份失效”可以召回 Token 过期、刷新失败、Session 注销等实现。

5. 相似知识与重复内容检测

通过向量相似度，可以发现名称不同但含义相近的知识节点、重复章节、相似问题和重复生成的图形。这可以改善知识图谱合并质量，并减少重复的大模型调用。

6. 个性化学习推荐

结合知识图谱关系、内容向量和用户掌握状态，系统可以推荐下一知识点、关联材料、复习内容和针对性例题，也可以根据用户问题判断知识缺口。

7. Git 变更影响分析

系统可以将一次提交的代码变化，与历史代码、架构文档、知识节点和图形进行语义匹配，回答：

这次修改可能影响哪些接口、业务流程、文档和知识节点？

8. 个人或团队统一知识库

PDF、Word、Markdown、代码仓库、飞书文档、会议纪要、历史问答、知识图谱和开发者图形都可以进入统一检索层，再由网页或飞书机器人提供问答入口。

为什么不应该只使用向量检索

向量检索擅长语义相似，但不擅长所有问题。

查找一个明确函数名、错误码或配置键时，关键词检索通常更准确；分析调用路径和知识前置关系时，图谱遍历更合适；判断代码的真实依赖时，AST、语言服务器或静态分析结果比纯语义相似更可靠。

因此，AiCat 更适合采用混合 RAG：

用户问题
  ↓
关键词与符号检索
  +
向量语义检索
  +
知识图谱与代码关系检索
  ↓
权限过滤、合并、去重和重排序
  ↓
读取最相关的原文和源码
  ↓
大模型生成答案、课程或图形
  ↓
返回结论与可追溯证据

在 AiCat 中如何选择向量数据库

AiCat 当前已经使用 PostgreSQL，因此第一阶段可以优先考虑 PostgreSQL + pgvector。

这样做的好处是部署简单、事务和权限模型容易复用，也不需要立即维护一套独立的向量数据库。当向量规模、查询吞吐或多租户隔离需求显著增长后，再评估 Qdrant、Milvus 等专用方案。

建议每个索引块至少保存：

  • 用户与项目标识；
  • 资源和文件标识；
  • 原始文本；
  • Embedding 向量；
  • 文件路径和资源类型；
  • 页码、章节或代码符号；
  • 起止行号；
  • Git commit；
  • 内容哈希；
  • 权限范围和索引版本。

文档和代码需要不同的切块策略

文档可以根据标题、段落和页码切块，并设置适度重叠。代码则不应只按固定字符数切分，最好根据语言结构按类、函数、接口、配置块和模块切分。

代码块还应保存符号关系，例如：

  • 当前函数属于哪个类；
  • 调用了哪些函数；
  • 被哪些入口调用；
  • 使用了哪些数据库表；
  • 对应哪些路由和配置；
  • 关联哪些测试。

这些结构化信息可以与向量结果组合，提高调用链和架构图分析的准确率。

权限、安全与数据一致性

向量检索必须在召回阶段执行权限过滤，而不是先召回全部内容，再让模型忽略无权访问的数据。否则即使最终回答没有直接显示敏感内容，模型请求本身也可能已经接触了越权资料。

此外还需要处理：

  • 文件修改后删除旧向量；
  • 使用内容哈希避免重复向量化；
  • 记录 Embedding 模型和索引版本；
  • 项目删除后级联清理索引；
  • Git 分支或 commit 变化后的增量更新；
  • 记录一次回答实际使用的片段；
  • 限制模型只能引用真实召回的证据。

推荐的渐进式实施路线

第一阶段：开发者图形源码语义检索

先为代码资源建立按函数和类切分的向量索引。在现有目录规划之后增加向量召回，将两种结果合并。这个阶段最容易观察到相关文件召回率和图形准确率的变化。

第二阶段：知识点问答证据召回

为原文片段、知识节点和课程详解建立索引。用户提问时，同时检索当前节点邻居和全局相关原文，并在答案中显示引用。

第三阶段：混合检索与重排序

加入关键词检索、符号检索、向量检索和图谱检索，并通过规则或重排序模型筛选最终上下文。

第四阶段：跨项目知识库与增量更新

建立统一检索入口，支持多项目问答、相似实现比较、Git 变更影响分析和团队资料检索。

如何判断 RAG 是否真的变好了

不能只看回答是否“像是正确的”。建议建立可量化指标：

  • 正确证据是否进入 Top-K；
  • 召回文件和代码符号是否完整；
  • 回答引用是否真实；
  • 图形节点和连线是否有证据支持；
  • 不同项目之间是否发生越权召回；
  • 平均上下文长度和 Token 成本；
  • 首次响应和完整响应耗时；
  • 增量索引时间；
  • 用户追问后是否仍能维持正确上下文。

还应保存检索诊断信息，包括查询文本、过滤条件、候选片段、相似度、重排序结果和最终采用的证据。出现错误时，才能判断问题来自检索、上下文组织还是模型生成。

结语

AiCat 已经具备 RAG 的基础：它能够从项目资源中选择源码，能够从知识图谱中读取节点和证据，也能够将这些上下文交给大模型生成回答、课程和图形。

Embedding 与向量数据库的价值，不是给系统贴上一个新的技术标签，而是让它在资料规模增长后仍然能够快速找到真正相关的内容，并为每一个结论提供可追溯依据。

最合理的升级路线也不是推翻现有知识图谱和源码规划，而是在它们之间增加一层可靠的语义检索能力，最终形成关键词、向量、图谱和代码结构共同参与的混合 RAG。

当检索结果能够被验证、权限能够被约束、引用能够被追溯时，AiCat 才会从“可以调用大模型分析资料”进一步成长为一个真正理解个人和团队知识资产的智能工作平台。

发表评论