字节后端一面#

固定窗口#

固定窗口是把时间切成固定长度的窗口，比如每 1 秒一个窗口。每个窗口内维护一个计数器，请求进来时计数加 1，只要计数没有超过阈值就放行；超过阈值就拒绝。窗口结束后，计数器清零，进入下一个窗口。

• 优点：实现简单，计数成本低，适合对精度要求不高的场景。
• 缺点：存在临界突刺问题。比如限制每秒 100 次请求，用户可以在上一秒最后 100 毫秒打满 100 次，又在下一秒最开始 100 毫秒再打 100 次，短时间内实际通过 200 次请求。

滑动窗口#

滑动窗口是在固定窗口基础上做细粒度拆分。比如把 1 秒拆成 10 个 100 毫秒的小窗口，每次统计最近 1 秒内多个小窗口的请求总数。随着时间推进，窗口会不断向前滑动。

• 优点：比固定窗口更平滑，可以缓解临界突刺问题，限流结果更接近真实的最近一段时间请求量。
• 缺点：实现和存储成本更高，需要维护多个小窗口的计数。窗口拆得越细，精度越高，维护成本也越高。

漏桶#

漏桶可以理解为一个固定容量的桶，请求先进入桶里排队，系统按照固定速率从桶里取出请求并处理。如果桶满了，后续请求会被拒绝或丢弃。

• 优点：输出速率稳定，可以把突发流量整形成平稳流量，适合保护下游服务。
• 缺点：对突发流量不够友好。即使系统短时间内还有处理能力，漏桶也会按照固定速率放行，请求可能在桶里等待或被拒绝。

令牌桶#

令牌桶是系统按照固定速率往桶里放令牌，桶有最大容量。请求到来时需要先拿到令牌，拿到令牌才能通过；没有令牌就被拒绝或等待。桶里如果积累了一些令牌，短时间内可以允许一批请求同时通过。

• 优点：既能限制平均速率，也能允许一定程度的突发流量，适合秒杀、网关、接口限流等场景。
• 缺点：参数需要结合业务容量设置，比如令牌生成速率和桶容量。桶容量设置过大时，瞬时突发流量仍然可能对下游造成压力。

Cache Aside 的基本流程#

读请求：

1
先读 Redis
2
-> Redis 命中，直接返回
3
-> Redis 未命中，读 MySQL
4
-> 把 MySQL 查询结果写回 Redis
5
-> 返回结果

写请求：

1
先更新 MySQL
2
-> 再删除 Redis 缓存

写请求里通常选择删除缓存，让后续读请求重新从 MySQL 加载最新数据。这样可以避免复杂缓存内容在并发更新时被错误覆盖。

主从延迟带来的旧数据问题#

如果 MySQL 做了读写分离，写请求更新的是主库，读请求可能走从库。主库同步到从库存在延迟，所以缓存删除之后，如果有读请求回源到从库，就可能读到旧数据，并把旧数据重新写回 Redis。

这个问题可以根据一致性要求分层处理：

1. 普通最终一致场景
   可以使用延迟双删。更新主库后先删除缓存，等待一段时间后再删除一次缓存，清掉可能被旧数据回填的缓存。延迟时间需要参考主从同步延迟，一般取大于主从延迟 P99 的时间。

2. 删除动作可靠性
   可以结合消息队列、binlog 监听或重试任务，保证缓存删除动作最终执行成功。比如监听 MySQL binlog，发现数据变更后异步删除对应 Redis Key。

3. 强一致场景
   对订单状态、支付状态、库存扣减结果这类强一致读，可以在写后一段时间内强制读主库，或者直接绕过缓存和从库，以 MySQL 主库结果为准。

秒杀热点场景的补充#

秒杀库存属于热点高并发写场景，如果每次购买都同步更新 MySQL 再删除 Redis，后续大量读请求可能同时回源 MySQL，导致数据库压力过高。

这类场景通常把库存提前预热到 Redis：

1
活动开始前：
2
MySQL 库存 -> 预热到 Redis
3

4
用户抢购时：
5
Redis 原子扣减库存
6
-> 扣减成功后发送 MQ
7
-> 消费者异步创建订单、落 MySQL、扣数据库库存

Redis 承接高并发读写，MySQL 作为最终数据源。后续通过 MQ 消费、库存流水、订单状态和对账任务保证最终一致性。

面试时可以总结为：

