面试官你好请简单自我介绍一下。王安全面试官好我叫王安全搞AI应用开发两年了主要用LangChain搭过几个RAG项目什么文档问答、知识库检索都整过今天来就是奔着咱们大厂工牌来的。面试官好那咱们直接进入正题。先聊点基础的——说说RAG的基本流程每一步大概干什么王安全这个简单RAG就是检索增强生成嘛先把文档切成块扔进向量库用户提问了就去向量库搜搜出来拼到Prompt里喂给大模型完事儿面试官说得比较粗。那我追问一句——文档分块策略有哪些实际项目中你怎么选王安全分块嘛……不就是设个chunk_size比如512、1024然后切就完了。语义分块我也听说过但感觉差不多用默认的就行。面试官再问一个——向量数据库你用过哪些选型时主要看什么指标王安全我用过Chroma和FAISSChroma轻量好用FAISS快。选型嘛……就看哪个Star多吧社区活跃的总没错。面试官行那咱们继续深入。RAG检索效果不好你会怎么一步步排查和优化王安全效果不好啊……那就调大top_k多召回几条或者换个更大的Embedding模型还不行就……让Prompt里写请务必根据上下文回答给模型施压面试官你这个施压法挺有创意。那换个话题——CoT和ToT这两种Prompt策略有什么区别分别在什么场景用王安全CoT就是让我们一步一步思考嘛ToT就是……Tree of Thoughts让模型像树一样思考反正都是让模型多想几步区别不大我一般都写请仔细思考后回答效果差不多。面试官再问一个实际问题——多轮对话场景下RAG系统怎么管理上下文和对话记忆王安全把历史对话全拼一起塞进去如果token超了就删最早的简单粗暴但有效。面试官好最后一轮。解释一下ReAct模式它在Agent里是怎么工作的王安全ReAct就是Reasoning Acting模型一边想一边干活。比如用户问今天北京天气怎么样模型先想我需要调用天气API然后调API拿到结果再想结果拿到了该组织回答了。大概就这样。面试官说得还行。那Agent的短期记忆和长期记忆怎么设计有什么区别王安全短期记忆就是当前对话的上下文窗口长期记忆……存数据库呗用户说过的偏好存起来下次用。具体怎么存我还没深入搞过但肯定是RedisMySQL一套带走。面试官最后一个问题——RAG系统的检索质量和生成质量分别怎么评估用哪些指标王安全检索看准确率呗搜出来的跟问题相关就对了。生成的话……让GPT-4当评委打分BLEU、ROUGE我也听过但没用过感觉做个Demo不用那么麻烦。面试官了解了。今天先到这儿你回去等通知吧。王安全好嘞工牌照片我准备好了随时可以入职心里嘀咕这次稳了。参考答案第一轮RAG基础Q1RAG的基本流程是什么核心原理RAGRetrieval-Augmented Generation检索增强生成本质上是在大模型张嘴回答之前先给它翻资料。整个流程可以类比为一个学生大模型参加开卷考试先到资料库向量数据库里找到相关参考书页检索然后把书页摊在桌上对照着写答案生成。标准RAG流程分为两大阶段离线索引阶段Indexing文档加载从PDF、网页、数据库等多源读入原始文档。文档分块将长文档按策略切成若干小段chunk每段是检索的最小单元。向量化用Embedding模型如text-embedding-3-large、bge-large-zh把每个chunk转成向量。向量入库将向量和原始文本一起存入向量数据库如Milvus、Pinecone、Chroma。在线查询阶段QueryingQuery向量化用户问题同样过Embedding模型转成向量。相似度检索在向量库中做ANN近似最近邻搜索召回top_k个最相似的chunk。重排序可选用Cross-Encoder模型对召回结果精排筛掉不相关的。上下文注入将检索到的文本块拼接进Prompt模板作为上下文。LLM生成大模型基于问题检索上下文生成最终答案。实际业务场景举例某企业内部知识库问答系统员工问年假怎么申请系统先从公司制度文档里检索到年假申请流程相关段落注入Prompt后让模型给出准确答案并附出处。没有RAG的话模型只能靠训练数据瞎编大概率给出一个不适用于该公司的通用回答。最佳实践建议离线阶段和在线阶段的Embedding模型必须保持一致。检索到的上下文不要直接硬塞建议加上编号和来源标注方便模型引用。对回答要求高准确率的场景必须加重排序环节。Q2文档分块策略有哪些实际项目中怎么选核心原理文档分块决定了检索的最小单元长什么样。切太大检索粒度粗、噪声多切太小语义碎片化、丢失上下文。这就像图书馆的书籍索引——按章索引太粗按句索引又太碎需要找到合适的粒度。主流方案对比| 策略 | 做法 | 优点 | 缺点 | 适用场景 | |------|------|------|------|----------| |固定大小分块| 按字符/token数切如chunk_size512overlap50 | 实现简单成本低 | 语义截断风险高可能在句子中间切断 | 文档结构规整、快速原型验证 | |句子级分块| 按句号/换行等分隔符切保持句子完整 | 语义完整性好 | 句子长度不一可能导致某些chunk过长或过短 | 对话记录、FAQ文档 | |段落级分块| 按自然段落切 | 天然语义边界 | 段落长度不可控 | 结构清晰的制度文档、技术手册 | |语义分块| 用模型判断语义边界在语义转折点处切 | 语义连贯性最佳 | 实现复杂需要额外模型开销 | 高质量知识库、混合类型文档 | |递归分块| 先用大分隔符如\n\n切超长的再用小分隔符如\n递归切 | 兼顾结构和长度控制 | 实现稍复杂 | LangChain默认推荐通用性好 | |父子分块| 检索用小chunk提升精度注入LLM时带回大chunk父文档保证上下文完整 | 兼顾检索精度和生成质量 | 存储开销翻倍 | 对回答完整性要求高的场景 |优缺点深度分析固定分块最大的坑是一刀切在腰上——比如切在了一个关键定义的正中间导致检索到的片段无法独立理解。overlap能部分缓解这个问题但不能根治。语义分块虽然效果好但需要额外的Embedding计算来判断语义相似度变化索引阶段的时间成本显著增加。对于百万级文档需要权衡是否值得。实际业务场景举例客服FAQ库用句子级分块每个问答对独立成一个chunk检索精准。法律合同库用段落级父子分块检索时用小chunk匹配条款号注入LLM时带上前后文。混合技术文档用递归分块代码块保持完整特殊分隔符文字部分按段落切。最佳实践建议没有万能chunk_size建议针对自己的文档做小规模实验固定几个典型query测试不同分块策略下的召回效果。overlap一般设为chunk_size的10%~20%。如果文档本身有清晰的层级结构标题-章节-段落优先利用元数据做结构化分块检索时可以按层级过滤。Q3向量数据库怎么选型核心原理向量数据库的核心能力是高效存储和检索高维向量。其底层依赖ANN近似最近邻算法常见的有HNSW分层导航小世界图、IVF倒排索引、PQ乘积量化等。选型时不能只看跑分要结合自己的业务阶段和需求。主流方案对比| 数据库 | 定位 | 优点 | 缺点 | 适合谁 | |--------|------|------|------|--------| |Chroma| 轻量级原生向量库 | 零配置、Python原生、适合原型开发 | 生产环境性能有限 | 个人项目、Demo、早期验证 | |FAISS| Meta开源的向量检索库 | 极致性能、丰富索引算法 | 不是完整数据库需自己管理存储 | 需要极致检索速度、有工程能力 | |Milvus| 云原生分布式向量库 | 分布式架构、十亿级扩展、完善生态 | 部署运维成本高 | 中大型生产系统 | |Pinecone| 全托管云服务 | 免运维、开箱即用 | 贵、数据在云端有合规风险 | 不想管基础设施的团队 | |Weaviate| 向量关键词混合检索 | 原生支持Hybrid Search | 社区资源相对少 | 需要同时做关键词和语义检索 | |Qdrant| 高性能Rust实现 | 性能优秀、过滤能力强 | 相对小众 | 对过滤查询有强需求的场景 | |Elasticsearch 向量插件| 传统搜索引擎向量能力 | 已有ES基础设施的可平滑升级 | 向量性能不如专用向量库 | 已有ES的团队 |选型核心维度数据规模百万级以内几乎哪种都能扛上亿级必须考虑Milvus/Pinecone这类分布式方案。运维能力有没有专职运维没有就选Pinecone/Zilliz Cloud全托管。过滤需求是否需要复杂的元数据过滤如只查2024年的文档这和纯向量检索不一样很多库的过滤能力天差地别。预算开源自建便宜但要人维护云服务省心但贵。延迟要求实时对话场景要求500ms需要关注P99延迟。实际业务场景举例创业团队MVP阶段用Chroma快速搭原型验证产品方向。中型企业文档问答系统百万文档量级上Milvus单机版性能够用成本可控。大型互联网公司十亿级Milvus集群 自建运维或直接采购Zilliz Cloud企业版。最佳实践建议原型阶段用Chroma快速验证确定产品方向后再做生产选型避免过早优化。不管选哪个务必先建好索引策略的评测Pipeline相同数据、相同query对比不同数据库的召回率和延迟。ES向量插件方案适合搜索团队本来就熟ES的组织不建议为了向量检索专门引入ES。第二轮Prompt工程与RAG优化Q4RAG检索效果不好怎么一步步排查和优化核心原理RAG检索效果不好不能只甩锅给向量库不行或Embedding模型太差。这是一个系统工程问题需要沿着文档→分块→向量化→检索→重排序这条链路逐环节排查就像水管堵了你得一段一段找堵点。系统化排查流程第一步检查原始文档质量文档是不是扫描件/图片OCR识别率如何文档中有没有表格、代码块等特殊内容它们对Embedding模型是灾难。排查方法随机抽20条召回失败的query人工看对应的源文档是否能回答。如果源文档本身就缺答案那是知识库覆盖度问题不是检索问题。第二步检查分块策略用固定分块是否截断了关键信息Chunk是否太大导致信息稀释或太小导致语义不完整排查方法把召回的chunk打印出来人工判断这段文字能独立回答用户问题吗。第三步检查Embedding质量Embedding模型是否与文档语言/领域匹配中文文档用英文模型效果必然差是否考虑了query和document的Embedding不对称性用户query很短文档chunk很长排查方法计算query和召回chunk的余弦相似度分布看高分chunk是否真的相关。第四步检查检索策略top_k设得是否合理太小漏召回太大引入噪声。是否用了Hybrid Search向量关键词混合检索排查方法对比top_k3/5/10/20下的召回率曲线。主流优化方案| 优化方向 | 具体手段 | 难度 | 效果 | |----------|----------|------|------| |分块优化| 语义分块、父子分块、小chunk检索大上下文注入 | 中 | ⭐⭐⭐⭐ | |Embedding升级| 换领域专用模型、做query/doc不对称Embedding | 低 | ⭐⭐⭐ | |混合检索| BM25关键词检索 向量语义检索结果融合RRF | 中 | ⭐⭐⭐⭐ | |重排序| 用Cross-Encoder如bge-reranker对召回结果精排 | 中 | ⭐⭐⭐⭐⭐ | |Query改写| 用LLM把用户口语化query改写成更利于检索的形式 | 中 | ⭐⭐⭐⭐ | |多路召回| 同时从不同索引不同分块粒度/不同Embedding召回然后合并 | 高 | ⭐⭐⭐⭐ | |HyDE| 先让LLM生成假设答案用假设答案的向量去检索 | 高 | ⭐⭐⭐ |实际业务场景举例某医疗问答系统用户问二甲双胍有啥副作用检索结果却召回一堆二甲双胍的化学结构。排查发现文档中副作用信息以表格形式存在Embedding模型对表格理解差。解决方案对表格做专项解析table2text将表格转为自然语言描述后再入库。最佳实践建议优化顺序建议先加重排序投入产出比最高再搞混合检索最后才动分块和Embedding。建立检索评测集人工标注50~100个query的理想召回文档每次优化后跑一遍评测用数据说话。重排序是性价比最高的优化手段加一个bge-reranker往往能让检索效果提升30%以上。Q5CoT和ToT这两种Prompt策略有什么区别核心原理CoTChain of Thought思维链的核心思想是让模型在给出最终答案之前先输出中间推理步骤。就像老师要求学生把解题过程写出来而不是只给一个答案。它解决的是模型跳过推理直接猜答案的问题。ToTTree of Thoughts思维树更进一步不只是一条链往下推而是在推理的每一个节点同时探索多个分支然后评估每个分支的前景选择最有希望的分支继续深入。这类似于下棋时的多步推演——不是只想一步而是同时想好几步棋评估每种走法的优劣。两者对比| 维度 | CoT | ToT | |------|-----|-----| |推理结构| 线性链式A→B→C→答案 | 树状分支每个节点可展开多个子节点 | |探索方式| 单一推理路径 | 多条路径并行探索 剪枝 | |计算开销| 低一次推理完成 | 高需要多次推理和评估 | |适用场景| 数学推理、逻辑题、需要步骤拆解的任务 | 需要探索多种方案的任务创意写作、策略规划、编程难题 | |实现复杂度| 低Prompt里加一句Lets think step by step | 高需要设计评估函数和搜索策略BFS/DFS | |典型效果| 显著提升数学和逻辑任务准确率 | 在需要多方案对比的任务上优于CoT |实际业务场景举例CoT场景用户问算一下我今年应缴个税模型需要先确定应纳税所得额→匹配税率表→计算→得出结果。Prompt写请一步步计算能显著减少计算错误。ToT场景AI写营销文案需要同时生成情感路线理性路线幽默路线三个方向然后评估哪个方向最适合目标受众再沿最优方向细化。最佳实践建议日常业务场景中CoT已经能覆盖90%的需求ToT更多用于学术研究和复杂决策场景。CoT的Lets think step by step不是万能的对简单问题反而可能降低效率。建议根据问题复杂度动态决定是否启用。在Agent场景中ToT的思想可以用于工具选择Agent面对多个可用工具时可以并行推演每种工具调用的结果选择最优执行路径。Q6多轮对话场景下RAG系统怎么管理上下文和对话记忆核心原理多轮对话的难点在于用户说的每一句话都可能依赖前面说过的东西。比如用户RAG是什么 → 模型回答了用户那它和微调有什么区别 —— 这个它指的就是RAG需要记住上一轮的对话内容。在RAG系统中对话记忆管理需要同时处理两件事对话历史用户说了啥、模型答了啥和检索上下文每轮从知识库搜出来的资料。主流方案| 方案 | 做法 | 优点 | 缺点 | |------|------|------|------| |全量拼接| 把所有历史对话全拼进Prompt | 实现简单信息不丢失 | Token消耗线性增长总有爆掉的一天 | |滑动窗口| 只保留最近N轮对话 | 控制Token增长 | 早期对话信息丢失 | |摘要压缩| 用LLM对历史对话做摘要只保留关键信息 | Token稳定信息密度高 | 摘要过程可能丢失细节 | |混合策略| 近期对话保留原文 远期对话保留摘要 | 兼顾细节和效率 | 实现稍复杂 | |结构化记忆| 把对话中提取出的实体、偏好存入结构化存储 | 可持久化、可跨会话 | 需要额外设计记忆提取逻辑 |多轮对话中的RAG检索策略多轮对话还要考虑每一轮要不要重新检索每轮检索每轮用户发言都独立检索适合话题跳转频繁的场景。Query改写后检索把用户当前query结合历史对话改写成完整语义后再检索。比如用户说那它的副作用呢先改写成二甲双胍的副作用再检索。这是目前效果最好的做法。首轮检索后续过滤首轮检索结果缓存下来后续轮次在缓存结果基础上过滤适合话题不跳转的场景。实际业务场景举例智能客服场景用户先问怎么退货系统检索退货政策并回答。用户接着问运费谁出系统需要①知道运费指的是退货场景下的运费②可能需要从之前检索到的退货政策中直接提取而不是重新检索。最佳做法是每轮做Query改写结合历史对话上下文然后重新检索。这样既利用了对话历史又保证了检索的准确性。最佳实践建议对话记忆和检索上下文要分两个区域管理不要混在一起。Prompt模板建议结构系统指令 检索上下文 对话历史摘要 当前用户问题。设置一个话题切换检测当检测到用户话题明显切换时清空或大幅压缩历史上下文重新开始。Token预算分配建议系统指令占10%检索上下文占50%对话历史占30%当前问题占10%。第三轮Agent与评估Q7解释一下ReAct模式它在Agent里是怎么工作的核心原理ReActReasoning Acting是Agent的操作系统。它让模型在思考和行动之间交替循环Thought思考我现在需要做什么 Action行动调用某个工具/API Observation观察工具返回了什么结果 Thought再思考基于结果下一步做什么 ...重复直到得出最终答案...这个循环类比为一个人接到任务帮我查一下北京今天天气如果下雨就提醒我带伞。他会先想需要查天气→打开天气App→看到晴→想不用带伞→回复今天晴天不用带伞。ReAct vs 纯推理 vs 纯行动| 模式 | 特点 | 局限 | |------|------|------| |纯推理CoT| 只思考不行动 | 无法获取外部信息容易幻觉 | |纯行动| 只调用工具不推理 | 不知道何时该用哪个工具乱调 | |ReAct| 思考与行动交替 | 结合两者优势可纠错、可动态调整 |ReAct的关键设计点工具描述Tool Description每个工具需要在Prompt中清晰描述其功能、参数、返回值。模型靠这些描述决定什么时候该调哪个工具。停止条件模型需要知道什么时候该停止行动、给出最终答案。通常用特殊标记如Final Answer:来触发。错误处理工具调用失败时模型需要能看懂错误信息并调整策略而不是死循环。实际业务场景举例用户问Agent帮我查一下最近3天关于GPT-5的最新新闻用中文总结要点。ReAct循环Thought需要先搜索新闻 → Action调用搜索工具 → Observation返回10条英文新闻链接Thought需要获取这几篇的正文 → Action调用网页抓取工具 → Observation返回新闻正文Thought正文是英文需要翻译和总结 → Action调用翻译总结工具 → Observation得到中文摘要Thought整理一下就可以回复了 → Final Answer输出最佳实践建议工具描述是ReAct的命门写得越清晰具体越好建议包含功能一句话描述、参数列表及类型、返回值格式、使用场景举例。设置最大迭代轮数如max_iterations10防止Agent陷入死循环。在Prompt中加入如果工具连续调用3次都没得到有用信息请停止并告知用户这类安全策略。Q8Agent的短期记忆和长期记忆怎么设计核心原理Agent的记忆系统仿照人脑的设计短期记忆当前任务/对话的工作台任务结束就清空。类比你做饭时脑子里记的现在炒到哪一步了。长期记忆跨会话持久化的信息下次对话还能调出来。类比你知道女朋友不吃香菜这个信息不会因为一顿饭做完就忘掉。短期记忆设计短期记忆的核心载体就是LLM的上下文窗口。设计要点结构化管理不要把所有信息堆在一起建议分区域管理系统指令区不变任务目标区当前任务描述工具调用历史区ReAct的Thought-Action-Observation序列中间结果区工具返回的有用信息记忆压缩当ReAct循环太多上下文快满时对中间过程做摘要压缩保留关键结论、丢弃冗余的试错过程。优先级裁剪不是所有信息都同等重要。可以设计规则——工具调用成功的关键结果优先级高于失败的尝试。长期记忆设计长期记忆的实现方案| 方案 | 做法 | 适用场景 | |------|------|----------| |结构化字段存储| 在数据库中维护用户画像表字段如偏好语言常用地址历史问题主题 | 用户偏好类信息 | |向量化记忆库| 将每次对话的关键信息向量化存入向量库下次对话时检索相关记忆 | 海量用户、复杂记忆 | |知识图谱| 将实体和关系抽取为图谱支持推理式回忆 | 需要关系推理的场景 | |摘要链| 每次对话结束自动生成摘要存入用户档案 | 通用、成本低 |短期 vs 长期记忆对比| 维度 | 短期记忆 | 长期记忆 | |------|----------|----------| |生命周期| 单次会话 | 跨会话持久化 | |存储位置| LLM上下文窗口 | 数据库/向量库 | |容量| 受Token上限约束通常几万Token | 理论上无限 | |访问速度| 即时已在Prompt中 | 需要检索 | |典型内容| 当前对话、工具调用历史 | 用户偏好、历史摘要、知识积累 |实际业务场景举例个人AI助理场景短期记忆用户说帮我订明天去上海的机票Agent查航班、确认时间、下单整个流程的工具调用链存在短期记忆中。长期记忆Agent记得用户偏好靠过道的座位常用国航身份证号是xxx加密存储下次订票时自动带上这些偏好不需要用户重复说。最佳实践建议长期记忆的设计要遵循最小必要原则不要什么都记只记对后续任务有用的信息。记忆更新策略用户偏好可能变化老旧的记忆要有过期机制或衰减权重。隐私合规长期记忆涉及用户数据必须做脱敏和加密存储且提供忘记我功能。Q9RAG系统的检索质量和生成质量分别怎么评估核心原理评估是RAG系统最容易被忽视但又最关键的一环。没有评估优化就靠拍脑袋。评估分为两大块检索评估衡量搜得准不准——召回的文档和用户问题是否相关生成评估衡量答得好不好——生成的答案是否准确、完整、流畅检索评估指标| 指标 | 含义 | 通俗解释 | 计算方式 | |------|------|----------|----------| |RecallK| 前K个结果中包含相关文档的比例 | 10本书里有没有我要的那本 | 相关文档在top-K中的数量 / 所有相关文档总数 | |PrecisionK| 前K个结果中相关文档的比例 | 搜出来的10本书里几本是我要的 | top-K中相关文档数 / K | |MRR平均倒数排名| 第一个相关文档排在第几位的倒数 | 我要的书排第几名越靠前越好 | 所有query的(1/第一个相关文档排名)的平均值 | |NDCG| 考虑排名位置和相关性等级的归一化指标 | 相关文档排得越靠前分数越高 | 需要考虑相关性分级如0~3分 | |Hit Rate| 前K个结果中至少包含一个相关文档的query比例 | 至少有一本对的书 | 命中query数 / 总query数 |生成评估指标| 指标 | 类型 | 含义 | 局限 | |------|------|------|------| |BLEU| 自动/词重叠 | 计算生成文本和参考答案的n-gram重叠度 | 只看字面匹配不懂语义 | |ROUGE| 自动/词重叠 | 侧重召回计算参考答案中有多少内容被生成文本覆盖 | 同样只看字面 | |忠实度Faithfulness| LLM-as-Judge | 生成的答案是否严格基于检索上下文有没有编造 | 依赖评判模型质量 | |答案相关性Answer Relevance| LLM-as-Judge | 答案是否回答了用户的问题 | 同上 | |上下文相关性Context Relevance| LLM-as-Judge | 检索到的上下文是否与问题相关 | 同上 | |RAGAS综合框架| 组合评估 | 将上述多个指标组合成一个评估Pipeline | 需要一定的工程搭建 |实际业务场景举例某电商客服RAG系统评估准备50个真实用户问题的评测集人工标注每个问题的理想召回文档和参考答案。检索评估跑一遍系统看50个问题的Recall5是否达到90%以上。生成评估用GPT-4对每个答案的忠实度打分1~5分要求低于4分的答案必须人工复核。建立在线监控每天自动抽样10条线上对话跑RAGAS评估指标异常时告警。最佳实践建议评估必须同时看检索和生成只看一个维度会得出错误结论。比如检索满分但生成乱编系统仍然不可用。自动评估BLEU/ROUGE只能做初步筛选业务上线前必须做LLM-as-Judge评估或人工评估。评估集需要持续更新线上bad case要定期加入评测集防止系统在固定评测集上过拟合。RAGAShttps://github.com/explodinggradients/ragas是目前最流行的RAG评估框架建议直接基于它搭建评估Pipeline不要从零造轮子。总结以上9道题覆盖了AI应用开发面试中RAG、Prompt工程、Agent和评估四个核心板块。王安全式的皮毛回答在真实面试中大概率是回家等通知每个技术点都值得深挖背后的原理和trade-off。希望这份参考答案能帮到你。