Your Name
Backend Interview Prep

Backend Interview Prep


面试准备
backend interview

后端开发实习面试准备

本文档基于简历中的三个项目整理：

  • 基于 Bitcask 的 KV 存储引擎
  • 电商评价微服务系统
  • 基于知识图谱的医疗问答 RAG 系统

目标：模拟后端实习面试场景，围绕项目介绍、项目深挖、技术拓展、基础八股和面试准备策略进行问答准备。

0. 面试建议流程

后端实习常见节奏：

  1. 自我介绍 1-2 分钟。
  2. 挑一个项目深挖 20-30 分钟。
    • Bitcask KV：存储引擎、文件格式、恢复、索引、并发、merge。
    • 评价微服务：业务流程、状态机、事务、幂等、Kafka、ES 最终一致性。
    • 医疗 RAG：NER、知识图谱、Cypher 检索、RAG 幻觉、Agent/RAG 扩展。
  3. 基础八股 20-30 分钟。
    • Go 并发、GC、map、slice、channel。
    • MySQL 索引、事务、MVCC、慢查询。
    • Redis 缓存三问题、持久化、数据结构。
    • Kafka 顺序性、可靠性、重复消费。
    • TCP/HTTP/gRPC、操作系统。
  4. 算法题 1 道。
    • 高频：滑动窗口、双指针、二分、栈、堆、DFS/BFS、TopK、LRU。

1. 自我介绍模板

问题 1：请你先做一个自我介绍。

参考回答：

面试官您好，我叫左士海，目前是复旦大学电子信息专业研二，方向是大数据与数据科学，求职方向是后端开发实习。

我的项目主要有三个：

第一个是基于 Bitcask 模型实现的 Go 语言 KV 存储引擎，核心是追加写日志、内存索引、数据恢复、批量写原子性和 merge 空间回收。我在这个项目里主要关注存储引擎的数据结构、文件编码、索引设计和异常恢复。

第二个是电商评价微服务系统，基于 Kratos、gRPC、MySQL、Kafka、Canal 和 Elasticsearch，实现了评价创建、商家回复、申诉、运营审核、评价检索等流程。这个项目更偏业务后端，涉及服务拆分、状态流转、事务一致性、异步同步和最终一致性。

第三个是基于知识图谱的医疗问答 RAG 系统，用 Neo4j 构建医疗知识图谱，结合 BERT/RNN 做实体识别，通过大模型进行意图识别和答案生成。这个项目重点是降低大模型在医疗问答中的幻觉，让答案尽量基于知识图谱检索结果生成。

我比较熟悉 Go 后端、MySQL、Redis、Kafka、gRPC，也对 RAG、知识图谱和大模型应用有一定实践。希望能在实习中参与高并发后端、搜索推荐或者 AI 应用相关的工程实践。

2. 项目一：Bitcask KV 存储引擎

2.1 项目介绍类

Q1：你先介绍一下这个 Bitcask KV 项目。

参考回答：

这个项目是我用 Go 实现的一个嵌入式 KV 存储引擎，参考 Bitcask 存储模型。它的核心思想是写入时只做追加写，把每次 Put/Delete 编码成 LogRecord 顺序追加到数据文件中，同时在内存中维护一个 KeyDir 索引，记录每个 key 最新 value 在文件中的位置。读取时先查内存索引，再根据文件 id 和 offset 到磁盘读取对应记录。

功能上支持 Put、Get、Delete、批量写入 WriteBatch、迭代器遍历，也实现了 HTTP/Redis 协议访问。核心模块包括：

  • 数据文件和 LogRecord 编码；
  • 内存索引，支持 BTree、ART、B+Tree 等实现；
  • 启动时根据日志文件重建索引；
  • WriteBatch 通过事务序列号和事务完成标记保证原子性；
  • merge 机制回收旧版本和删除记录占用的磁盘空间。

这个项目的重点是理解 LSM/Bitcask 类存储引擎的写入路径、恢复路径和空间回收问题。

Q2：Bitcask 的核心设计是什么？为什么写入性能高？

参考回答：

Bitcask 的核心是追加写日志 + 内存索引。

写入时不在原地修改旧数据，而是把新的 key-value 记录追加到 active data file 的末尾。这样磁盘写入基本是顺序写，避免大量随机写，所以写入吞吐比较高。

内存中维护 KeyDir：

key -> {file_id, offset, size}

Get 时先从内存索引定位到最新记录的位置，然后到磁盘读取 value。因为索引在内存，所以点查也比较快。

缺点：

  1. 所有 key 的索引需要常驻内存，key 很多时内存压力大；
  2. 更新和删除都会留下旧记录，需要 merge 回收空间；
  3. 启动时需要扫描日志重建索引，如果没有 hint 文件会比较慢。

Q3：你的 LogRecord 是怎么设计的？

参考回答：

LogRecord 主要包含：

CRC32 | RecordType | KeySize | ValueSize | Key | Value

其中：

  • CRC32 用来校验记录是否完整；
  • RecordType 区分普通记录、删除记录、事务完成标记等；
  • KeySize 和 ValueSize 使用变长编码，减少元数据空间；
  • Key 和 Value 是实际数据。

读取时先解析 header，拿到 key 和 value 的长度，再读取完整数据，最后用 CRC 校验。如果 CRC 不匹配，说明记录可能是异常退出时写了一半，恢复时要停止或跳过，避免错误数据进入索引。

Q4：Put 的完整写入流程是什么？Get 时又是怎么通过 key 定位到磁盘记录的？

参考回答：

Put 的完整过程可以分成“写日志”和“更新内存索引”两步。

第一步，先校验 key，空 key 直接返回错误。然后把用户的 key/value 封装成一条 LogRecord，类型是 LogRecordNormal。项目里普通 Put 也会给 key 加一个非事务序列号，和 WriteBatch 的事务序列号机制保持统一。

第二步，调用追加写流程。追加写时会先确保当前有 active data file；如果还没有写过数据，就创建一个新的 active file。然后把 LogRecord 编码成磁盘格式：

CRC32 | RecordType | KeySize | ValueSize | Key | Value

编码完成后会得到本条记录的字节数组和大小。如果 activeFile.WriteOff + 当前记录大小 超过 DataFileSize，说明当前文件快满了，就先 Sync 当前 active file，把它放到 older files 里，再创建新的 active file。接着记录当前写偏移 writeOff，把编码后的记录顺序追加到 active file，写完后更新文件的 WriteOff。

