AI Agent 面试 - 高频拷打题合集（牛客热帖 3.1W 浏览）

来源：牛客网热帖 "Agent面试拷打！" 2025-03-24 | 浏览量 31000+

这些是当前面试中实际在问的题目，适合逐题准备。

---

一、Agent 架构与设计

1. 你理解的 Agent 架构是什么？一个 Agent 系统一般由哪些模块组成？

参考答案：

• Agent 本质是 LLM + 感知 + 规划 + 行动 + 记忆 的闭环系统，能自主完成多步骤任务

• 核心模块：**Brain（LLM）**负责推理与决策；Planning 负责任务分解与路径规划；Memory 提供上下文与历史信息；Tool Use 执行外部操作（API/数据库/搜索）；Observation 接收工具返回并反馈给 LLM

• 典型架构参考：OpenAI Function Calling 模式、LangChain Agent、AutoGPT 循环架构

• 控制流一般是 循环式：Perceive → Think → Act → Observe → Think → ... 直到任务完成或达到最大轮次

• 工程层面还需要：Guardrails（输出校验/安全过滤）、日志与可观测性、错误重试与降级策略

2. Tool 是怎么设计的？什么样的功能应该做成 Tool？

参考答案：

• Tool = 一个有明确输入输出的函数，通过 JSON Schema 描述参数，让 LLM 能理解何时调用、如何传参

• 适合做成 Tool 的场景：LLM 本身做不好的事——实时数据查询、精确计算、外部系统操作（下单/发邮件）、文件读写

• 设计原则：单一职责（一个 Tool 做一件事）、参数语义清晰（description 写给 LLM 看）、返回值结构化（便于 LLM 解析）

• 要做好 错误处理：Tool 执行失败时返回有意义的错误信息而非直接抛异常，让 LLM 能据此调整策略

• 工程实践：Tool 数量控制在 10-20 个以内，太多会导致 LLM 选择困难；可以用 Tool Router 或分层 Agent 解决工具过多问题

• 安全方面：高危操作（删除/支付）需加 人工确认环节（Human-in-the-loop）

3. Memory 分几种？Short-term / Long-term memory 怎么实现？

参考答案：

• 短期记忆（Short-term）：当前对话的上下文窗口，直接放在 prompt 的 message history 里；受 token 限制，需要做截断或摘要

• 长期记忆（Long-term）：跨会话持久化，通常存向量数据库（如 Pinecone/Milvus），每轮对话结束后将关键信息 embedding 后存入

• 工作记忆（Working Memory）：当前任务的中间状态，如 scratchpad、变量存储，用于多步推理过程中保持上下文

• 短期→长期的转化：会话结束时用 LLM 提取摘要/关键事实，写入长期存储；下次会话开始时检索相关记忆注入 prompt

• 实现方案：短期用 Redis/内存；长期用向量库 + 结构化数据库（用户画像/偏好用关系型存储更合适）

• 关键挑战：记忆的遗忘与更新——旧信息可能过时，需要有机制覆盖或衰减

4. Agent 是怎么做任务规划的？是 ReAct 还是 Plan-Execute？

参考答案：

• ReAct（Reasoning + Acting）：每一步都 Thought → Action → Observation 交替进行，边想边做，适合探索性任务和步骤不确定的场景

• Plan-and-Execute：先一次性生成完整计划（步骤列表），再逐步执行，适合结构化任务（如"帮我订机票+酒店+行程规划"）

• 实际生产中常用混合方案：先粗粒度 Plan，执行过程中遇到异常再用 ReAct 动态调整（Adaptive Planning）

• Plan-and-Execute 的优势：减少 LLM 调用次数、可以做进度展示、支持人工审批

• ReAct 的优势：灵活、能处理意外情况、不需要预知所有步骤

• 高级方案：Tree of Thought（多路径探索）、Reflection（执行后自我反思并修正计划）

5. 多 Agent 协作是怎么做的？

参考答案：

• 常见协作模式：主从模式（Orchestrator + Worker Agents）、管道模式（顺序传递）、辩论模式（多 Agent 讨论达成共识）