普通读多写少业务可以用 Cache Aside，写 MySQL 后删除 Redis，保证最终一致性。如果存在主从延迟，缓存删除后可能从从库读到旧数据并回填 Redis，普通场景可以用延迟双删或 binlog 监听做二次删除；强一致场景可以在写后一段时间内强制读主库，或者直接绕过缓存和从库。秒杀库存这种热点场景会用 Redis 预扣库存加 MQ 异步落库，再通过流水和对账保证最终一致。

缓存雪崩：大量 Key 同时过期#

常见处理方式包括过期时间随机化、分批预热、限流降级。

1
基础过期时间：30 分钟
2
随机偏移：0-5 分钟
3
实际过期时间：30-35 分钟

1
第 1 批：活动配置
2
第 2 批：热门商品基础信息
3
第 3 批：秒杀库存
4
第 4 批：商品详情和展示数据

缓存击穿：单个热点 Key 过期#

热点 Key 过期时，重点是避免所有请求同时回源 MySQL。常见方案是互斥锁和逻辑过期。

1
请求发现 Redis 未命中
2
-> 尝试获取分布式锁
3
-> 获取成功：查 MySQL，重建缓存，释放锁
4
-> 获取失败：等待后重试，或返回兜底结果

1
Redis value = 数据内容 + 逻辑过期时间
2

3
请求读取 Redis
4
-> 数据没过期：直接返回
5
-> 数据逻辑过期：先返回旧数据
6
-> 后台线程异步查 MySQL 并刷新缓存

结合秒杀项目的回答#

秒杀库存这类热点数据一般会提前预热到 Redis，抢购时通过 Redis 原子扣减库存，扣减成功后写入 MQ，由消费者异步落 MySQL。这样高并发入口主要打 Redis，MySQL 通过 MQ 被削峰。

面试时可以总结为：

如果缓存过期时流量很高，我会先区分缓存雪崩和缓存击穿。大量 Key 同时过期可以通过随机过期时间、分批预热、限流降级来缓解；分批预热会提前把热点数据分页加载到 Redis，并控制速率，避免预热过程压垮 MySQL。单个热点 Key 过期可以用互斥锁或逻辑过期，只让一个线程重建缓存，其他请求等待、重试或返回旧数据。秒杀库存这种热点场景会提前预热到 Redis，用 Redis 原子扣减加 MQ 异步落库，避免请求集中回源 MySQL。

数据质量#

知识库入库前要先做清洗、去重和去噪。比如去掉重复文档、无效 HTML、导航栏、广告、乱码内容，保留真正有业务价值的信息。

如果知识库内容本身质量很差，后面的向量检索和大模型生成都很难稳定。

文档切分#

文档切分要尽量按标题、段落、语义边界切分，避免把一个完整语义拆散。

Chunk 太大时，检索结果可能包含很多无关内容；Chunk 太小时，又容易丢失上下文。实际项目里一般会结合 chunk size、overlap 和文档结构来调整。

比如商品知识库可以按商品、规格、售后规则、活动规则切分；技术文档可以按标题、章节、段落切分。

Metadata 过滤#

入库时要保留标题、来源、业务类型、商品 ID、时间、权限、租户等 metadata。检索前可以先根据 metadata 做过滤，再做向量召回。

比如用户问某个商品的售后政策，可以先过滤到对应商品、售后文档、有效时间范围内的内容，再进行相似度检索。

这样可以减少无关文档进入候选集。

Query 改写#

用户问题可能比较口语化，也可能缺少关键词。可以对 Query 做关键词提取、同义词扩展、多路查询或结合历史上下文改写。

比如用户问“这个能不能退”，可以结合上下文改写成“某商品是否支持退货、退款、售后政策”。

Query 改写的目标是提高召回率，让检索系统更容易找到相关资料。

混合检索#

只用向量检索时，语义相似效果比较好，但可能漏掉精确关键词、编号、商品名、错误码、专业术语。只用关键词检索时，精确匹配强，但语义泛化能力弱。

所以可以使用混合检索：

1
向量检索：负责语义相似召回
2
关键词检索：负责精确关键词召回
3
混合排序：合并两路候选结果

常见组合是向量检索加 BM25。这样既能召回语义相近的内容，也能保留精确匹配能力。

Rerank 重排#

第一阶段检索通常会召回 TopK 候选片段，比如 Top20 或 Top50。召回后可以用 rerank 模型对候选片段重新排序，把和问题最相关的内容排到前面。