第三步，根据持久化配置决定是否刷盘。如果开启了 SyncWrites，或者累计写入字节数超过 BytesPerSync，就对 active file 执行 Sync。所以这里可以区分：写入系统调用成功不等于一定已经落盘，是否立即落盘取决于 fsync 策略。

第四步，构造内存索引位置：

LogRecordPos{Fid: activeFile.FileId, Offset: writeOff, Size: recordSize}

然后用原始用户 key 更新内存索引：

key -> {file_id, offset, size}

如果这个 key 之前已经存在，旧位置就变成了无效旧版本，会把旧记录大小累计到 reclaimSize，后续 merge 可以根据这个空间浪费比例决定是否触发回收。

Get 时的定位过程正好反过来：

  1. 先校验 key；
  2. 到内存索引里查 key，拿到 LogRecordPos；
  3. 根据 Fid 判断记录在哪个文件：如果等于当前 active file 的文件 id，就读 active file，否则到 olderFiles 里找对应文件；
  4. 根据 Offset 从这个 data file 读取 LogRecord；
  5. 读取时先读 header，解析出 key size 和 value size，再读完整 key/value；
  6. 用 header 里的 CRC 和实际读出的内容重新计算校验，校验通过才返回；
  7. 如果记录类型是 deleted，返回 key not found，否则返回 value。

所以通过 key 定位磁盘记录的关键不是扫描磁盘，而是依赖内存 KeyDir。KeyDir 保存的是最新版本的位置，磁盘日志里可以有同一个 key 的多个历史版本，但只有内存索引指向的那条才是当前有效记录。

追问：为什么索引用原始 key，而 LogRecord 里存的是带 seqNo 的 key？

因为 seqNo 是为了恢复时区分普通写和事务批量写。对外查询时用户只关心原始 key，所以内存索引用原始 key；写入日志时加 seqNo，启动恢复扫描日志时再解析出真实 key，根据事务是否完成决定是否更新索引。

Q5：Delete 是怎么实现的？为什么不是直接删除文件里的数据？

参考回答：

Delete 不是原地删除，而是追加一条类型为 deleted 的 LogRecord，也叫 tombstone。

原因是 Bitcask 是追加写模型，如果直接去文件中删除或者修改旧记录，就会引入随机写和复杂的空间管理，破坏顺序写优势。

Delete 流程：

  1. 先判断 key 是否存在；
  2. 追加一条删除标记记录；
  3. 从内存索引中删除这个 key；
  4. 后续 merge 时，旧 value 和 tombstone 都可以被清理。

这样可以保证删除操作也是顺序写，恢复时扫描到 tombstone 后也能知道该 key 已经被删除。

2.2 数据恢复与一致性

Q6：数据库启动时怎么恢复索引？

参考回答：

启动时会按文件 id 从小到大扫描所有 data file，逐条解析 LogRecord。对于普通 Put 记录，就把 key 对应的位置更新到内存索引；对于 Delete 记录，就从索引中删除 key。

因为同一个 key 可能有多个版本，扫描顺序是日志写入顺序，所以后扫描到的一定是更新的版本，最终内存索引保留的是最新位置。

如果遇到 CRC 校验失败或者不完整记录，通常说明上次异常退出时写入未完成，这部分数据不能恢复进索引。

Q7：WriteBatch 怎么保证原子性？

参考回答：

WriteBatch 的目标是保证一批 Put/Delete 要么全部生效，要么异常恢复时全部不生效。

实现思路是给 batch 里的每条记录加同一个事务序列号 seqNo，写入时先追加所有数据记录，最后追加一条事务完成标记 txn-fin。

恢复时：

  1. 扫描日志；
  2. 如果看到带 seqNo 的事务记录，先暂存起来；
  3. 只有当扫描到对应的 txn-fin 标记，才把这批记录应用到索引；
  4. 如果异常退出导致只写了一部分，但没有 txn-fin，恢复时整批丢弃。

这样可以避免批量写中途崩溃导致部分 key 被错误恢复。

Q8：如果写入 LogRecord 后还没更新内存索引就宕机，会怎么样？

参考回答：

不会丢数据。因为真正持久化的是日志文件，内存索引只是加速访问的数据结构。重启后会重新扫描日志文件，把已经成功写入并通过 CRC 校验的 LogRecord 重新恢复到索引中。

但是如果日志只写了一半，CRC 校验不通过，则不会恢复这条记录。

如果要求更强的持久性，还需要考虑 fsync 策略：每次写都 fsync 最安全，但性能差；可以配置批量 fsync 或定时 fsync，在性能和可靠性之间取舍。

2.3 索引与迭代器

Q9：为什么要抽象 BTree、ART、B+Tree 多种索引？

参考回答：

因为 Bitcask 的磁盘数据组织和内存索引可以解耦。磁盘上只需要保存 LogRecord，内存索引只负责 key 到位置的映射。

抽象统一索引接口后，可以切换不同数据结构：

  • HashMap：点查快，但不支持有序遍历；
  • BTree：支持有序遍历、范围查询，实现相对简单；
  • ART：对字符串 key 和前缀查询比较友好，空间利用和查找性能较好；
  • B+Tree：更适合磁盘页式索引，不过作为内存索引也可以支持范围扫描。

项目里做统一接口的价值是让存储层不依赖具体索引实现，迭代器、Prefix Scan 等能力可以由有序索引提供。

Q10：Prefix 遍历怎么实现？如果用 HashMap 可以吗？

参考回答：

Prefix 遍历需要找出所有以某个前缀开头的 key。如果底层是有序索引，比如 BTree，可以从第一个大于等于 prefix 的 key 开始向后迭代，直到 key 不再满足前缀条件。

如果用 HashMap，也可以遍历所有 key 再过滤 prefix，但是复杂度是 O(N)，数据量大时效率差，而且无法自然支持有序输出。

所以如果业务需要 Prefix、范围扫描、正反向遍历，更适合用 BTree/ART 这类有序或前缀友好的索引。

2.4 Merge 与空间回收

Q11：为什么需要 merge？merge 怎么判断哪些记录是有效的？

参考回答：

追加写会导致同一个 key 的旧版本、被删除 key 的旧记录一直留在磁盘上，所以磁盘空间会不断增长，需要 merge 回收。

merge 的基本流程：

  1. 遍历旧的数据文件；
  2. 对每条记录，根据 key 查当前内存索引；
  3. 如果索引里记录的位置正好指向当前这条记录，说明它是 live record，需要复制到新的 merge 文件；
  4. 如果索引已经指向更新位置，说明这是旧版本，丢弃；
  5. 删除标记和过期旧记录也可以丢弃；
  6. merge 完成后替换旧文件，并写 hint 文件加速下次启动。