• 典型框架：CrewAI（角色分工）、AutoGen（多 Agent 对话）、LangGraph（图状态机编排）

• 通信机制：共享 Blackboard（共享状态空间）、消息传递（Agent 之间直接对话）、中央协调器分发任务

• 工程要点：每个 Agent 要有明确的角色定义和能力边界，避免职责重叠导致冲突

• 实际案例：代码生成场景 → Planner Agent 拆需求 + Coder Agent 写代码 + Reviewer Agent 审查 + Executor Agent 运行测试

• 挑战：多 Agent 的成本控制（每个 Agent 都消耗 token）、一致性保证（多个 Agent 对同一事实的理解要一致）、死循环检测

---

二、RAG 全链路

6. 你做 RAG 的完整流程是什么？（数据 → 切分 → embedding → 向量库 → 检索 → 重排 → 生成）

参考答案：

• 数据采集与清洗：从 PDF/网页/数据库等多源提取文本，去噪、去重、格式统一

• 文档切分（Chunking）：按语义段落切分（优于固定长度），保留标题/元数据；常用 RecursiveCharacterTextSplitter，chunk 间加 overlap

• Embedding：用 text-embedding-3-small/BGE/M3E 等模型将 chunk 向量化，存入向量数据库（Milvus/Qdrant/FAISS）

• 检索（Retrieval）：用户 query embedding 后做 ANN 近似最近邻搜索，召回 top-K 相关 chunk

• 重排（Rerank）：用交叉编码器（如 bge-reranker、Cohere Rerank）对召回结果精排，显著提升相关性

• 生成（Generation）：将 rerank 后的 top-N chunk 作为 context 注入 prompt，LLM 据此生成答案

• 后处理：引用溯源（标注答案来自哪个 chunk/文档）、幻觉检测、格式化输出

7. Chunk 大小怎么确定？为什么？

参考答案：

• 没有万能值，需要根据文档类型和检索场景实验调优，通常 256-1024 token 是常见区间

• 太小（<128 token）：语义不完整，检索到也没用；太大（>2000 token）：噪声多，embedding 质量下降，检索精度降低

• 经验值：FAQ/知识库 → 256-512 token；技术文档/法律合同 → 512-1024 token；长篇叙述 → 按段落/章节切

• Overlap 很重要：通常设 10-20% 的重叠，避免关键信息被切断

• 进阶方案：语义切分（按段落/主题边界切，而非固定长度）、多粒度索引（同时建粗粒度和细粒度索引）

• 评估方法：用标注好的 QA 对，比较不同 chunk 大小下的 Recall@K 和最终回答质量

8. 向量召回不准怎么办？

参考答案：

• Query 改写/扩展：用 LLM 将用户原始 query 改写为多个变体，或做 HyDE（生成假设性答案再检索）

• 多路召回融合：向量检索 + BM25 关键词检索 + 知识图谱检索，结果做 RRF（Reciprocal Rank Fusion）合并

• 优化 Embedding 模型：换更强的模型（如 BGE-large、GTE）；或在领域数据上 fine-tune embedding 模型

• 优化切分策略：检查是否因为 chunk 切分不当导致语义破碎，调整 chunk 大小和 overlap

• 添加元数据过滤：利用文档标题、分类、时间等元数据做 pre-filter，缩小检索范围

• 引入 Rerank：向量粗召回 + 交叉编码器精排，效果提升通常很显著（10-30% MRR 提升）

9. 如何做 rerank？用什么模型？

参考答案：

• Rerank 是对向量粗召回的 top-K 结果做交叉编码器精排，将 query 和每个 candidate 拼接后打分

• 常用模型：Cohere Rerank API、bge-reranker-v2-m3（开源最强之一）、cross-encoder/ms-marco-MiniLM

• 工作原理：交叉编码器同时看 query 和 doc，能捕捉细粒度语义交互，远优于双塔模型的独立编码

• 实践要点：粗召回 50-100 个，rerank 后取 top 3-5 个喂给 LLM；rerank 增加 50-200ms 延迟，但值得

