AI 应用开发面试题

01 RAG 的原理和解决了什么问题

从稳定性、成本与效率、规模化演进多视角切入，RAG 是大模型落地企业级知识密集型场景的必经之路 —— 从稳定性视角，大模型的检索幻觉 Retrieval Hallucination会导致生成结果不可控，而 RAG 通过外部检索的确定性上下文约束生成逻辑，规避业务决策风险；
从成本与效率视角，全量微调需消耗海量算力与标注成本，且知识更新周期长，RAG 用增量知识检索 Incremental Knowledge Retrieval替代模型级重训练，将知识更新成本降至文档级写入，同时通过上下文裁剪 Context Pruning控制 Token 消耗；
从规模化演进视角，RAG 实现了知识存储与推理计算的解耦，知识体系可独立横向扩展。大模型预训练知识的时间窗口限制、生成结果的不可靠性，以及全量微调的高成本与低迭代效率，共同决定了仅靠大模型本身无法满足企业级知识服务的核心需求，而 RAG 构建的 “检索 - 增强 - 生成” 协同链路精准破解了这一系列底层矛盾。

用户原始查询先进入查询预处理集群，完成清洗标准化后按 Token 长度阈值拆分处理，长查询经语义分块后与短查询统一执行查询重写，确保检索输入的规范性，这是规模化演进视角下的标准化预处理设计，支撑高并发场景的统一检索入口。
预处理后的查询通过分布式检索网关并行触发向量检索+关键词检索，双检索并行提升效率；检索结果需经过双重精度校验，未达阈值时触发熔断降级，启用低延迟基础检索池保障服务可用性，这是稳定性与效率视角的协同设计。
有效检索结果经 Cross-Encoder 重排序后，执行上下文过滤与 Token 裁剪，超标则异步截断，严格控制输入 Token 占比，既避免大模型输入窗口溢出，又降低推理 Token 成本，兼顾稳定性与成本优化。
最终构造的 Prompt 送入 vLLM 推理集群生成结果，落地包含查询 ID、检索片段 ID、相似度得分、生成 Token 数等字段的审计日志后返回用户，日志支撑规模化场景下的问题追溯与效果迭代。

从稳定性、成本与效率、安全与边界多视角切入，对话 history 处理是长对话场景的核心技术 —— 从稳定性视角，大模型输入窗口有限导致 history 无限制传入会引发 Token 溢出 Overflow，进而导致显存碎片化与服务雪崩，history 处理通过裁剪与压缩控制 Token 规模，保障服务稳定；
从成本与效率视角，冗余 history 会增加推理 Token 成本与延迟，精准的 history 筛选可降低 30% 以上的 Token 消耗，提升推理效率；
从安全与边界视角，history 中可能包含用户隐私信息，处理过程中的数据隔离与脱敏可规避隐私泄漏风险。长对话场景的上下文连贯性需求与大模型输入窗口限制、成本控制、隐私合规的矛盾，决定了仅靠简单传入 history 无法满足企业级对话服务的需求，而系统化的 history 处理机制，通过 “筛选 - 压缩 - 存储 - 复用” 全链路设计精准平衡了连贯性、稳定性、成本与安全的核心诉求。

用户输入新查询后，对话网关按用户 ID从分布式缓存集群拉取全量 history，基于用户 ID 的路由设计确保同一用户的上下文连贯性，分布式缓存则支撑规模化用户的 history 高效存储与快速查询，契合规模化演进视角的需求。
历史处理模块先通过语义相似度阈值（＜0.7）过滤无关 history，再利用 BART-base 模型做长 history 压缩，之后经隐私脱敏模块校验，移除手机号、邮箱等隐私信息，符合安全与边界视角的合规要求；处理后执行Token 计数校验，避免触发大模型输入窗口限制，保障稳定性。
处理后的上下文返回对话网关并缓存（过期时间 24h），后续用于构造 Prompt 送入大模型推理集群；若生成失败（Token 溢出），则触发二次压缩进一步裁剪 history，形成失败补偿机制，强化稳定性。
生成成功后，对话网关将 history 处理日志（含处理前后 Token 数、过滤/压缩策略、脱敏记录）与生成日志落地审计系统，支撑问题追溯与策略优化，同时将结果返回用户，完成全链路流转。