判断是否有效的关键是：当前索引是否仍然指向这条记录的位置。

Q12：merge 过程中如果还有新的写入怎么办？

参考回答：

通常做法是只 merge 某个时间点之前的不可变旧文件，不处理当前 active file。active file 继续接收新写入。

为了避免并发问题，merge 开始时可以记录当前 non-active data files 的范围，只对这些文件做合并。新的写入进入新的 active file，不影响 merge。

替换文件时要保证原子性，可以通过临时目录、merge 完成标记、rename 等方式实现。如果 merge 中途宕机，恢复时根据标记判断 merge 是否完成，未完成的临时文件可以删除，不影响原数据。

2.5 技术拓展与高危追问

Q13：Bitcask 和 LSM Tree 有什么区别？

参考回答：

Bitcask 和 LSM 都偏写优化，但结构不同。

Bitcask：

  • 数据追加写到日志文件；
  • 内存保存完整 key 到磁盘位置的索引；
  • Get 通常一次内存查询 + 一次磁盘读取；
  • 范围查询能力弱，依赖内存有序索引；
  • key 很多时内存压力大。

LSM Tree：

  • 写入先进入 MemTable 和 WAL；
  • MemTable flush 成 SSTable；
  • 后台 compaction 合并多层 SSTable；
  • 更适合大数据量和范围查询；
  • 读可能要查 MemTable、多层 SSTable 和 Bloom Filter。

一句话：Bitcask 更像 “log + 全量内存索引”，LSM 更像 “分层有序文件 + compaction”。

Q14：如果 key 特别多，Bitcask 的问题是什么？怎么优化？

参考回答：

最大问题是 KeyDir 全量常驻内存，key 数量特别大时内存占用高。

优化方向：

  1. 缩短 key 或对 key 做压缩；
  2. 索引中只保存必要元信息，例如 file id、offset、size；
  3. 使用更省内存的数据结构，例如 ART 或前缀压缩；
  4. 将部分索引落盘，变成类似 B+Tree/LSM 的结构，但这会牺牲 Bitcask 简洁性；
  5. 分片，把 key 分到多个实例，降低单实例内存压力。

Q15：如果面试官问“你这个项目有哪些不足”，怎么答？

参考回答：

这个项目主要用于学习和实现 Bitcask 核心机制，和生产级 KV 还有差距：

  1. 内存索引需要保存所有 key，数据量大时内存压力明显；
  2. merge 过程需要更完善地处理并发写、宕机恢复和文件原子替换；
  3. fsync 策略需要根据可靠性和性能做配置；
  4. 缺少完善的压测、监控和故障注入；
  5. Redis 协议兼容只是基础实现，和真正 Redis 在命令语义、网络模型、过期淘汰上有差距。

但核心的日志编码、索引恢复、批量写原子性和空间回收机制已经实现。

Q16：你这个 Bitcask 项目里每个数据文件的大小是多少？为什么要限制单个文件大小？

参考回答：

项目里的默认配置是每个 data file 最大 256MB，对应代码里的 DefaultOptions.DataFileSize = 256 * 1024 * 1024。在单元测试里为了更容易触发文件切换和 merge，也会把这个值调小，比如 32MB 或 64MB。

写入时会先把 LogRecord 编码，计算本次记录大小。如果当前活跃文件的写偏移 WriteOff + 本次记录大小 超过 DataFileSize，就会先对当前 active file 做 Sync，把它转成 older file，然后创建新的 active file 继续追加写。

限制单个文件大小主要有几个原因：

  1. 避免单个日志文件无限增长，便于文件管理和故障恢复；
  2. 启动扫描、merge、删除旧文件都可以按文件粒度处理；
  3. merge 时通常只处理 immutable 的 older files，不处理正在写的 active file，文件切分后并发边界更清晰；
  4. 如果文件太大，单次 merge 和启动恢复成本会变高；如果文件太小，文件数量会增加，文件描述符和元数据管理成本会上升。

所以这个大小不是固定标准，而是一个工程参数。我的项目默认取 256MB，是在文件数量、恢复成本和 merge 粒度之间做的折中。

追问：如果一个 value 本身超过了 DataFileSize 怎么办？

可以说明当前实现更偏学习型，没有专门做超大 value 分片。由于判断发生在写入前，如果单条记录大小超过阈值，会切到新 active file 后写入，这个新文件可能超过配置大小。生产实现里一般要限制单 value 大小，或者把大 value 拆分、外置存储，只在 KV 中保存引用。

3. 项目二：电商评价微服务系统

3.1 项目介绍类

Q1：请介绍一下电商评价微服务系统。

参考回答：

这个项目是一个电商评价业务系统，基于 Kratos 框架实现，主要拆成评价中台、商家端、运营端和异步同步任务几个模块。

核心业务包括：

  • 用户创建评价；
  • 商家回复评价；
  • 商家发起申诉；
  • 运营审核申诉；
  • 评价列表检索和过滤。

技术链路上，BFF 层通过 HTTP 对外提供接口，内部通过 gRPC 调用评价中台服务。核心数据存储在 MySQL，使用 GORM/GORM Gen 操作数据库。评价数据变化后，通过 Canal 监听 MySQL binlog，将变更事件写入 Kafka，再由异步 job 消费并写入 Elasticsearch，构建评价读模型，用于评价列表、评分筛选、时间排序和状态过滤。

项目重点是业务状态流转、多表事务、幂等控制、异步同步和最终一致性。

Q2：为什么拆成评价中台、商家端、运营端？

参考回答：

主要是按业务边界和使用方拆分。

  • 评价中台负责核心领域能力，比如评价、回复、申诉、状态流转，是业务事实的唯一写入口；
  • 商家端 BFF 面向商家后台，负责店铺归属校验、商家回复、商家申诉等；
  • 运营端 BFF 面向运营人员，负责审核申诉、状态管理；
  • review-job 负责异步同步，解耦搜索读模型构建。

这样做的好处：

  1. 核心业务规则集中在中台，避免多端重复实现；
  2. 不同端可以有不同接口和权限逻辑；
  3. 搜索同步异步化，不阻塞主链路；
  4. 服务边界更清晰，方便扩展。

Q3：微服务架构里服务发现和负载均衡怎么实现？你这个项目里 Consul 是怎么工作的？

参考回答：

微服务里服务实例的地址不是固定的，实例可能扩容、缩容、重启或迁移，所以不能让调用方写死 IP 和端口。服务发现的核心就是用注册中心维护“服务名 -> 可用实例列表”的映射，调用方按服务名找到实例，再通过负载均衡选择其中一个实例调用。