• 轻量替代：用 LLM 本身做 rerank（把候选列表给 LLM 让它排序），效果好但成本高，适合离线场景

• 还可以做 多阶段 rerank：向量召回 → 轻量 reranker → 重型 reranker，平衡效果与延迟

10. 如何评估 RAG 效果？指标是什么？

参考答案：

• 检索质量指标：Recall@K（标注相关文档在 top-K 中的命中率）、MRR（平均倒数排名）、NDCG

• 生成质量指标：Faithfulness（答案是否忠于检索到的文档，不编造）、Answer Relevancy（答案是否回答了问题）、Correctness（答案正确性）

• 端到端指标：用户满意度、任务完成率、人工评分

• 自动化评估框架：RAGAS（Retrieval-Augmented Generation Assessment）、TruLens、DeepEval

• 评估数据集构建：从真实用户 query 中采样，人工标注 ground truth 答案和相关文档

• 关键：分段评估，分别看检索准不准、生成好不好，定位瓶颈在哪个环节

11. RAG 和微调怎么取舍？

参考答案：

• RAG 适合：知识频繁更新、需要引用溯源、数据量大但标注少、需要快速上线

• 微调适合：特定领域的语言风格/格式要求、任务模式固定（如分类/抽取）、需要内化领域知识减少推理延迟

• 组合方案最优：微调让模型学会领域"语感"和输出格式，RAG 提供实时知识——二者不矛盾

• 成本对比：RAG 主要成本在检索基础设施和 embedding 计算；微调成本在训练数据标注和 GPU 训练

• 决策框架：先上 RAG（快、灵活），效果不够再加微调；微调不能解决"模型不知道"的问题，RAG 可以

• 反模式：不要用微调来"记住"事实——事实会变，微调后很难更新

12. 多路召回怎么做？

参考答案：

• 核心思路：用不同检索方式互补盲区，每路召回一批候选，最后融合排序

• 常见组合：向量检索（语义匹配）+ BM25/ES（关键词匹配）+ 知识图谱（结构化关系查询）

• 融合策略：**RRF（Reciprocal Rank Fusion）**最简单有效，按排名倒数加权合并；或学一个融合模型做 learned fusion

• 实现方式：各路检索独立并行执行，结果汇总后统一 rerank

• 示例场景："华为 Mate 60 电池容量"——向量检索可能召回相关但不精确的段落，BM25 能精确匹配"Mate 60"+"电池容量"关键词

• 工程注意：各路召回量要平衡（如向量 top-50 + BM25 top-30），避免某一路完全主导结果

13. 如何降低 RAG 的延迟？

参考答案：

• Embedding 缓存：对高频 query 缓存 embedding 结果，避免重复计算

• 向量索引优化：用 HNSW/IVF-PQ 等近似索引替代暴力搜索；合理设置 nprobe/ef_search 平衡精度与速度

• 异步并行：检索和 rerank 与 LLM 预热并行执行；多路召回并行请求

• Streaming 输出：LLM 用流式返回，用户无需等全部生成完，体感延迟大幅降低

• 缩减 context 长度：rerank 后只取 top-3 而非 top-10，减少 LLM 输入 token 数

• 模型选择：embedding 用轻量模型（如 text-embedding-3-small）；rerank 用蒸馏后的小模型；生成用速度快的模型（如 GPT-4o-mini）

• 预计算：对文档库中的高频问题预生成答案，命中时直接返回

---

三、LLM 工程问题

14. 如何解决幻觉问题？

参考答案：

• RAG 兜底：所有事实性回答都基于检索到的文档，prompt 中明确要求"仅基于提供的上下文回答"

• 引用溯源：要求模型输出时标注信息来源（[1][2]），便于用户验证，也约束模型不编造

• 自我一致性检查：同一问题多次采样，取一致性最高的答案（Self-Consistency）

• 后处理校验：用另一个 LLM 或规则引擎检查答案是否与 context 矛盾；对关键字段做事实核查

