Java后端面试知识库

外观

极高进阶

一句话答案 ​

RAG 流程：文档切分→Embedding→向量存储→用户查询检索→拼接上下文→LLM 生成，用外部知识增强模型回答。

核心要点

传统 RAG 的局限：

  • 基于文本相似度召回，不理解实体间的关系
  • 多跳推理能力弱（"A 的上司的部门负责人是谁" 这类问题召回不准）
  • 文档间的隐性关系（如因果、从属）无法利用

知识图谱 RAG（GraphRAG）：

  • 将文档中的实体（Entity）和关系（Relation）提取为知识图谱（三元组：主语-谓语-宾语）
  • 查询时：先识别问题中的实体 → 在图谱中搜索相关子图 → 将子图 + 原始文档一起作为上下文

优势：

  1. 多跳推理：图遍历天然支持多跳关系查询
  2. 精确关系理解：明确表示实体间关系，不依赖语义相似度
  3. 结构化知识聚合：可以从多个文档中聚合关于同一实体的信息
  4. 可解释性强：能展示推理路径

劣势：

  • 图谱构建成本高（实体和关系提取依赖 NLP / LLM）
  • 维护复杂，关系更新困难
  • 实现门槛高（Neo4j / TigerGraph）

实际建议： 一般项目用传统向量 RAG，数据有明显实体关系结构（如企业组织架构、医药知识）才考虑 GraphRAG。

追问与易错

追问方向：

  • 这个概念在你的项目中是怎么应用的？
  • 和相关技术/方案相比有什么优劣？
  • 如果出了问题你会怎么排查？

易错点：

  • ❌ 只知道概念不知道原理——面试官会追问底层实现
  • ❌ 缺乏实际使用经验——结合项目场景回答更有说服力

💡 记忆锚点

RAG像开卷考试：LLM本身是"闭卷"（只靠训练知识），RAG给它发参考资料（文档切分→Embedding→存向量库，查询时检索最相关的块拼进Prompt）。传统RAG靠语义相似度找资料，GraphRAG更进一步，把文档变成知识图谱（实体+关系），能做多跳推理（"A的老板的部门是什么"）。一般项目用向量RAG够了，有明确实体关系（组织架构/医药）才上GraphRAG。