在我的评价系统里，评价中台服务名是 review.service。review 服务启动时通过 Kratos 的 Registrar 注册到 Consul；商家端 review-b 和运营端 review-o 作为调用方，通过 Kratos 的 Consul discovery 访问：

discovery:///review.service

整体链路是：

review 服务启动
 -> 向 Consul 注册 serviceName、instanceID、地址、端口、元数据和健康检查
 -> review-b / review-o 根据 review.service 向 Consul 查询可用实例
 -> gRPC client 拿到实例列表
 -> 客户端负载均衡选择一个实例发起 RPC

Consul 本身可以理解成注册中心 + 健康检查系统。服务提供者启动时把自己注册进去，Consul 保存服务实例信息；服务下线或健康检查失败后，Consul 会把这个实例标记为不可用，调用方后续就不应该再把流量打到这个实例上。

服务实例注册一般包含：

  1. 服务名，例如 review.service；
  2. 实例 ID，一般要全局唯一，可以用 hostname、IP、端口组合；
  3. 实例地址和端口，例如 gRPC 监听端口；
  4. metadata，例如版本、环境、权重；
  5. health check，用来判断实例是否健康。

保活和心跳机制有两类常见设计：

  1. 主动心跳：服务实例定期向注册中心续约，超过 TTL 没续约就认为实例失效；
  2. 被动探活：注册中心定期调用实例的 HTTP、TCP 或 gRPC health check，检查失败就摘除实例。

Consul 支持多种健康检查方式，比如 TTL check、HTTP check、TCP check、gRPC check。我的项目里使用 Kratos 的 Consul registry 组件，review 服务端构造 consul.New(client, consul.WithHealthCheck(true))，把服务注册和健康检查交给框架处理；review-b、review-o 通过 Consul discovery 获取服务实例。

负载均衡通常是在客户端做的。调用方从 Consul 拿到 review.service 的健康实例列表后，gRPC/Kratos 客户端根据负载均衡策略选择实例。常见策略有 round-robin、随机、权重、一致性哈希等。如果没有显式配置，就依赖框架默认策略；生产上我会显式配置并配合超时、重试、熔断，避免某个实例异常时拖垮调用方。

追问：服务实例异常退出怎么办？

如果是正常退出，框架应该主动向 Consul deregister，删除注册信息；如果是进程崩溃或机器宕机，主动注销来不及，就依赖健康检查或 TTL 超时。超过一定时间没有心跳，或者健康检查连续失败，Consul 会把实例标记为不健康，客户端发现列表更新后就不再调用它。

追问：服务发现和负载均衡分别解决什么问题？

服务发现解决“调用谁”的问题，也就是根据服务名找到可用实例；负载均衡解决“多个可用实例选哪一个”的问题。注册中心负责维护实例列表和健康状态，客户端或网关负责按策略分配请求。

3.2 业务流程与状态机

Q4：用户创建评价的完整流程是什么？

参考回答：

大致流程：

  1. 用户通过 HTTP 接口提交评价；
  2. BFF 做基础参数校验；
  3. 调用评价中台 gRPC；
  4. 中台校验订单、用户、商品、是否重复评价等业务规则；
  5. 写入 MySQL 评价表；
  6. 事务提交后，MySQL binlog 被 Canal 捕获；
  7. Canal 将变更事件发送到 Kafka；
  8. review-job 消费 Kafka，更新 Elasticsearch；
  9. 前台评价列表查询走 ES。

如果是强一致查询，可以直接查 MySQL；如果是列表检索和筛选，走 ES，接受短暂延迟。

Q5：评价状态和申诉状态怎么设计？

参考回答：

评价状态可以设计成：

  • 10：待审核或正常展示；
  • 20：已回复；
  • 30：申诉中；
  • 40：已隐藏或处理完成。

申诉状态可以设计成：

  • 10：待审核；
  • 20：申诉通过；
  • 30：申诉驳回。

重点不是具体数字，而是状态流转要受控。例如：

正常评价 -> 商家回复 -> 已回复
正常评价 -> 商家申诉 -> 申诉中
申诉中 -> 运营通过 -> 评价隐藏/处理完成
申诉中 -> 运营驳回 -> 恢复正常展示

实现时不能让任意状态互相跳转，应该在 service/biz 层限制合法状态迁移，避免脏状态。

Q6：怎么防止重复评价、重复回复、重复申诉？

参考回答：

分业务层和数据库层两层保证。

业务层：

  • 创建评价前按 order_id、user_id、sku_id 查询是否已有评价；
  • 回复前检查该评价是否已有 reply；
  • 申诉前检查是否已有未完成申诉。

数据库层：

  • 对评价可以建立唯一索引，例如 (order_id, user_id, sku_id)；
  • 对回复可以限制一个 review_id 只有一条有效回复；
  • 对申诉可以限制一个 review_id 同时只有一个 pending appeal。

只靠业务查询会有并发问题，比如两个请求同时查都不存在，然后都插入成功。所以关键约束应该放在数据库唯一索引上，业务层负责友好报错。

Q7：如果创建评价成功，但同步 ES 失败怎么办？

参考回答：

这是典型的最终一致性问题。MySQL 是主库，ES 是读模型，不能因为 ES 失败影响主链路提交。

解决思路：

  1. 用户创建评价时只保证 MySQL 写成功；
  2. 通过 Canal 监听 binlog，保证只要 MySQL 提交成功，就能捕获变更；
  3. Kafka 作为缓冲，review-job 消费后写 ES；
  4. 写 ES 失败时不能丢消息，需要重试；
  5. 多次失败可以进入死信队列或记录失败表，后续补偿；
  6. ES 文档 id 使用 review_id，保证重复消费时幂等 upsert。

这样系统是最终一致的，不是强一致。

3.3 事务、一致性、幂等

Q8：商家回复评价时涉及哪些一致性问题？

参考回答：

商家回复通常至少涉及：

  1. 校验评价存在；
  2. 校验店铺归属；
  3. 校验是否已经回复；
  4. 插入回复记录；
  5. 更新评价状态为已回复。

插入回复和更新评价状态应该在一个 MySQL 事务里完成，否则可能出现回复表有数据但评价状态没更新，或者状态更新了但回复不存在。

同时要处理重复请求：

  • 业务层判断是否已回复；
  • 数据库层对 review_id 建唯一约束；
  • 如果重复提交，返回幂等成功或明确的已回复错误。

Q9：Kafka 消费如何保证幂等？

参考回答：