• Prompt 约束：加入"如果你不确定，请说不知道"、"不要编造信息"等指令

• 结构化输出：用 JSON Schema 约束输出格式，减少自由发挥空间

15. 如何降低模型幻觉？

参考答案：

• 与上题有重叠，但侧重系统层面的策略：

• 温度调低：temperature 设 0-0.3，减少随机性

• 知识注入：通过 RAG 或 System Prompt 注入准确信息，减少模型依赖自身参数记忆

• Fine-tune on domain data：让模型学会在特定领域的正确表达模式

• Chain-of-Thought：要求分步推理，中间步骤暴露后更容易发现逻辑错误

• Grounding：将关键实体链接到知识库，生成前先查证

• 拒绝回答机制：训练或 prompt 让模型在低置信度时主动拒答，而非硬编一个答案

16. 如何让模型输出稳定格式？

参考答案：

• JSON Mode / Structured Output：OpenAI 支持 response_format: { type: "json_object" }，强制输出合法 JSON

• Function Calling：通过定义函数参数的 JSON Schema，模型输出自动符合 schema

• Few-shot 示例：在 prompt 中给 2-3 个完整的输入→输出示例，模型会模仿格式

• Pydantic / Instructor 库：自动重试 + 校验，输出不合规时带着错误信息让模型修正

• 后处理正则兜底：对 LLM 输出做正则提取/修复（如补全缺失的括号、去除 markdown 代码块标记）

• 减少 temperature：降低随机性，格式一致性更好

• 明确的格式指令：prompt 中详细说明输出格式要求，用模板框住

17. 如何做自动化 Prompt 优化（A/B test / eval）？

参考答案：

• 构建评测数据集：收集真实用户 query + 标注的理想答案（golden dataset），至少 50-100 条覆盖各场景

• A/B 测试框架：同时运行两版 prompt，按流量比例分流，对比关键指标（准确率/用户满意度/任务完成率）

• 自动评估：用 LLM-as-Judge（GPT-4 评分）、RAGAS 指标、或领域特定的自动评分器

• DSPy / PromptFlow：用编程方式定义 prompt pipeline，自动搜索最优 prompt 组合

• 版本管理：每个 prompt 版本有唯一 ID，关联到评测结果，可追溯回滚

• 持续迭代：上线后持续收集 bad case，补充到评测集，驱动下一轮 prompt 优化

• 注意：不要只看平均分，要关注尾部 case（worst 10%），那些才是用户真正会投诉的

---

四、系统设计

18. 如果一个 Agent 系统 QPS 很高，你怎么设计架构？

参考答案：

• 异步任务队列：用 Kafka/RabbitMQ 解耦请求接收与 Agent 执行，削峰填谷

• Agent 无状态化：状态存 Redis/DB，Agent Worker 可水平扩容

• LLM 调用池化：维护 API Key 池或自部署模型的多实例负载均衡，避免单点限流

• 分级处理：简单查询走规则/缓存直接返回，复杂任务才走完整 Agent 链路

• 限流与排队：按用户/租户做 rate limiting，超限排队而非拒绝

• 预计算热点：高频问题（如"退货政策"）预生成答案缓存，命中率高的可省掉 LLM 调用

19. 向量检索很慢怎么办？

参考答案：

• 索引类型选择：HNSW（内存型，延迟低）适合百万级；IVF-PQ（量化压缩）适合千万-亿级

• 缩小搜索范围：先用元数据（类目/时间/租户）做 pre-filter，再在子集中做向量搜索

• 分片 + 并行查询：数据分片到多个节点，并行查询后合并结果

• 降维：用 PCA 或 Matryoshka Embedding 将 1536 维降到 256-512 维，搜索速度成倍提升

• GPU 加速：用 FAISS-GPU 或 Milvus GPU 索引，适合大批量请求

• 结果缓存：高频 query 的检索结果缓存（TTL 可设较长，知识库不常变）

20. LLM 调用很慢怎么办？

参考答案：

• Streaming 输出：首 token 延迟通常 200-500ms，流式返回让用户感知更快

