一、简历项目深挖（智能客服 RAG 系统）

1. 请详细介绍一下你做的这个企业级智能客服系统的整体架构，以及你在其中负责的核心模块 答题要点 整体流程：用户提问 → 上下文管理 → 意图识别 / Query 改写 → 向量召回（RAG 检索） → Prompt 拼接 → LLM 生成 → 后处理 / 安全过滤 → 回复用户 明确自己负责的模块：比如 RAG 知识库搭建、检索优化、Prompt 工程、多轮对话管理、接口开发 / 部署运维等。
2. 你在项目中是怎么处理业务文档的？比如 PDF、Word 这些不同格式的文档，是怎么清洗、切片和结构化的？ 答题要点 文档解析：不同格式的处理方式（如 PDF 用 PyPDF2/Plumber，Word 用 python-docx，扫描件可能用到 OCR） 清洗：去重、去格式噪音、去除无关信息（页眉页脚、广告、乱码） 切片分块：固定大小 / 滑动窗口 / 语义分块，分块大小的选择依据（比如 512/1024 token，结合业务场景和模型上下文限制） 结构化：提取关键信息、构建元数据（文档 ID、章节、业务分类、更新时间），方便后续过滤和检索。
3. 项目中你是怎么优化 RAG 检索效果的？遇到过哪些召回不准的问题，是怎么解决的？ 答题要点 优化手段：Query 改写 / 扩展、Hybrid 检索（向量 + 关键词 / 全文检索）、多级召回（粗召回 + 精排）、重排模型（如 BGE、Cohere Rerank）、元数据过滤、向量库索引优化。 典型问题：召回无关文档、长文本召回不全、专业术语匹配差、歧义问题；对应解决方法（如同义词扩展、行业词向量微调、多轮 Query 理解）。
4. Prompt 工程在这个客服项目里你做了哪些优化？怎么保证模型回复贴合业务话术、不偏离企业规范？ 答题要点 系统提示词设计：角色定义、回复规则、格式要求、边界限制（比如 “不知道的问题不要编造，引导用户转人工”） Few-shot 示例：根据高频问题编写示例，对齐回复风格 输出约束：通过正则 / JSON Schema / 输出解析器，强制模型按指定格式输出，避免乱回复 安全与合规：敏感词过滤、内容审核、拒绝回答无关问题的策略。
5. 多轮对话场景下，你是怎么管理上下文的？遇到过上下文丢失、逻辑断裂的问题吗？怎么处理的？ 答题要点 上下文存储：用 Redis / 数据库维护会话 ID，存储对话历史 上下文窗口控制：滚动窗口、关键信息摘要、只保留最近 N 轮对话，避免超过模型上下文限制 上下文压缩：对历史对话做关键信息提取 / 摘要，减少 token 消耗 意图识别：结合上下文理解用户当前提问，判断是否需要关联历史对话信息。
6. 项目上线后，你是怎么监控系统运行状态的？遇到过哪些线上问题，怎么排查和优化的？ 答题要点 监控指标：响应时间、调用成功率、问答准确率、人工转接率、用户满意度、token 消耗 典型线上问题：响应超时、模型调用失败、回复 hallucination（幻觉）、高并发下服务卡顿 排查与优化：日志分析、链路追踪、接口异步化、服务扩容 / 限流、缓存优化、模型推理加速、知识库更新与迭代。 二、基础技术栈与理论题
7. RAG 的核心流程是什么？分别解决了大模型的哪些痛点？ 答题要点 流程：数据处理→向量化→向量存储→召回→Prompt 拼接→生成 解决的痛点：知识滞后、知识幻觉、无法使用私有数据、数据安全问题
8. 向量数据库（Milvus/FAISS/Chroma）在 RAG 中的作用是什么？它们之间有什么区别？ 答题要点 作用：存储向量、高效的相似性检索、支持大规模数据的快速召回 区别：FAISS 轻量、适合单机；Chroma 轻量易上手，适合开发；Milvus 分布式、适合大规模生产环境，支持多种索引和过滤
9. 大模型应用开发中，Prompt 工程有哪些常见技巧？什么情况下会用到 Few-shot、CoT（思维链）？ 答题要点 技巧：明确角色、指令清晰、格式约束、示例引导、思维链、反思 / 自检 Few-shot：适合固定格式 / 规则的任务，给模型参考示例 CoT：适合推理、问答、计算类任务，引导模型分步思考，减少错误
10. 你了解大模型微调吗？在什么场景下会选择微调，而不是只靠 RAG+Prompt？ 答题要点 场景：RAG 无法解决的风格统一、专业术语理解、复杂推理逻辑、特定格式输出、低资源场景 注意：微调成本高、数据要求高，优先优化 RAG 和 Prompt，再考虑微调
11. Python 中你常用哪些库做数据处理（Pandas/NumPy）？举个例子，你在项目中用它们做了什么数据清洗或数据集制作工作？ 答题要点 举例：用 Pandas 清洗业务 FAQ 数据，去重、补全、标准化；用 NumPy 处理向量数据，批量生成文档向量；用自定义脚本处理多格式文档，生成训练 / 微调数据集
12. 你用 FastAPI/Flask 开发过 AI 接口吗？请简单说一下一个完整的 AI 服务接口从开发到上线的流程，包括部署和调试。 答题要点 开发：定义接口、封装模型调用、异常处理、日志记录 调试：本地测试、单元测试、接口压测 部署：容器化（Docker）、服务编排、负载均衡、监控告警 运维：版本迭代、回滚机制、性能调优 三、工程落地与优化题
13. 如果你的智能客服系统在高峰期响应变慢，可能的原因有哪些？你会从哪些方面入手优化？ 答题要点 原因：模型推理耗时高、向量检索慢、并发请求高、网络 IO 瓶颈、数据库压力大 优化方向： 模型侧：模型量化、推理加速（vLLM/TGI）、异步调用、缓存高频问答 检索侧：向量库索引优化、预计算向量、分层召回、缓存热门向量 工程侧：服务扩容、负载均衡、接口异步化、限流降级
14. 怎么评估一个 RAG 系统的效果？你在项目中用到了哪些评估指标或方法？ 答题要点 检索层指标：召回率、准确率、MRR、NDCG 生成层指标：BLEU、ROUGE、人工评估（准确率、相关性、流畅度、幻觉率）、用户反馈（人工转接率、好评率） 评估方式：自动化评估脚本、人工标注、A/B 测试
15. 如果业务方反馈智能客服的回答经常出错，甚至编造信息，你会怎么排查和解决？ 答题要点 排查步骤：定位问题（是检索错了，还是模型生成错了）→ 检查召回文档是否相关 → 检查 Prompt 是否有约束 → 检查模型是否存在幻觉 解决方法：优化检索策略、加强 Prompt 约束、增加事实校验、设置 “不知道” 兜底、更新知识库数据、必要时微调模型
16. 多轮对话中，随着对话轮数增加，token 消耗会越来越高，你有哪些方法控制 token 成本？ 答题要点 上下文窗口管理：滚动窗口、只保留关键轮次对话 上下文压缩：对历史对话做摘要、关键信息提取 精简 Prompt：去除冗余信息、优化系统提示词 模型选择：在满足需求的前提下，选择更小的模型或更短的上下文版本 缓存优化：缓存高频问答、相似问题的回复，减少重复调用模型
17. 你在项目中怎么处理数据安全和隐私问题？比如用户对话数据、企业内部知识库数据，有哪些防护措施？ 答题要点 数据脱敏：用户敏感信息（手机号、身份证号）脱敏 权限控制：知识库按业务分类，设置访问权限 模型调用安全：敏感词过滤、禁止模型输出敏感信息 数据存储：加密存储对话数据，定期清理非必要数据 合规性：符合企业数据安全规范，避免数据泄露 四、场景与业务理解题
18. 你认为智能客服这类 LLM 应用落地，最大的难点是什么？你在项目中是怎么应对的？ 答题要点 难点：业务场景复杂多变、用户问题千奇百怪、知识库更新频繁、模型幻觉、效果评估难、成本控制 应对：从业务方高频问题入手，优先解决核心场景；建立知识库更新流程；设置多重校验和兜底机制；结合用户反馈持续迭代
19. 如果让你给一个传统企业搭建智能客服系统，你会怎么从 0 到 1 推进？第一步会做什么？ 答题要点 第一步：需求调研，明确业务场景、高频问题、用户痛点、核心指标（比如降低多少人工转接率） 整体流程：需求调研→数据梳理（现有 FAQ、业务文档）→方案设计（RAG+Prompt / 是否需要微调）→MVP 开发→测试评估→上线试点→迭代优化→全量推广
20. 对比纯规则引擎的客服和基于大模型的智能客服，你认为最大的区别是什么？大模型客服的优势和劣势分别是什么？ 答题要点 优势：理解自然语言、支持多轮对话、处理复杂问题、无需编写大量规则、可扩展性强 劣势：成本高、存在幻觉、效果依赖数据和 Prompt、响应时间不如规则引擎、效果不稳定
21. 如果业务方希望智能客服不仅能回答问题，还能帮用户办理业务（比如查询订单、修改信息），你会怎么设计这个流程？需要考虑哪些问题？ 答题要点 设计思路：意图识别→参数提取→调用业务接口→结果返回 考虑问题：参数校验、权限控制、接口安全、错误处理、用户确认机制、流程闭环（办理成功 / 失败的回复）