Kafka 消费天然可能重复，所以消费者逻辑必须幂等。

在这个项目里，写 ES 可以用 review_id 作为 document id，消费到同一个评价变更时执行 upsert。重复消费同一条消息，只会覆盖同一个 ES 文档，不会产生重复数据。

如果是状态更新，还要考虑消息乱序。可以在消息里带 update_time 或 version，ES 写入时只接受版本更新的事件，避免旧消息覆盖新状态。

Q10：Canal + Kafka + ES 和业务代码直接写 ES 相比有什么区别？

参考回答：

业务代码直接写 ES 是双写：

写 MySQL -> 写 ES

问题是 MySQL 成功但 ES 失败时会不一致，需要复杂补偿。

Canal 方案是基于 binlog：

写 MySQL -> binlog -> Canal -> Kafka -> ES

优点：

  1. MySQL 是唯一事实来源；
  2. 只要事务提交，就一定有 binlog；
  3. ES 同步和主链路解耦；
  4. 失败可以通过 Kafka 重试和补偿。

缺点：

  1. 有同步延迟；
  2. 链路更长，运维复杂；
  3. 需要处理重复消费、乱序、消息堆积。

真实生产里通常更倾向 binlog CDC 或 outbox，而不是业务层裸双写。

Q11：如何保证 Kafka 消息不丢？

参考回答：

从 producer、broker、consumer 三层看。

Producer：

  • acks=all；
  • 开启重试；
  • 配合幂等 producer，避免重试产生重复。

Broker：

  • topic 多副本；
  • min.insync.replicas 合理配置；
  • leader 挂掉后从 ISR 里选新 leader。

Consumer：

  • 业务处理成功后再提交 offset；
  • 提交 offset 和业务处理之间要注意顺序；
  • 失败要重试或进入死信队列。

但 Kafka 通常做到 at-least-once 更常见，所以业务侧一定要幂等。

3.4 项目源码风险类追问

Q12：如果你代码里重复评价拦截被注释了，怎么办？

参考回答：

我会承认这是一个项目风险点。重复评价不能只依赖上层逻辑，应该恢复业务校验，并且在数据库层增加唯一索引，例如：

(order_id, user_id, sku_id)

原因是业务层查询在并发下不可靠。两个请求同时进来，都可能查不到已有评价，然后都插入成功。数据库唯一约束是最终防线。业务层捕获唯一键冲突后返回“已评价”即可。

Q13：如果运营审核参数在 data 层被 AI 审核逻辑覆盖，这有什么问题？

参考回答：

这属于职责边界和业务正确性问题。

运营审核是人工决策，data 层不应该覆盖上层传入的审核结果。data 层应该只负责持久化，不应该偷偷引入 AI 审核逻辑修改业务参数。

正确做法：

  • AI 审核作为一个独立策略或辅助建议；
  • biz/service 层决定最终审核结果；
  • data 层只保存明确传入的状态；
  • 保留审核来源，例如人工/AI/规则，方便追溯。

Q14：如果 ES 有直接写和 CDC 两条同步路径，会有什么问题？

参考回答：

会有双写不一致和乱序问题。

比如业务代码直接写 ES 成功，但 MySQL 事务后来回滚；或者 MySQL 更新后 CDC 又写入旧版本，覆盖直接写结果。两条路径同时存在会让 ES 数据来源不唯一，问题难排查。

我会统一成一种链路。更推荐 MySQL 作为唯一事实来源，ES 只通过 CDC/Kafka 异步构建。如果确实需要直接写，也要加版本号、幂等和补偿机制，但复杂度更高。

Q15：如果缓存 key 缺少 store/user 维度，会有什么风险？

参考回答：

会发生 key 碰撞或越权读取。

比如只用 review_id 做缓存 key，而不同店铺或用户上下文下权限不同，那么一个用户可能读到另一个店铺的数据。缓存 key 应该包含业务隔离维度，例如：

review:{store_id}:{review_id}
user_review:{user_id}:{order_id}:{sku_id}

同时还要设置合理 TTL，并在数据变更后删除或更新缓存。

4. 项目三：医疗知识图谱 RAG 系统

4.1 项目介绍类

Q1：请介绍一下医疗 RAG 项目。

参考回答：

这个项目是一个基于知识图谱的医疗问答系统，目标是降低大模型在医疗领域直接回答时的幻觉问题。

系统主要分四步：

  1. 用 Neo4j 构建医疗知识图谱，包含疾病、药品、症状、检查项目等实体，以及治疗、并发症、宜忌食物等关系；
  2. 对用户问题做命名实体识别，模型是基于 BERT/RoBERTa 表征加 RNN 类序列标注头，并结合规则 AC 自动机补充识别；
  3. 用 Prompt 让大模型做多意图识别，例如疾病简介、症状、病因、治疗、用药、检查、并发症等；
  4. 根据识别出的实体和意图生成 Cypher 查询 Neo4j，把检索结果作为上下文交给大模型，让模型基于检索内容生成回答。

这个系统本质上是 GraphRAG：检索来源主要是知识图谱，而不是单纯向量数据库。

Q2：为什么要用知识图谱做医疗问答，而不是直接让大模型回答？

参考回答：

医疗场景对可靠性要求高，大模型直接回答容易出现幻觉，尤其是编造药品、剂量、禁忌或者治疗建议。

知识图谱的价值：

  1. 实体和关系结构化，来源更可控；
  2. 可以通过 Cypher 精确检索疾病、症状、药品、治疗等关系；
  3. 回答时把检索结果作为上下文，限制大模型只基于已知信息回答；
  4. 对“某疾病有什么症状”“某药治疗什么病”这种关系型问题，图谱比纯向量检索更精确。

缺点是覆盖率受图谱限制，图谱没有的信息回答不了，需要明确提示“根据已知信息无法回答”。

Q3：这个医疗 RAG 项目的知识图谱是怎么构建的？包含哪些实体和关系？

参考回答：

知识图谱是基于 DiseaseKG / Open-KG 医疗数据集构建的，项目里主要使用 data/medical_new_2.json 作为源数据，然后通过 build_up_graph.py 解析数据并写入 Neo4j。

构建流程可以分成四步：

  1. 先启动 Neo4j，并通过 py2neo.Graph 连接图数据库；
  2. 逐行读取 medical_new_2.json，每一行基本对应一个疾病及其相关字段；
  3. 从疾病字段中抽取实体、属性和关系，先在内存里做去重，再把实体保存到 data/ent_aug/，把关系保存到 data/rel_aug.txt；
  4. 最后把实体节点和关系边批量导入 Neo4j。