• 模型降级：非关键场景用小模型（GPT-4o-mini/Qwen-7B），关键场景用大模型

• Prompt 精简：减少 system prompt 和 context 长度，token 少 = 生成快

• 并行调用：多个独立的 LLM 请求并行发出（如同时生成摘要和分类）

• 缓存：对相同输入缓存 LLM 输出（Semantic Cache —— 语义相似的 query 也命中缓存）

• 自部署推理优化：vLLM/TGI + continuous batching + KV cache + 量化（AWQ/GPTQ），吞吐量提升 3-10x

• 预生成：可预判的请求提前生成并缓存

21. 如何做缓存？

参考答案：

• 多层缓存架构：L1 本地内存缓存（热点数据）→ L2 Redis 分布式缓存 → L3 持久化存储

• 缓存什么：Embedding 结果、向量检索结果、LLM 完整回复、Rerank 结果

• Semantic Cache：不只精确匹配 query，用 embedding 相似度判断——语义接近的 query 复用缓存答案（GPTCache）

• 缓存策略：TTL 根据数据更新频率设定（知识库不常变→长 TTL；实时数据→短 TTL 或不缓存）

• 缓存失效：知识库更新时主动清除相关缓存；用 version tag 标记数据版本

• 注意：带个性化因素的请求（用户画像不同→答案不同）需要把用户特征也纳入缓存 key

22. 如何做降级？

参考答案：

• LLM 降级链：GPT-4o 超时/限流 → 降级到 GPT-4o-mini → 降级到本地小模型 → 降级到规则引擎/模板回复

• RAG 降级：向量检索超时 → 降级到 BM25 关键词检索 → 降级到热门 FAQ 匹配

• 功能降级：复杂 Agent（多步推理）降级为单轮问答；个性化推荐降级为热门推荐

• 熔断器模式：用 Circuit Breaker（如 Hystrix 思路），连续失败 N 次自动熔断，一段时间后半开试探

• 用户提示：降级时要告知用户"当前服务繁忙，为您提供简化回答"，管理预期

• 预案演练：提前定义好各级降级策略并做压测验证，不要等线上出问题才临时想

23. 如何控制成本？（LLM 很贵）

参考答案：

• 模型分级调用：简单任务用便宜小模型，只对复杂任务调用大模型（Router 模型自动分流）

• 缓存复用：Semantic Cache 命中率高时可省 50%+ 的 LLM 调用

• Prompt 压缩：去掉冗余的 context、用 LLMLingua 等工具压缩 prompt、减少 few-shot 示例数量

• 批处理：非实时场景攒批调用，利用 Batch API（OpenAI Batch API 半价）

• Token 预算控制：每次请求设 max_tokens 上限；每用户/每天设 token 消耗配额

• 自部署模型：高 QPS 场景自建推理服务（vLLM + 开源模型），长期成本远低于 API

• 监控与告警：实时监控 token 消耗和费用，异常飙升时自动告警并限流

24. 如何设计一个高并发的 RAG 系统架构？

参考答案：

• 整体架构：API Gateway → 请求队列 → RAG Worker 集群 → 向量数据库集群 + LLM 服务池

• 检索层：向量数据库（Milvus/Qdrant）多副本部署 + 读写分离；ES 集群做 BM25 检索；结果缓存 Redis

• 计算层：Embedding 服务独立部署，GPU 推理 + 动态扩缩容；Rerank 服务独立部署

• 生成层：LLM 调用走负载均衡（多 API Key 或多推理实例），支持降级链

• 数据层：文档入库走异步 Pipeline（上传 → 解析 → Chunk → Embed → 入库），不影响在线服务

• 弹性伸缩：基于 QPS/延迟指标做 HPA（K8s 水平自动扩缩），峰谷差异大时效果显著

• 可观测性：全链路 Tracing（每个请求的检索耗时、rerank 耗时、LLM 耗时一目了然），便于定位瓶颈

---

五、业务场景设计（电商方向）

25. 做一个类似 TikTok Shop / 淘宝的 AI 导购助手，怎么设计？