Rerank 的作用是提高前几条结果的相关性，因为最终塞进 Prompt 的内容数量有限，前几条质量会直接影响回答质量。

阈值控制#

检索结果需要设置相似度阈值或相关性阈值。如果最高分结果都很低，说明知识库里可能没有可靠答案。

这种情况下不应该强行把低相关内容塞给模型，否则模型容易根据弱相关材料编答案。更合理的做法是返回“知识库中没有找到明确依据”，或者让模型基于无资料状态拒答。

离线评估#

RAG 不能只靠感觉调参，需要准备一批测试问题和标准答案，评估检索效果。

常见指标包括：

1
Recall@K：正确资料有没有出现在前 K 个召回结果里
2
MRR：正确资料排在越前面分数越高
3
Hit Rate：问题是否命中了有效资料
4
人工评估：判断检索片段是否真的能支撑答案

通过这些指标可以持续调整 chunk 大小、overlap、TopK、阈值、metadata 过滤规则、混合检索权重和 rerank 策略。

面试时可以总结为：

我会从知识库质量、文档切分、召回策略、重排和评估几个方面保证 RAG 检索准确性。数据入库前先清洗、去重，并保留标题、来源、业务标签等 metadata；切分时按语义边界切 chunk，避免上下文丢失；检索时可以用向量检索结合关键词检索，提高语义召回和精确匹配能力；召回后再用 rerank 模型重排，把最相关的片段放到前面；最后设置相似度阈值，低于阈值就认为没有可靠资料，并通过离线问题集持续评估 Recall@K、MRR 等指标。

检索阈值#

检索阶段要设置相似度阈值或 rerank 分数阈值。如果召回结果低于阈值，说明知识库里没有足够相关的资料，就不把这些低相关片段强行塞给模型。

1
召回结果分数 >= 阈值：进入生成阶段
2
召回结果分数 < 阈值：判断为无可靠资料

这样可以减少模型基于弱相关内容进行发挥。

TopK 结果校验#

不能只看有没有召回结果，还要判断 TopK 结果是否真的覆盖用户问题。

比如用户问“某商品是否支持 7 天无理由退货”，检索结果只命中了商品介绍，没有命中售后规则，这种情况下也应该认为资料不足。

可以让系统在生成前先判断：

1
检索结果是否与问题相关
2
检索结果是否包含回答所需的关键信息
3
检索结果之间是否互相矛盾

如果结果不相关、信息不完整或互相冲突，就不要输出确定性结论。

Prompt 约束#

生成阶段要在 Prompt 里明确约束模型只能基于检索资料回答。

可以加入类似规则：

1
只能使用给定资料回答问题。
2
如果资料中没有答案，回复“知识库中没有找到相关信息”。
3
不要根据常识、经验或猜测补充资料中没有出现的内容。

这类约束可以降低模型自由发挥的概率。

引用约束#

答案最好绑定引用来源，比如文档标题、文档 ID、段落编号或来源链接。模型输出结论时，需要能对应到具体检索片段。

如果一个结论没有来源支撑，就不能作为确定答案输出。

这种方式可以让回答从“模型自己觉得对”变成“能在知识库里找到依据”。

结构化输出#

可以让模型先输出一个结构化判断，再决定是否回答。

例如：

1
has_answer: true / false
2
evidence: 命中的资料片段
3
answer: 最终回答

如果 has_answer=false，就直接返回资料不足的说明，不进入正常回答。

这种方式可以把“是否有依据”和“生成答案”拆开，减少无依据生成。

评估监控#

线上需要记录无答案问题、低置信度问题、用户负反馈和人工标注结果。后续可以把这些问题用来补充知识库、优化切分策略、调整阈值和改进 Query 改写。

RAG 的幻觉控制不是只靠 Prompt，一般需要检索阈值、证据约束和评估反馈一起做。

面试时可以总结为：

如果知识库里没有准确答案，我不会让模型强行回答。检索阶段会设置相似度阈值和 rerank 阈值，低于阈值就判断为无可靠资料；生成前会检查 TopK 结果是否真的覆盖问题；Prompt 中会约束模型只能基于检索资料回答，没有依据就说明知识库中没有找到相关信息；答案需要带引用来源，没有证据支撑的结论不能输出。还可以让模型先输出 has_answer 判断，再决定是否生成答案，并记录无答案问题用于后续补充知识库和优化检索。