实体主要有 8 类：

  1. 疾病，例如急性肺脓肿；
  2. 药品，例如布林佐胺滴眼液；
  3. 食物，例如芝麻；
  4. 检查项目，例如胸部 CT 检查；
  5. 科目，例如内科、呼吸内科；
  6. 疾病症状，例如乏力、呼吸困难；
  7. 治疗方法，例如抗生素药物治疗；
  8. 药品商/在售药品，用来表示某个厂商或商品药品信息。

其中疾病节点的信息最丰富，除了名称，还会保存疾病简介、疾病病因、预防措施、治疗周期、治愈概率、疾病易感人群等属性。其他实体基本只保存名称。

关系上，面试时可以重点讲疾病相关的 8 类关系：

  1. 疾病使用药品：疾病 -> 药品；
  2. 治疗的方法：疾病 -> 治疗方法；
  3. 疾病宜吃食物：疾病 -> 食物；
  4. 疾病忌吃食物：疾病 -> 食物；
  5. 疾病的症状：疾病 -> 疾病症状；
  6. 疾病所需检查：疾病 -> 检查项目；
  7. 疾病所属科目：疾病 -> 科目；
  8. 疾病并发疾病：疾病 -> 疾病。

另外源码里还会从 drug_detail 字段解析出“药品商/厂商 生产 药品”的关系。README 中原始数据集层面还有常用药、推荐药、推荐食谱等更细的关系，但在项目实现里会把一部分关系合并成更适合问答检索的中文关系，比如把常用药和推荐药统一到“疾病使用药品”，把宜吃和推荐食谱合并到“疾病宜吃食物”。

这样设计的原因是，问答阶段不需要暴露原始数据字段，而是需要围绕用户意图快速查到疾病的属性或相关实体。例如用户问“急性阑尾炎该怎么治疗”，系统可以先识别出“急性阑尾炎”这个疾病实体，再根据意图查询“疾病简介”“治疗的方法”“疾病使用药品”等属性和关系，把 Neo4j 检索结果作为上下文交给大模型生成回答。

追问：为什么不用纯文本直接喂给大模型，而要拆成实体和关系？

因为医疗问答里很多问题本质是结构化关系查询，比如“某病有什么症状”“需要做什么检查”“能吃什么、不能吃什么”。拆成实体和关系后，Cypher 可以精确检索，减少大模型编造；同时也便于做实体对齐、意图到关系的映射和结果溯源。缺点是覆盖率依赖图谱，图谱里没有的疾病或关系不能强行回答。

4.2 NER 与实体对齐

Q4：NER 模型怎么做的？

参考回答：

NER 主要是序列标注任务。输入用户问题，先通过预训练语言模型得到 token 表征，再接 RNN 类序列建模层和分类层，预测每个 token 的标签，比如 B-Disease、I-Disease、B-Drug 等。

项目里还结合了数据增强，包括：

  • 实体替换：把同类实体替换成其他疾病/药品；
  • mask：增强模型对上下文的鲁棒性；
  • 拼接：构造更复杂的问题样本。

此外还用了 AC 自动机做规则匹配，补充识别图谱中已有实体，避免模型漏召回。

Q5：实体识别模型的具体结构是什么？BERT 和 Transformer 架构分别是什么样的？

参考回答：

我这个项目里的实体识别是一个典型的序列标注模型，输入是一句话，输出是每个 token 对应的 BIO 标签，比如 B-疾病、I-疾病、B-药品、O 等。

具体模型结构是：

文本
 -> tokenizer 编码，加 [CLS] / [SEP] / padding
 -> BERT/RoBERTa 编码
 -> 双向 RNN 序列建模层
 -> Linear 分类层
 -> 每个 token 的实体标签

代码里用的是 BertModel.from_pretrained(model/chinese-roberta-wwm-ext)，也就是 HuggingFace 的 BERT 类接口加载中文 RoBERTa-wwm-ext。BERT 输出每个 token 的上下文向量，维度是 768。然后接了一个 2 层的双向 nn.RNN，hidden_size=128，如果是双向，拼接后每个 token 的输出维度就是 256。最后用 Linear(hidden_size * 2, tag_num) 映射到标签数，训练时用 CrossEntropyLoss(ignore_index=0)，忽略 padding 标签。

这里要注意一个诚实点：代码中实际是 nn.RNN，不是严格的 LSTM；README 示例里出现过 LSTM 写法，但当前训练代码是 RoBERTa/BERT + 双向 RNN + Linear。

BERT 本身可以理解成只使用 Transformer Encoder 的预训练语言模型。它的输入表示由三部分相加：

Token Embedding + Segment Embedding + Position Embedding

然后经过多层 Transformer Encoder。每层 Encoder 主要包括：

  1. Multi-Head Self-Attention：让每个 token 关注句子里的其他 token；
  2. Add & LayerNorm：残差连接和归一化，保证训练稳定；
  3. Feed Forward Network：对每个 token 的表示做非线性变换；
  4. 再做一次 Add & LayerNorm。

Transformer 的核心是 Self-Attention。每个 token 会映射成 Q、K、V：

Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V

Q 和 K 计算 token 之间的相关性，softmax 后得到注意力权重，再对 V 做加权求和。Multi-Head Attention 就是把这个过程做多组，让不同 head 学不同关系，比如局部搭配、长距离依赖、实体上下文等。

相比 RNN，Transformer 的优势是：

  1. 更容易并行，因为不需要按时间步递归计算；
  2. Self-Attention 可以直接建模长距离依赖；
  3. 预训练后可以迁移到 NER、分类、问答等下游任务。

在 NER 里，BERT/RoBERTa 负责提供强上下文语义表示，后面的 RNN 和分类层负责进一步适配序列标注任务。最后项目还会把模型识别结果和 AC 自动机规则结果做合并，再用 TF-IDF 实体对齐到知识图谱标准实体。

追问：为什么 BERT 后面还要接 RNN，直接 Linear 不行吗？

直接 BERT + Linear 也可以做 NER，而且是很常见的 baseline。这里接 RNN 是希望在 BERT 表示之上再建模标签附近的顺序信息，尤其是医学实体通常是连续片段。不过它不是必须的，生产上还可以考虑 BERT + CRF，让标签转移更符合 BIO 约束，比如 I-疾病 不应该随便接在 B-药品 后面。

Q6：LSTM 模型是什么？相比普通 RNN 解决了什么问题？

参考回答：

LSTM 全称是 Long Short-Term Memory，长短期记忆网络，本质上是 RNN 的一种改进结构。普通 RNN 按时间步递归处理序列，当前隐藏状态依赖当前输入和上一个隐藏状态：