参考答案：

• 架构：用户输入 → 意图识别（闲聊/商品咨询/下单/售后）→ 路由到对应子 Agent → 调用 Tool → 生成回复

• 核心能力：自然语言商品搜索、多轮对话澄清需求、个性化推荐、比价、下单引导、售后处理

• 对话管理：维护对话状态机（浏览→意向→决策→下单→售后），不同阶段用不同策略

• 知识基础：商品库 RAG + 用户画像 + 实时库存/价格 API + 平台规则知识库

• 个性化：根据用户历史行为（浏览/购买/收藏）调整推荐策略和话术风格

• 安全与合规：不能虚假宣传、价格要实时准确、敏感商品需合规审查

26. 电商 Agent 里需要哪些 Tool？

参考答案：

• 商品搜索 Tool：接收自然语言查询，调用商品搜索 API（关键词+向量混合检索）

• 商品详情 Tool：根据商品 ID 获取详情（价格/规格/库存/评价摘要）

• 购物车/下单 Tool：添加购物车、创建订单（需人工确认环节）

• 订单查询 Tool：查询订单状态、物流信息

• 用户画像 Tool：获取用户偏好/历史购买/浏览记录

• 优惠券/促销 Tool：查询可用优惠、计算到手价

• 售后 Tool：发起退换货、查询售后进度

• 推荐 Tool：基于当前对话上下文调用推荐引擎获取个性化推荐

27. 电商 Agent 的 Memory 应该存什么？

参考答案：

• 会话级（短期）：当前对话中提到的需求偏好（"要红色的""预算500以内"）、已推荐过的商品（避免重复）、对话阶段状态

• 用户级（长期）：尺码偏好、品牌偏好、价格敏感度、购买周期（如每月买猫粮）、过往投诉与满意点

• 场景上下文：当前浏览的商品页、来源渠道（直播间/搜索/推荐位）、时间上下文（节日/大促期间话术调整）

• 存储方案：短期用 Redis Hash（session_id → 状态）；长期用户画像存关系型 DB + 向量库（用于相似用户匹配）

• 隐私注意：用户数据脱敏存储，遵守数据保护法规，提供数据删除能力

28. 做一个"自动运营 Agent"（自动生成活动、改价、发券），怎么设计？

参考答案：

• 架构：数据感知层（监控销量/库存/竞品价格）→ 策略决策层（LLM 分析 + 规则引擎）→ 执行层（调用运营 API）→ 效果反馈层

• 核心 Tool：价格调整 API、优惠券创建/分发 API、活动页生成工具、数据看板查询 API

• 安全机制：必须有人工审批环节——改价/发券属于高风险操作，Agent 只生成方案，人工确认后执行

• 策略引擎：基于历史数据训练价格弹性模型；设置改价上下限（如降幅不超过 30%）；大促节奏自动编排

• 反馈闭环：执行后持续监控效果（转化率/GMV/ROI），自动生成复盘报告，优化下次策略

• 防护栏：预算硬上限、单日操作次数限制、异常检测（如短时间内大量发券触发告警）

29. 电商商品库做 RAG，embedding 用什么字段？

参考答案：

• 核心字段：商品标题 + 商品描述/卖点 + 类目路径 + 关键属性（品牌/材质/适用人群）

• 拼接策略：将多个字段拼成一段结构化文本再 embedding，如："【标题】xxx【类目】xxx【卖点】xxx【规格】xxx"

• 不建议 embedding 的：纯数字字段（价格/库存）→ 用结构化过滤更合适；SKU 编码等无语义内容

• 富文本处理：商品详情中的图片描述/评价摘要也可以纳入，提升语义覆盖

• 多向量方案：标题单独一个 embedding（用于短查询匹配）+ 详情一个 embedding（用于长查询匹配），检索时分别召回再融合

• 元数据索引：价格区间、品牌、类目等作为 filter 字段，配合向量检索做 hybrid search

30. 用户问"适合送男朋友的礼物"，RAG 怎么做？

参考答案：