h_t = f(Wx_t + Uh_{t-1})

它的问题是序列很长时容易梯度消失或梯度爆炸，导致模型很难记住较远位置的信息。LSTM 的核心改进是引入了细胞状态 C_t 和门控机制，用门来控制哪些信息保留、哪些信息遗忘、哪些信息输出。

LSTM 主要有三个门：

  1. 遗忘门 forget gate：决定上一时刻细胞状态里哪些信息要丢弃；
  2. 输入门 input gate：决定当前输入中哪些新信息要写入细胞状态；
  3. 输出门 output gate：决定当前细胞状态中哪些信息要输出成隐藏状态。

可以用简化公式理解：

f_t = sigmoid(W_f [h_{t-1}, x_t])      # 遗忘门
i_t = sigmoid(W_i [h_{t-1}, x_t])      # 输入门
ĉ_t = tanh(W_c [h_{t-1}, x_t])         # 候选记忆
C_t = f_t * C_{t-1} + i_t * ĉ_t        # 更新细胞状态
o_t = sigmoid(W_o [h_{t-1}, x_t])      # 输出门
h_t = o_t * tanh(C_t)                  # 当前隐藏状态

直观理解：C_t 像一条长期记忆通道，遗忘门决定旧记忆保留多少，输入门决定新信息写入多少，输出门决定当前要暴露多少信息给后续网络。这样梯度可以沿着细胞状态更稳定地传播，所以比普通 RNN 更能处理长距离依赖。

在 NER 这种序列标注任务里，LSTM 可以建模实体前后的上下文。例如“肺脓肿”这几个字是否是疾病实体，不只看单个字，还要看前后词。双向 LSTM 会同时从左到右和从右到左建模上下文，对每个 token 得到更完整的上下文表示。

但结合我的项目要诚实说明：当前代码实际使用的是 nn.RNN，不是严格 LSTM；README 示例里有 LSTM 写法。面试时可以说：如果换成 LSTM，结构上就是把当前的双向 RNN 层替换为双向 LSTM，目标是增强长距离依赖建模和缓解梯度消失。

追问：LSTM 和 Transformer 有什么区别？

LSTM 仍然是递归结构，必须按序列时间步计算，不容易并行；Transformer 用 Self-Attention 直接计算 token 两两关系，更容易并行，也更适合大规模预训练。LSTM 对中小规模序列任务仍然有效，但现在 NLP 里通常会优先用 BERT/Transformer 提供上下文表示。

Q7：简历写 BERT+LSTM，但代码里如果是 nn.RNN，面试官问怎么办？

参考回答：

要诚实回答。

可以说：

简历里写的是 BERT+LSTM，准确地说，我的实现是预训练语言模型加 RNN 类序列建模头，代码中使用的是 nn.RNN，不是严格的 LSTM。两者的共同点是都用于建模序列上下文，但 LSTM 通过门控机制缓解长距离依赖和梯度消失，表达能力更强。这里简历表述不够精确，我应该改成 BERT/RoBERTa + RNN 序列标注模型。

这样回答比硬拗更好。

Q8：实体识别后的实体对齐是怎么做的？为什么要做 TF-IDF 对齐？

参考回答：

实体识别只解决“用户问题里提到了什么实体片段”，但这个片段不一定等于知识图谱里的标准节点名称。所以实体识别之后还要做实体对齐，也叫实体标准化或实体链接。

比如用户说“感冒”，NER 可能识别出 mention 是“感冒”，但图谱里的标准疾病节点可能是“普通感冒”“上呼吸道感染”或者其他更规范的名称。如果不对齐，后面生成 Cypher 时可能查不到节点。

项目里的对齐方式是按实体类型分别做字符级 TF-IDF 相似度匹配：

  1. 启动时读取 data/ent_aug/ 下的实体词表，比如疾病、药品、检查项目、科目、症状等；
  2. 对每一种实体类型单独建立一个 TfidfVectorizer(analyzer="char")；
  3. 把该类型下所有标准实体名称转成 TF-IDF 向量，并缓存起来；
  4. NER 和 AC 自动机识别出实体后，会得到 (start, end, type, mention)；
  5. 根据实体类型 type，只在同类型候选实体里检索，不会拿疾病去和药品比；
  6. 把 mention 也转成字符级 TF-IDF 向量；
  7. 用余弦相似度和该类型所有标准实体计算相似度；
  8. 取相似度最高的候选实体，如果分数大于阈值，比如代码里是 0.5，就认为对齐成功；否则不强行对齐。

代码逻辑可以概括为：

mention + 实体类型
 -> 选择该类型的标准实体词表
 -> 字符级 TF-IDF 向量化
 -> cosine_similarity
 -> 取 top1
 -> 分数 >= 0.5 才返回标准实体

最后返回的是类似这样的结构：

{"疾病": "普通感冒", "药品": "布林佐胺滴眼液"}

这里用字符级 TF-IDF 的原因是中文医学实体经常有共享字词，字符 n-gram 或字符级特征能处理一部分简称、别名和轻微差异，而且实现简单、可解释、速度快。

局限也很明显：

  1. 它主要看字面相似度，不理解医学语义；
  2. 对完全不同说法的别名效果不好；
  3. 阈值 0.5 是经验值，过低会误对齐，过高会漏召回；
  4. 当前实现每个类型只保留一个最高匹配结果，如果一句话里出现多个同类型实体，可能会被覆盖。

如果工程化优化，我会增加同义词词典和别名表，保留 top-k 候选并结合上下文重排；更进一步可以用向量召回或领域实体链接模型，但要注意医疗场景宁可拒答，也不要把实体错误对齐后生成错误建议。

Q9：TF-IDF 的原理是什么？为什么它能用来做实体相似度匹配？

参考回答：

TF-IDF 是一种传统的信息检索权重方法，用来衡量一个词或字符对某个文档的重要程度。它由两部分组成：TF 和 IDF。

TF 是 Term Frequency，表示词在当前文档中出现得有多频繁。一个词在当前文档里出现越多，通常越能代表这个文档。

IDF 是 Inverse Document Frequency，表示词在整个语料中有多稀有。如果一个词在很多文档里都出现，比如“疾病”“治疗”这种通用词，它区分度就低，IDF 就低；如果一个词只在少数文档里出现，它更有区分度，IDF 就高。

常见公式可以这样理解：

TF-IDF(t, d) = TF(t, d) * IDF(t)
IDF(t) = log(N / (DF(t) + 1))