• 这是一个模糊意图 query，直接向量检索效果差，需要多步处理：

• Query 理解与扩展：用 LLM 将模糊 query 展开为多个具体 query（"男士手表推荐""男生数码好物""男朋友生日礼物清单"）

• 多路召回：向量检索（语义匹配"礼物""男生"）+ 类目检索（男装/数码/运动/护肤）+ 标签检索（标记为"礼物""男士"的商品）

• 用户画像加权：如果知道男朋友的年龄/兴趣，做个性化过滤和排序

• 场景化 Rerank：用 LLM 对召回结果做"送礼适合度"重排，考虑价格档次、包装、实用性等维度

• 结果组织：按场景/价位分组呈现（"200以内实用好物""500+轻奢礼物""数码控最爱"）

• 补充交互：Agent 可以反问澄清——"他平时喜欢运动还是数码？预算大概多少？"

31. 如何把"推荐系统"和"RAG"结合？

参考答案：

• 定位互补：推荐系统擅长"猜你喜欢"（基于行为协同过滤），RAG 擅长"你问我答"（基于语义检索）

• 融合架构：用户 query → RAG 检索相关商品 + 推荐引擎返回个性化推荐 → 结果融合排序 → LLM 生成自然语言推荐理由

• 推荐作为 RAG 的 pre-filter：先用推荐模型缩小候选集（与用户兴趣匹配的 top-1000），再在候选集内做向量检索

• RAG 增强推荐解释：推荐系统给出商品，RAG 检索相关评价/卖点，LLM 生成"为什么推荐这个给你"的解释文案

• 特征共享：用户的对话意图（RAG 侧提取）可以作为推荐系统的实时特征输入

• 冷启动解决：新用户没有行为数据时，通过对话（RAG）快速收集偏好，弥补推荐系统冷启动问题

32. 如何做个性化 RAG？

参考答案：

• 用户画像注入：将用户画像（偏好/历史/标签）作为额外 context 注入 prompt，引导 LLM 生成个性化回答

• 检索个性化：query embedding 时融入用户向量（如 query_vec + α * user_vec），让检索结果偏向用户兴趣

• Rerank 个性化：在 rerank 阶段加入用户特征，同样的 query 不同用户看到不同排序

• 知识库分层：全局知识库（所有用户共享）+ 用户私有知识库（个人收藏/历史对话/个人笔记）

• 动态 prompt 适配：根据用户身份/等级调整语气和推荐策略（如新客 vs VIP 客户）

• 隐私保护：个性化数据需加密存储，遵循最小必要原则，用户可控制和删除个人数据

33. 设计一个电商 AI 导购 Agent，支持：商品推荐、对话购物、查询订单、售后问题、个性化推荐、高并发

参考答案：

• 整体架构：API Gateway（限流/鉴权）→ Intent Router（意图分类）→ 子 Agent 集群 → Tool 层 → 数据层

• 意图路由：轻量分类模型（或 LLM）识别意图后路由——商品咨询→导购 Agent；订单查询→订单 Agent；售后→售后 Agent；闲聊→通用 Agent

• 导购 Agent：商品 RAG（多路召回+rerank）+ 推荐引擎融合 + 用户画像个性化 + 多轮对话澄清

• 订单/售后 Agent：主要是结构化查询 + 规则引擎（退货政策/退款流程），LLM 负责自然语言交互

• 高并发设计：

  • 无状态 Agent Worker + K8s HPA 弹性扩缩
  • 多层缓存（Semantic Cache + Redis + 本地缓存）
  • LLM 调用池化 + 降级链（大模型→小模型→模板回复）
  • 向量库多副本 + 读写分离
  • 异步消息队列削峰

• 个性化：短期 session memory（当前对话偏好）+ 长期 user profile（历史行为画像），两层记忆融合

• 监控与安全：全链路 Tracing、token 消耗监控、敏感词过滤、价格一致性校验、人工兜底通道（转人工客服）

---

🔗 原始链接

• https://www.nowcoder.com/feed/main/detail/e810608338be4eb9bff23db1b7ed2472