其中 N 是文档总数，DF(t) 是包含词 t 的文档数量。实际工程实现里一般会加平滑，避免除零。

在我的项目里，一个“文档”可以理解成一个标准实体名称，比如“普通感冒”“急性肺脓肿”“布林佐胺滴眼液”。因为中文医学实体比较短，如果按词分词不稳定，所以用了字符级 TF-IDF，也就是把单个汉字或字符作为特征。

举个例子，用户输入 mention 是“肺脓肿”，候选实体有“急性肺脓肿”和“肺炎”。字符级 TF-IDF 会发现“肺、脓、肿”这些字符和“急性肺脓肿”重合更多，而“脓、肿”又不是所有疾病名都会出现，所以相似度更高。

得到 TF-IDF 向量后，再用余弦相似度比较 mention 和候选实体：

cosine_similarity(A, B) = A·B / (||A|| * ||B||)

它衡量两个向量方向是否接近。方向越接近，说明两者包含的关键字符越相似。项目里就是对同一实体类型下的所有标准实体算余弦相似度，取分数最高的实体；如果最高分超过阈值，比如 0.5，就认为对齐成功。

TF-IDF 的优点是实现简单、速度快、可解释，不需要训练模型，适合实体词表规模不是特别大、且实体名称字面相似度比较有价值的场景。

缺点也很明显：

  1. 它只看字面重合，不理解语义；
  2. 对“感冒”和“上呼吸道感染”这种低字面重合的同义表达效果不好；
  3. 对错别字、简称、别名依赖词表和阈值；
  4. 如果候选实体非常多，暴力计算相似度也需要做索引或召回优化。

所以面试里可以说：TF-IDF 在这个项目里是一个轻量、可解释的实体标准化方案，适合做 baseline；如果要生产化，可以结合别名词典、向量召回、BM25 或实体链接模型做增强。

Q10：AC 自动机为什么适合做实体规则匹配？

参考回答：

AC 自动机适合多模式串匹配。医疗图谱里有大量疾病、药品、症状名称，如果逐个字符串匹配，复杂度很高。

AC 自动机先把所有实体词构建成 Trie，并通过 fail 指针支持多模式匹配。对用户问题扫描一遍，就能找出出现过的图谱实体，时间复杂度近似 O(文本长度 + 匹配结果数)。

它适合提升召回，但缺点是：

  1. 对别名、错别字、简称不够鲁棒；
  2. 可能误匹配短词；
  3. 需要配合模型和实体链接做消歧。

4.3 意图识别与 GraphRAG

Q11：意图识别怎么做？为什么用 Prompt 而不是训练分类器？

参考回答：

项目中用大模型 Prompt 做多意图识别，让模型从预定义的医疗意图里选择，例如疾病简介、症状、病因、治疗、用药、检查、并发症等。

选择 Prompt 的原因：

  1. 医疗意图类别比较明确；
  2. 标注成本高，用 Prompt 可以减少人工标注；
  3. 多意图问题比较常见，比如“糖尿病有什么症状，吃什么药”，Prompt 更灵活；
  4. 迭代快，新增意图只需要调整 Prompt 和解析逻辑。

缺点是输出格式不稳定，所以最好要求模型输出 JSON，并做 schema 校验，而不是只靠字符串包含判断。

Q12：GraphRAG 的流程是什么？

参考回答：

流程：

用户问题
 -> NER 识别实体
 -> 实体对齐到图谱节点
 -> LLM/Prompt 识别意图
 -> 根据实体 + 意图生成 Cypher
 -> Neo4j 检索相关三元组/属性
 -> 构造上下文 prompt
 -> LLM 基于上下文生成回答

关键点是最后的生成 Prompt 要约束模型：只能基于检索到的 <提示> 回答，如果提示中没有相关信息，就回答“根据已知信息无法回答该问题”。

Q13：如何减少 RAG 幻觉？

参考回答：

主要从检索和生成两侧控制。

检索侧：

  1. 提高 NER 和实体链接准确率；
  2. 检索结果要包含来源实体、关系和属性；
  3. 对多意图分别检索，避免漏召回；
  4. 对低置信度实体不强行回答。

生成侧：

  1. Prompt 明确要求只基于上下文；
  2. 无信息时回答无法回答；
  3. 输出时可以附带依据；
  4. 对医疗建议加安全声明，提示不能替代医生诊断；
  5. 可增加答案一致性校验或让模型判断答案是否被上下文支持。

Q14：医疗 RAG 项目应该如何评估效果？不能只看大模型回答是否流畅吗？

参考回答：

不能只看回答是否流畅。RAG 系统要分模块评估，也要做端到端评估。因为一个最终回答不好，可能是实体识别错了、实体对齐错了、意图识别错了、Cypher 查错了，也可能是检索对但生成阶段产生了幻觉。

我会把医疗 RAG 的评估拆成五层：

  1. NER 实体识别评估；
  2. 实体对齐评估；
  3. 意图识别和查询生成评估；
  4. 图谱检索评估；
  5. 最终回答质量和医疗安全评估。

第一层是 NER。这个可以用序列标注常见指标，比如 precision、recall、F1。项目 README 里记录过 RoBERTa 加数据增强后测试集 F1 从 96.77% 提升到 97.40%。但这里要注意，NER F1 高不代表整个 RAG 就好，只能说明实体边界和类型识别比较准。

第二层是实体对齐。可以准备一批用户 mention 到标准图谱实体的标注集，评估 Top1 Accuracy、Recall@K，以及错误对齐率。医疗场景里错误对齐风险很高，比如把一个症状或疾病对齐错，后面回答就会完全偏掉，所以低置信度时宁可不对齐。

第三层是意图识别和查询生成。我的系统里意图识别是 Prompt 方式，可以评估多标签分类的 precision、recall、F1；查询生成可以评估生成的查询类型、疾病名、属性名、关系名是否和标准答案一致，也可以看 Cypher 或中间查询语句是否可执行。

第四层是检索效果。GraphRAG 的检索不是普通文档 chunk，而是图谱节点、关系和属性。可以评估：

实体是否命中
关系是否命中
属性是否命中

第五层是最终回答质量。除了人工判断答案是否正确，还要看是否基于检索结果、是否出现医疗幻觉、是否违反安全边界。医疗场景里更重要的是“不乱答”，所以可以额外统计拒答率、错误建议率和引用依据完整度。

如果面试官继续追问，我会强调：这类系统不能只看生成文本是否流畅，而要看“问题理解 -> 检索 -> 生成”整个链路是否都可靠。

© 2026 Your Name