AI大模型原理和应用面试题（一）

1. 什么是 RAG？RAG 的主要流程是什么？

RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合 “外部知识检索” 与 “大模型生成” 的技术，核心是让大模型在生成回答前，先从海量外部文档中检索与查询相关的准确信息，再基于这些知识生成内容，以此解决大模型知识局限、过时或产生 “幻觉” 的问题。
主要流程：① 数据预处理阶段：将外部文档拆分（分块）后，通过 Embedding 模型转换为向量，存入向量数据库；② 检索阶段：用户输入查询，将查询转为向量，在向量数据库中匹配相似度最高的文档片段；③ 生成阶段：将检索到的相关片段与用户查询结合为提示词（Prompt），输入大模型生成精准回答。

2. 什么是 RAG 中的 Rerank？具体需要怎么做？

Rerank（重排序）是 RAG 检索阶段的优化环节，指在 “初步检索” 获取候选文档片段后，用更精细的语义模型对候选片段重新评估排序，筛选出更贴合查询需求的片段。初步检索（如向量检索）侧重 “快速召回大量候选”，Rerank 侧重 “精准提升结果相关性”。
具体步骤：① 初步检索：通过向量数据库（如 Pinecone、Milvus）召回 Top-N（通常 50-100 个）与查询相似的文档片段；② 选择 Rerank 模型：常用轻量级语义模型（如 BERT 微调模型、Cohere Rerank、Sentence-BERT），平衡精度与速度；③ 计算相关性分数：将用户查询与每个候选片段输入 Rerank 模型，模型输出两者的语义相关性分数；④ 筛选排序：按相关性分数从高到低排序，取 Top-K（通常 5-15 个）片段，作为最终检索结果传入大模型。

3.A2A 协议有哪五大设计原则？

A2A（Agent-to-Agent，智能体间通信）协议是规范不同 AI 智能体交互的标准，五大设计原则如下：
互操作性（Interoperability）：支持不同框架、厂商开发的智能体无缝通信，不绑定特定技术栈，确保跨平台、跨语言兼容；
模块化（Modularity）：将智能体功能拆分为独立模块（如检索模块、生成模块、工具调用模块），模块通过标准化接口交互，便于灵活组合与替换；
可扩展性（Scalability）：支持动态增减智能体节点，适配单智能体对话、多智能体协作等不同规模场景，且能扩展新的交互类型；
安全性（Security）：内置身份认证、数据加密、权限控制机制，防止数据泄露、篡改或未授权访问，保障交互可信度；
语义一致性（Semantic Consistency）：定义统一的语义描述规范（如 JSON-LD、RDF），确保不同智能体对交互内容的理解一致，避免歧义。

4. 什么是混合检索？在基于大模型的应用开发中，混合检索主要解决什么问题？

混合检索（Hybrid Retrieval）是结合 “向量检索” 与 “传统检索（关键词检索、结构化检索）” 的检索方式，通过多维度匹配逻辑提升结果的相关性与覆盖度。
主要解决的问题：① 弥补向量检索局限：向量检索依赖语义相似度，可能遗漏 “语义不相似但关键词匹配” 的关键文档（如查询 “苹果手机” 漏检含 “iPhone” 的文档）；② 弥补传统检索局限：关键词检索依赖精确字符匹配，无法理解语义（如查询 “电脑蓝屏修复” 无法匹配 “Windows 崩溃解决”）；③ 适配结构化信息：对含时间、地点、数值等结构化信息的文档（如 “2024 年电商销售额报告”），结构化检索（如 SQL 查询）可精准筛选，补充向量检索在结构化筛选上的不足；④ 提升检索鲁棒性：避免单一检索方式因数据质量（如文档语义模糊）或查询表述问题导致的检索失效。

5. 什么是 Google ADK？

Google ADK（Agent Development Kit，智能体开发工具包）是 Google 推出的一套用于快速开发、部署和管理 AI 智能体（Agent）的工具集，旨在降低智能体开发门槛，支持构建具备 “知识检索、任务规划、记忆管理、多工具调用” 能力的应用。核心功能包括：① 检索增强模块：提供向量数据库对接接口，快速接入外部知识文档；② 工具调用框架：标准化工具调用流程，支持智能体调用第三方 API、数据库、本地软件等；③ 对话记忆管理：支持短期对话记忆与长期知识记忆的存储、检索与更新；④ 部署与监控：支持一键部署到 Google Cloud 或本地环境，配套日志分析、性能监控工具；⑤ 大模型适配：兼容 Google Gemini 系列模型，也支持对接 OpenAI GPT、Anthropic Claude 等第三方大模型。主要用于企业级智能体开发（如客服智能体、研发辅助智能体、教育辅导智能体）。

6.RAG 的完整流程是怎么样的？

RAG 完整流程分为 “离线数据准备” 与 “在线查询生成” 两大阶段，共 8 个核心步骤：
文档收集：从本地文件（PDF、Word、Markdown）、数据库、网页、API 接口等来源，收集需用于增强的外部知识文档；
文档解析：提取文档中的文本内容 ——PDF 用 PyPDF2、pdfplumber 工具提文，图片类文档用 OCR（如 Tesseract）识别文字，HTML 用 BeautifulSoup 去标签留正文；
文档清洗：过滤页眉页脚、广告、重复段落等无关信息，对表格数据转为 “行标题：列内容” 的文本格式，确保内容简洁；
文档分块：将长文档拆分为短片段（分块大小通常 200-500 字符，或 100-300 Token），避免长文档 Embedding 时语义信息丢失；
向量生成（Embedding）：用 Embedding 模型（如 OpenAI text-embedding-3-small、Sentence-BERT）将每个分块转为固定维度向量；
向量存储：将向量与对应文档分块（含元数据如来源、页码、时间）存入向量数据库（如 Pinecone、Milvus、Chroma）；
在线检索：用户输入查询后，清洗查询文本（去特殊字符、修正拼写），转为查询向量；在向量数据库初步检索候选片段，再经 Rerank 模型筛选出 Top-K 相关片段；
生成回答：将筛选后的片段、用户查询、系统提示词（如 “基于以下知识回答，不编造信息”）组合为 Prompt，输入大模型生成回答并返回用户。

7.A2A 协议的工作原理是怎样的？

A2A 协议通过 “标准化消息格式” 与 “分布式交互流程” 实现智能体间的通信与协作，核心工作原理分 4 步：
智能体注册与发现：智能体启动后，向 “智能体注册中心” 注册自身信息（唯一 ID、功能类型、通信地址、支持的消息格式）；当智能体 A 需协作时，通过注册中心查询目标智能体 B 的地址与能力，确认是否支持所需交互；
消息构建与封装：智能体 A 按 A2A 协议规定的格式（通常为 JSON 或 Protobuf）构建消息，包含 “发送方 ID、接收方 ID、消息类型（请求 / 响应 / 通知）、内容体、时间戳、数字签名” 等字段，确保消息完整性与可追溯；
消息传输与路由：智能体 A 通过支持的传输方式（HTTP/HTTPS、WebSocket、MQTT）发送消息；若智能体 A 与 B 不在同一网络，由 “消息路由器” 根据接收方 ID 路由消息，确保准确送达；
消息解析与响应：智能体 B 接收消息后，验证数字签名与发送方身份，解析消息内容并执行对应任务（如检索知识、调用工具）；任务完成后，按协议格式构建响应消息返回给 A；若需多智能体协作，B 可进一步转发消息给其他智能体。

8. 在 RAG 应用中为了优化检索精度，其中的数据清洗和预处理怎么做？

RAG 中数据清洗与预处理的核心目标是 “提升文档质量，让分块、Embedding 更精准”，具体步骤如下：
文档格式统一：将不同格式的文档（PDF、Word、Markdown、HTML、图片）转为纯文本 ——PDF 用 pdfplumber 提取文本（保留段落结构），Word 用 python-docx 提文，HTML 用 BeautifulSoup 去除标签，图片用 Tesseract OCR 识别文字；
冗余信息过滤：删除页眉页脚、页码、版权声明、广告、重复段落等无关内容；对代码文档，保留注释与核心逻辑，去除冗余空格与换行；
文本标准化：统一文本格式（如英文小写转换、去除特殊字符 / 表情符号），进行拼写纠错（中文用 pycorrector，英文用 pyspellchecker），中文文档用 jieba 或 THULAC 分词（便于 Embedding 捕捉语义）；
结构化信息提取：对含 “参数 - 值”“时间 - 地点 - 事件” 的文档（如报告、表格），提取为结构化文本（如 “发布时间：2024 年 5 月；数据来源：行业白皮书”），或转为键值对存储，适配后续结构化检索；
质量校验：过滤空白文本、过短文本（通常少于 10 字符的片段直接丢弃），抽样检查预处理效果（如验证 OCR 识别准确率、冗余过滤完整性），根据结果调整预处理规则。

9.A2A 协议的工作流程是怎样的？

以 “多智能体协作完成‘生成行业报告’任务” 为例，A2A 协议的典型工作流程分 5 步：
任务发起：用户向 “主智能体”（如对话智能体）提交任务 “生成 2024 年新能源汽车行业销售报告”；主智能体分析任务，判断需调用 “检索智能体”（获取销售数据）与 “工具调用智能体”（生成图表）；
智能体发现：主智能体向 A2A 注册中心查询，获取 “检索智能体”（支持行业数据检索）与 “工具调用智能体”（支持图表生成工具调用）的通信地址与能力描述；
任务分配与通信：主智能体按 A2A 协议格式构建消息 —— 给检索智能体的消息含 “任务：检索 2024 年新能源汽车月度销量数据；数据来源：权威行业平台”；给工具智能体的消息含 “待处理数据类型：月度销量；目标：生成折线图”，并通过 HTTP 发送消息；
子任务执行：检索智能体接收消息后，从向量数据库与结构化数据库中获取数据，按协议格式返回给主智能体；工具智能体接收主智能体转发的数据后，调用图表工具生成 PNG 格式图表，返回文件地址；
结果汇总与反馈：主智能体整合销量数据与图表地址，调用 “生成智能体” 生成完整报告，返回给用户；同时记录交互日志（智能体调用顺序、耗时、结果状态），用于后续监控与优化。

10. 什么是查询扩展？为什么在 RAG 应用中需要查询扩展？

查询扩展（Query Expansion）是 RAG 检索阶段的优化技术，指在用户原始查询基础上，通过添加同义词、相关词、上下文补充信息或专业术语，生成更丰富的 “扩展查询”，提升检索结果的覆盖度与相关性。
需要查询扩展的原因：① 原始查询语义不完整：用户查询通常简洁（如 “蓝屏怎么办”），语义信息有限，易导致向量检索漏检相关文档（如含 “Windows 崩溃修复”“系统重启故障” 的文档）；② 解决查询歧义：查询存在多义性（如 “苹果” 指水果或电子品牌），通过添加上下文（如 “苹果手机最新型号”）缩小检索范围，避免无关结果；③ 适配领域术语差异：普通用户对专业领域查询（如 “大模型微调”）可能不用专业术语（如 “LoRA 微调”“RLHF 优化”），扩展查询添加术语可检索更精准的专业文档；④ 提升召回率：扩展后的查询包含更多相关语义，能召回原始查询未覆盖但实际相关的文档，减少关键信息遗漏。

11.A2A 协议与 MCP 协议的关系是怎样的？

A2A（Agent-to-Agent）协议与 MCP（Model Control Protocol，模型控制协议）均用于 AI 系统的交互与控制，但定位、场景不同，二者为 “互补关系”，具体如下：
核心定位差异：A2A 聚焦 “智能体间的宏观协作”，定义不同智能体（如检索智能体、生成智能体）的交互标准，解决 “多智能体如何分工协作” 的问题；MCP 聚焦 “模型与控制端的微观控制”，定义对大模型的精细化操作标准（如调整生成参数、中断生成、管理对话历史），解决 “如何精准控制单个模型” 的问题；
功能覆盖互补：复杂 AI 应用中，A2A 协调多智能体分工（如 “主智能体用 A2A 调用检索智能体”），MCP 控制智能体内部的模型（如 “检索智能体用 MCP 调整 Embedding 模型的输入长度、相似度阈值”）；
技术兼容性：二者无依赖关系，可独立或结合使用 —— 基于 A2A 构建多智能体系统时，各智能体内部可通过 MCP 对接不同大模型，实现 “智能体协作 + 模型精细化控制” 的双重能力；
场景区分：简单场景（单智能体调用单模型）仅需 MCP；复杂场景（多智能体协作完成复杂任务，如行业报告生成、多步骤客服响应）需 A2A 协调智能体，同时用 MCP 控制模型，共同保障系统运行效率与精度。

12. 什么是自查询？为什么在 RAG 中需要自查询？

自查询（Self-Querying）是 RAG 检索阶段的智能优化技术，指让大模型根据用户原始查询，自动拆解并生成 “结构化查询条件”（如过滤条件、排序规则），结合向量检索与结构化检索，实现更精准的结果筛选 —— 核心是 “系统自主理解查询中的结构化需求，而非仅依赖语义相似度匹配”。
需要自查询的原因：① 适配结构化需求：用户查询常含结构化条件（如 “2024 年发布的 AI 技术书籍”，含时间条件），仅向量检索无法精准筛选时间维度，自查询生成 “发布时间 >= 2024” 的条件，结合语义检索（AI 技术书籍）得到精准结果；② 减少无关结果：如查询 “北京朝阳区咖啡店地址”，自查询生成 “地区 = 北京朝阳区” 的条件，过滤其他地区文档，避免向量检索返回语义相关但地区不符的结果；③ 处理多条件复杂查询：对含多个约束条件的查询（如 “2024 年新款、价格低于 5000 元的笔记本电脑评测”），自查询拆解为 “发布时间 = 2024、价格 < 5000、语义 = 笔记本电脑评测” 多维度条件，实现 “语义 + 结构化” 联合检索，大幅提升结果相关性。

13. 什么是提示压缩？为什么在 RAG 中需要提示压缩？

提示压缩（Prompt Compression）是 RAG 生成阶段的优化技术，指将 “检索到的文档片段 + 用户查询” 组合为 Prompt 前，通过删除冗余信息、提炼核心内容、简化表述等方式，缩小 Prompt 的 Token 长度，确保不超过大模型的上下文窗口限制。
需要提示压缩的原因：① 突破上下文窗口限制：大模型有固定的上下文长度（如 GPT-4 基础版 8K Token、GPT-3.5 4K Token），若检索片段过长（如 Top 10 分块共 10K Token），直接组合会超出限制，导致大模型无法处理；② 提升生成效率：过长 Prompt 会增加大模型的处理时间与计算成本，压缩后减少 Token 消耗，加快回答生成速度；③ 聚焦核心信息：检索片段可能含重复描述、背景铺垫等冗余内容，压缩可提炼 “结论 + 关键论据”，避免大模型被无关信息干扰，提升回答的精准度；④ 支持多轮对话：多轮 RAG 对话中，历史对话内容 + 新检索片段易累积过长，压缩可释放上下文空间，支持更长的对话轮次。

14. 如何进行 RAG 调优后的效果评估？请给出真实应用场景中采用的效果评估标准与方法

RAG 调优效果评估从 “检索精度”“生成质量”“用户体验”“业务指标” 四个维度展开，真实应用场景常用标准与方法如下：
检索精度评估：① 评估标准：召回率（Recall，检索到的相关片段占所有相关片段的比例）、精确率（Precision，检索到的片段中相关片段的比例）、F1 分数（召回率与精确率的调和平均）、NDCG（归一化折扣累积增益，评估结果排序合理性）；② 评估方法：人工标注测试集（含 50-100 个查询及对应相关文档），计算 RAG 检索结果的召回率、精确率、F1 分数；用 NDCG@K（K 取 5/10）评估相关片段的排名情况，例如在客服场景中，测试 “如何办理退款” 查询，需确保检索到的 “退款流程”“退款条件” 片段均被召回且排名靠前。
生成质量评估：① 评估标准：事实准确性（回答是否与检索片段一致，无幻觉）、相关性（回答是否匹配用户查询需求）、完整性（是否覆盖查询所需的关键信息）、简洁性（无冗余表述）；② 评估方法：人工打分（邀请 3-5 名标注员按 1-5 分对生成回答评分，取平均值）；自动评估工具辅助（如用 LlamaIndex 的 ResponseEvaluator 检测回答与检索片段的一致性，用 BERTScore 计算回答与查询的语义相似度），例如在医疗知识问答场景中，需确保生成的 “疾病治疗建议” 完全匹配检索到的权威医学文档，无虚构治疗方案。
用户体验评估：① 评估标准：平均响应时间（从用户提交查询到收到回答的耗时）、交互轮次（用户获取满意答案所需的查询次数）、用户满意度（用户对回答的认可程度）；② 评估方法：埋点统计线上用户的平均响应时间（目标通常 <3 秒）；分析用户会话日志，统计交互轮次（目标通常 ≤ 2 轮）；通过产品内问卷（如 “是否解决您的问题？”）收集用户满意度（目标通常 ≥ 85%），例如在电商智能导购场景中，需确保用户平均 1-2 轮查询即可获取商品推荐、优惠信息等所需内容。
业务指标评估：① 评估标准：核心业务转化率（如客服场景中 “查询后成功解决问题的比例”、电商场景中 “查询后下单转化率”）、人工介入率（需人工处理的查询占比）、重复查询率（用户重复提交相同查询的比例）；② 评估方法：对接业务数据库，统计调优前后的核心业务指标变化，例如客服场景中，RAG 调优后人工介入率从 30% 降至 15%，即说明调优有效；电商场景中，商品查询后的下单转化率提升 5%，则符合业务预期。

15. 什么是 RAG 中的分块？为什么需要分块？

RAG 中的分块（Chunking）是指将原始长文档（如几十页的 PDF、万字文章）拆分为短文本片段（通常 100-500 Token，或 200-1000 字符）的预处理步骤，每个分块包含完整的局部语义（如一个段落、一个章节的子主题），并关联原始文档的元数据（如来源、页码、标题）。
需要分块的核心原因：① 适配 Embedding 模型限制：多数 Embedding 模型有输入长度限制（如 OpenAI text-embedding-3-small 支持最大 8191 Token），长文档直接 Embedding 会被截断，丢失尾部信息；分块后每个片段均在模型输入范围内，能完整保留局部语义；② 提升检索精度：长文档包含多主题信息（如一篇 “AI 技术报告” 含 “发展历程”“核心算法”“应用场景”），若整体 Embedding，向量会混合多主题语义，导致检索时无法精准匹配单一主题查询（如查询 “AI 核心算法” 可能召回含 “应用场景” 的长文档，相关性低）；分块后每个片段聚焦单一子主题，检索时能精准匹配查询语义；③ 优化生成效率：大模型上下文窗口有限，若传入长文档，会占用大量 Token 空间，导致可输入的查询与提示词受限；分块后仅需传入与查询相关的少数片段，节省 Token 消耗，同时让大模型聚焦核心信息生成回答，减少无关内容干扰。

16. 在 RAG 中，常见的分块策略有哪些？分别有什么区别？

RAG 中常见的分块策略按 “拆分逻辑” 可分为 5 类，核心区别在于拆分依据、适用场景与语义完整性：
固定长度分块（Fixed-Size Chunking）：① 逻辑：按固定字符 / Token 长度拆分（如每 300 Token 一个分块），拆分时不考虑文档结构；② 优点：实现简单，无依赖文档格式；③ 缺点：易拆分到句子 / 段落中间，破坏语义完整性（如将 “小明今天去公园，他看到一只小狗” 拆分为 “小明今天去公园” 和 “他看到一只小狗”，两个分块均语义不完整）；④ 适用场景：无明显结构的纯文本（如日志文件、聊天记录）。
语义分块（Semantic Chunking）：① 逻辑：基于文本语义关联性拆分，用 NLP 工具（如 spaCy、NLTK）识别句子边界、段落边界或主题变化，确保每个分块是完整的语义单元（如一个完整段落、一个完整主题）；② 优点：语义完整性高，检索时能精准匹配查询；③ 缺点：依赖 NLP 工具对语义的识别精度，复杂句式（如长复合句）可能拆分不精准；④ 适用场景：结构化文档（如文章、报告、论文），需保留完整段落或主题语义。
结构感知分块（Structure-Aware Chunking）：① 逻辑：结合文档格式结构拆分，如 PDF 的章节标题、页眉页脚、表格、图片说明，按 “章节 - 子章节 - 段落” 层级拆分，表格转为 “表格标题 + 行数据 + 列说明” 的文本块；② 优点：保留文档原生结构，分块与实际阅读逻辑一致，元数据丰富（如 “第 3 章 核心算法 - 3.1 深度学习”）；③ 缺点：依赖文档格式解析工具（如 pdfplumber、python-docx），非结构化文档（如扫描件 PDF）无法适用；④ 适用场景：有明确格式的文档（如带章节的报告、含表格的论文、Word 文档）。
滑动窗口分块（Sliding Window Chunking）：① 逻辑：在固定长度分块基础上，设置重叠区域（如分块长度 300 Token，重叠 50 Token），例如第 1 分块（1-300 Token）、第 2 分块（251-550 Token）；② 优点：避免固定长度分块的语义断裂，重叠部分确保相邻分块的语义连贯性；③ 缺点：增加分块数量，占用更多向量数据库存储空间；④ 适用场景：长句子、连续叙述类文档（如故事、小说、连续实验记录），需保留句子间逻辑关联。
查询驱动分块（Query-Driven Chunking）：① 逻辑：先分析用户查询的主题与关键词，再针对查询动态拆分文档中与主题相关的片段，而非提前离线分块；② 优点：分块与查询高度匹配，检索精度极高；③ 缺点：需实时分析查询与文档，响应时间长，不适合高并发场景；④ 适用场景：低并发、对检索精度要求极高的场景（如学术研究、法律文档检索）。

17. 在 RAG 中的 Embedding 嵌入是什么？

RAG 中的 Embedding（嵌入）是指将文本（如用户查询、文档分块）通过专门的 Embedding 模型，转换为低维度、稠密的数值向量（如 768 维、1536 维）的过程，这些向量能在数学空间中 “语义相似的文本距离更近，语义无关的文本距离更远”，是实现 RAG 检索的核心技术。核心特点：① 语义映射：文本的语义信息被编码为向量的数值特征，例如 “猫” 和 “猫咪” 的向量距离极近，“猫” 和 “汽车” 的向量距离极远；② 低维度：原始文本按字符 / Token 拆分后维度极高（如 100 字符的文本维度可能达数千），Embedding 后压缩为固定低维度（如 OpenAI 模型输出 1536 维），便于存储与计算；③ 距离可计算：通过余弦相似度、欧氏距离等算法，可快速计算两个向量的相似度，从而判断对应文本的语义相关性 —— 这是 RAG 中 “用查询向量匹配文档向量” 的核心逻辑。在 RAG 中的作用：① 文档向量化：将离线分块后的文档片段转为向量，存入向量数据库；② 查询向量化：用户提交查询后，将查询转为向量；③ 相似度匹配：在向量数据库中，通过计算查询向量与文档向量的相似度，快速召回语义相关的文档片段，为后续生成回答提供知识支撑。

18. 在 RAG 中，你知道有哪些 Embedding Model 嵌入模型？

RAG 中常用的 Embedding 模型按 “开源 / 闭源” 可分为两类，覆盖不同部署场景与精度需求：
闭源 Embedding 模型（需 API 调用，无开源权重）：① OpenAI 系列：text-embedding-3-small（1536 维，轻量高效，适合高并发场景）、text-embedding-3-large（3072 维，精度更高，适合对检索精度要求高的场景）、text-embedding-ada-002（1536 维，性价比高，是早期常用模型）；② Google 系列：Gemini Embedding（支持多模态输入，文本向量维度 768/1536 维，适配 Google Cloud 生态）；③ Anthropic 系列：Claude Embedding（与 Claude 大模型兼容性好，向量维度 1536 维，适合用 Claude 生成回答的 RAG 场景）；④ 国内厂商系列：百度文心一言 Embedding（ERNIE Embedding，支持中文语义优化，适配百度云）、阿里通义千问 Embedding（Qwen Embedding，中文处理精度高，适合国内业务场景）。
开源 Embedding 模型（可本地部署，有公开权重）：① Sentence-BERT（SBERT）系列：all-MiniLM-L6-v2（384 维，轻量快速，适合本地低资源部署）、all-mpnet-base-v2（768 维，精度高于 MiniLM，是开源场景的主流选择），支持多语言，可通过 Hugging Face 下载权重；② BERT 微调模型：bert-base-uncased（12 层，768 维，需自行微调适配特定领域）、chinese-bert-wwm-ext（中文优化版 BERT，适合中文文档检索）；③ 其他开源模型：E5（Microsoft 推出，如 e5-small-v2，384 维，支持 “查询 - 文档” 语义匹配优化）、GTE（阿里巴巴推出，如 gte-small，384 维，中文处理效果优异，适合国内开源场景）。

19. 在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

在 RAG 中选择 Embedding 模型需从 “业务需求、技术限制、成本预算” 三个维度综合评估，核心考虑因素如下：
语义匹配精度需求：① 高精度场景（如医疗、法律、学术检索）：优先选择高维度、大参数量模型，如闭源的 OpenAI text-embedding-3-large、Google Gemini Embedding，或开源的 Sentence-BERT all-mpnet-base-v2，确保能捕捉专业领域的细粒度语义差异；② 一般精度场景（如客服、电商导购）：选择轻量模型，如 OpenAI text-embedding-3-small、开源的 Sentence-BERT all-MiniLM-L6-v2，平衡精度与效率。
语言与领域适配性：① 中文场景：优先选择中文优化模型，如闭源的百度 ERNIE Embedding、阿里 Qwen Embedding，或开源的 chinese-bert-wwm-ext、GTE-small，避免通用模型对中文语义理解不足的问题；② 特定领域（如金融、医疗）：优先选择领域微调模型，如医疗领域的 BioBERT Embedding、金融领域的 FinBERT Embedding，或对通用模型用领域数据微调后使用，提升领域术语的语义匹配度。
部署与性能限制：① 在线高并发场景：若需低延迟（如响应时间 < 100ms），优先选择闭源 API 模型（如 OpenAI、百度），或本地部署轻量开源模型（如 all-MiniLM-L6-v2），避免大模型本地推理耗时过长；② 离线 / 私有化部署场景：必须选择开源模型（如 Sentence-BERT 系列、GTE），确保数据不对外传输，同时需评估服务器硬件资源（如 GPU 显存，轻量模型 4GB 显存可运行，大模型需 16GB+ 显存）。
成本预算：① 低成本场景：选择开源模型本地部署（无 API 调用费用），或闭源的高性价比模型（如 OpenAI text-embedding-3-small，按 Token 计费，100 万 Token 费用约 0.1 美元）；② 高预算场景：若精度优先，可选择闭源高精度模型（如 text-embedding-3-large），或对开源模型进行领域微调（需承担数据标注与算力成本）。
与大模型的兼容性：若 RAG 生成阶段使用特定大模型（如 Claude），优先选择该厂商配套的 Embedding 模型（如 Claude Embedding），因厂商会优化模型间的语义对齐，减少 “检索片段与生成回答语义偏差” 的问题。

20. 在 RAG 中，索引流程中的文档解析你们怎么做的？

RAG 索引流程中的文档解析（Document Parsing）是指从原始文档中提取纯文本内容，并保留关键结构信息的步骤，需针对不同文档格式设计差异化方案，核心流程与方法如下：
文档格式分类与工具选择：① PDF 文档：分为 “可复制文本 PDF” 与 “扫描件 PDF（图片格式）”—— 可复制文本用 pdfplumber（保留段落结构、表格位置，提取精度高于 PyPDF2）提取文本；扫描件 PDF 先用 OCR 工具（如 Tesseract OCR、百度智能云 OCR）识别图片中的文字，再用 pdfplumber 提取 OCR 后的文本；若含表格，用 pdfplumber.table.extract_tables() 提取表格数据，转为 “表格标题：行 1 - 列 1：内容；行 1 - 列 2：内容” 的文本格式，确保表格信息可被 Embedding 捕捉；② Word 文档（.docx）：用 python-docx 工具，通过 document.paragraphs 提取段落文本，document.tables 提取表格（转为文本格式），同时保留章节标题层级（如 “一级标题：XXX；二级标题：XXX”）；③ Markdown 文档：用 python-markdown 工具解析，提取 # 标题、## 子标题 等层级结构，去除 **、[]() 等 Markdown 语法标签，保留纯文本内容；④ HTML 网页：用 BeautifulSoup 工具，通过 soup.get_text() 提取正文，过滤 <script>、<style>、广告标签等无关内容，保留 <h1>-<h6> 标题、<p> 段落结构；⑤ 图片文档（.jpg/.png）：直接用 OCR 工具识别文字，若含多页图片，按页码顺序拼接文本，并标注 “图片来源：页码 X”。
结构信息保留：在提取文本的同时，记录文档元数据与结构信息 ——① 元数据：文档名称、来源路径、创建时间、页码（PDF/Word）、章节标题（如 “第 2 章 数据处理”）；② 结构标记：对表格文本标记 “[表格开始] XXX [表格结束]”，对图片 OCR 文本标记 “[图片识别文本] XXX [图片识别文本结束]”，便于后续检索时识别内容类型，提升相关性判断精度。
解析质量校验与异常处理：① 校验内容完整性：抽样检查解析后的文本，确保无大面积内容缺失（如 PDF 某页未提取）、乱码（需设置正确编码，如 UTF-8）；② 处理特殊字符：去除文档中的不可见字符（如换行符、制表符过多导致的文本混乱），统一中英文标点符号（如将全角逗号 “，” 转为半角 “,”）；③ 异常文档处理：对解析失败的文档（如损坏的 PDF、加密的 Word），记录日志并提示人工处理，避免影响后续分块与 Embedding 流程。
批量解析与自动化：对大量文档（如数百份 PDF），编写批量解析脚本，按 “文件夹遍历→格式判断→对应工具解析→文本存储” 的流程自动化处理，解析后的文本按 “文档名称_页码.txt” 命名，存储到指定目录，便于后续分块步骤调用。

21. 在 RAG 应用的过程中，关于提示工程的设计有什么心得和技巧吗？

明确角色与指令边界：在提示开头给大模型设定清晰角色（如 “你是专业的客服助手，仅基于提供的文档片段回答用户关于退款流程的问题，不编造信息”），避免大模型偏离任务范围，尤其减少 “幻觉” 生成。
结构化知识片段呈现：将检索到的文档片段按 “来源 + 核心内容” 格式整理（如 “【文档来源：退款政策第 3 条】退款申请需提交订单号、身份证照片，审核周期为 3-5 个工作日”），用分隔符（如 “---”）区分不同片段，帮助大模型快速定位关键信息，避免信息混淆。
补充上下文与约束条件：若用户查询简洁（如 “怎么退款”），在提示中补充场景上下文（如 “用户当前需办理电商平台购物退款，结合以下文档片段说明具体步骤”）；同时添加约束（如 “回答分点说明，每步不超过 20 字，避免使用专业术语”），确保回答符合用户理解习惯。
多轮对话时携带历史信息：多轮 RAG 对话中，提示需包含 “历史查询 + 历史回答 + 新检索片段”，但需压缩冗余历史（如仅保留与当前查询相关的历史内容），避免 Token 超限，同时让大模型理解对话逻辑连贯性（如 “用户上一轮询问退款材料，现在追问审核进度，结合以下新片段回答”）。
预留修正空间：在提示末尾添加 “若文档片段中无相关信息，需明确告知用户‘当前暂未查询到该问题的相关说明’，不可猜测回答”，避免大模型在信息不足时强行生成内容，提升回答可信度。

22. 什么是 Advanced RAG？

Advanced RAG（高级检索增强生成）是在基础 RAG 框架上，通过引入 “多阶段检索优化、知识推理、动态记忆管理、多模态融合” 等技术，解决基础 RAG 局限（如检索精度低、无法处理复杂推理问题、仅支持文本知识）的增强方案。核心特征包括：
多阶段检索：突破 “单向量检索” 模式，新增 “初步召回→Rerank 重排序→自查询筛选” 等环节，例如先用向量检索召回 100 个候选片段，再用交叉编码器（如 Cohere Rerank）筛选出 20 个高相关片段，最后通过自查询补充 “时间 / 地域” 等结构化条件，得到最终 5 个精准片段。
知识推理能力：集成逻辑推理模块，对复杂查询（如 “分析 2023 年与 2024 年新能源汽车销量差异的原因”），先通过检索获取两年销量数据及影响因素文档，再用大模型推理模块拆解 “政策影响、市场需求、供应链” 等维度，结合检索信息生成结构化分析结果，而非单纯拼接文档内容。
动态记忆管理：区分 “短期对话记忆” 与 “长期知识记忆”，短期记忆存储用户当前对话中的个性化信息（如 “用户所在地区为北京”），长期记忆存储检索到的通用知识，在生成回答时融合两类记忆，提升个性化与精准度（如 “结合北京新能源补贴政策，您查询的 2024 年销量增长原因包括……”）。
多模态支持：突破基础 RAG 仅处理文本的限制，支持图片、表格、音频等多模态知识检索，例如检索含图表的文档时，先提取图表数据转为文本描述，再进行 Embedding 与检索，生成回答时同步引用图表关键数据（如 “根据文档中的销量折线图，2024 年 Q2 销量环比增长 15%”）。

23. 什么是 Modular RAG？

Modular RAG（模块化检索增强生成）是将 RAG 系统拆分为 “独立可替换模块”，通过标准化接口组合各模块，实现 “灵活扩展、按需定制、低耦合维护” 的架构设计方案。核心特点是 “模块解耦 + 接口标准化”，各模块可独立开发、测试、替换，不影响整体系统运行。核心模块及功能：
数据接入模块：负责从不同来源（本地文件、数据库、API、网页）收集文档，支持 PDF、Word、Markdown 等多种格式，模块输出为 “原始文档列表”，可替换为适配特定数据源的插件（如对接企业内部数据库的定制模块）。
预处理模块：包含文档解析、清洗、分块功能，输出为 “结构化文档分块（含元数据）”，可根据文档类型替换分块策略（如对代码文档用 “函数级分块”，对普通文本用 “语义分块”）。
向量生成模块：将文档分块转为向量，输出为 “向量 + 分块映射表”，可替换不同 Embedding 模型（如从 OpenAI Embedding 切换为开源的 Sentence-BERT），或添加向量压缩功能（如 PCA 降维）。
检索模块：包含向量检索、Rerank、自查询等功能，输出为 “Top-K 相关分块”，可替换向量数据库（如从 Pinecone 切换为 Milvus），或新增检索策略（如混合检索中添加关键词检索模块）。
生成模块：接收检索分块与用户查询，生成回答，输出为 “最终回答文本”，可替换不同大模型（如从 GPT-4 切换为 Claude 3），或添加提示压缩、格式美化等子功能。
优势：便于团队协作开发（不同团队负责不同模块）、快速适配业务变化（如新增数据源仅需开发数据接入模块）、降低维护成本（模块故障仅需修复或替换对应模块，不影响其他功能）。

24. 什么是护栏技术？

在 RAG 及大模型应用中，护栏技术（Guardrail Technology）是指通过 “规则约束、内容过滤、权限控制、输出校验” 等机制，确保系统生成的内容 “合规、安全、符合业务规范”，避免出现违规信息、敏感内容或超出业务范围的回答，核心目标是 “划定系统行为边界，降低风险”。常见护栏技术及应用场景：
输入护栏：对用户查询进行预处理，过滤违规输入（如含辱骂、歧视、违法内容的查询），通过关键词匹配、语义分析（如用大模型判断查询是否合规）拦截违规请求，例如用户输入 “如何制作危险物品”，系统直接返回 “该查询涉及违规内容，无法提供帮助”。
知识边界护栏：限制 RAG 系统仅基于指定的合法知识文档生成回答，禁止引用外部未授权知识或编造信息，通过在提示中明确 “仅使用以下提供的文档片段回答，不使用其他外部知识”，并在生成后校验回答与检索片段的一致性（如用 BERTScore 检测语义相似度），避免回答超出知识范围。
输出内容护栏：对生成的回答进行后处理，过滤违规表述（如敏感政治内容、虚假宣传信息），通过关键词过滤库、正则匹配（如过滤特定敏感词）、语义审核（如用大模型判断回答是否合规）确保输出安全，例如金融 RAG 系统生成回答时，自动过滤 “承诺保本高收益” 等违规表述。
权限护栏：根据用户身份（如普通用户、管理员、VIP 用户）限制可访问的知识范围与功能，例如普通用户仅能检索公开文档，管理员可检索企业内部敏感文档；通过在检索模块添加权限校验逻辑，确保不同用户仅获取授权范围内的知识，避免数据泄露。

25. 什么是 GPTCache？

GPTCache 是一款用于 “缓存大模型生成结果与 RAG 检索结果” 的开源工具，核心功能是将 “用户查询→检索结果→生成回答” 的映射关系存储到缓存中，当用户提交相同或相似查询时，直接从缓存返回结果，无需重复执行检索与生成流程，核心目标是 “降低大模型 API 调用成本、提升系统响应速度”。核心特性与工作原理：
多级缓存支持：支持内存缓存（如 Redis、Memcached）、本地文件缓存（如 JSON 文件）、分布式缓存（如 Redis 集群），可根据业务场景选择缓存介质（如高并发场景用 Redis 集群，本地测试用文件缓存）。
相似查询匹配：不仅缓存完全相同的查询，还支持相似查询匹配（如用户查询 “如何办理退款” 与 “退款流程是什么” 视为相似查询），通过计算查询向量与缓存中查询向量的相似度（如余弦相似度 > 0.9），命中相似缓存时返回结果，提升缓存命中率。
缓存过期与更新：支持设置缓存过期时间（如 24 小时），过期后自动重新执行检索与生成流程；当底层知识文档更新时，可手动或自动触发缓存清理（如删除与更新文档相关的缓存条目），确保缓存内容与最新知识同步。
与 RAG 无缝集成：可直接对接 LangChain、LlamaIndex 等 RAG 框架，在检索模块后、生成模块前添加缓存逻辑 —— 检索前先检查缓存，若命中则直接返回检索结果与生成回答；若未命中则执行检索与生成，完成后将结果存入缓存。
适用场景：大模型 API 调用成本高的场景（如按 Token 计费的闭源模型）、高并发 RAG 应用（如客服智能体）、知识文档更新频率低的场景（如静态帮助文档检索）。

26. 大模型的结构化输出指的是什么？

大模型的结构化输出是指通过 “提示指令约束” 或 “工具辅助”，让大模型生成的内容遵循固定格式（如 JSON、XML、表格、Markdown 列表），而非自由文本，核心目标是 “让输出内容机器可解析、人类易阅读、便于后续数据处理”。核心特点与实现方式：
格式固定性：输出内容有明确的结构规则，例如生成用户信息时，固定格式为 {"user_id": "123", "name": "张三", "age": 25}（JSON 格式），或 “| 用户 ID | 姓名 | 年龄 |n|--------|------|------|n| 123 | 张三 | 25 |”（Markdown 表格格式），避免自由文本的表述差异。
实现方式：① 提示指令约束：在提示中明确指定输出格式，例如 “请将用户信息按以下 JSON 格式返回：{"user_id": "字符串", "name": "字符串", "age": 数字}，无需额外说明文字”；② 工具辅助：使用大模型的结构化输出插件（如 OpenAI 的 response_format 参数指定 {"type": "json_object"}），或通过 LangChain 的 StructuredOutputParser 工具，自动校验并修正输出格式，确保符合要求。
应用场景：① 数据存储与分析：生成的结构化数据可直接导入数据库（如 JSON 格式用户信息导入 MongoDB），或用 Excel 打开（如 CSV 格式表格）；② 接口调用：生成的结构化数据可直接作为 API 请求参数（如生成 {"order_id": "456", "amount": 100} 用于调用支付接口）；③ 多系统协作：不同系统间通过结构化输出传递信息，避免格式解析错误（如 RAG 系统生成结构化报告，供 BI 工具可视化展示）。

27. 什么是 GPT Structured Outputs？

GPT Structured Outputs（GPT 结构化输出）是 OpenAI 针对 GPT 系列大模型（如 GPT-3.5、GPT-4）推出的结构化输出功能，通过在 API 调用中指定 response_format 参数，强制大模型生成符合特定格式（目前主要支持 JSON）的输出，无需依赖复杂的提示指令约束，核心目标是 “简化结构化输出实现流程，提升格式准确性”。核心特性与使用方式：
格式强制约束：通过 API 参数直接指定输出格式，例如调用 GPT-4 API 时，设置 response_format={"type": "json_object"}，大模型会严格生成 JSON 格式内容，不包含任何额外的自然语言说明（如无 “以下是 JSON 结果：” 这类前缀），避免手动清理输出内容。
格式校验与修正：大模型内部会自动校验生成的 JSON 格式合法性（如括号匹配、键值对格式正确），若存在格式错误会自动修正，大幅降低 “生成非标准格式” 的概率，相比纯提示约束（如仅在提示中要求 “生成 JSON”），格式准确率提升显著。
使用方式示例：在 API 请求中添加参数：

json
{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "请返回用户ID为123的基本信息，包含name和age字段"}],
  "response_format": {"type": "json_object"}
}

大模型会返回标准 JSON 结果：{"name": "张三", "age": 25}。
适用场景：需高频生成结构化数据的场景（如 RAG 系统生成结构化报告、客服系统生成工单信息、数据标注工具生成标签数据），尤其适合对格式准确性要求高、需自动化处理输出结果的业务（如直接对接数据库或 API 接口）。

28. 什么是 LangChain？

LangChain 是一款用于构建 “大模型驱动应用” 的开源框架，核心目标是 “简化大模型与外部知识、工具、多模态数据的集成流程”，通过提供标准化组件与流程编排能力，帮助开发者快速搭建复杂大模型应用（如 RAG 系统、智能体 Agent、多轮对话机器人），避免重复开发基础功能。核心定位与价值：
连接外部能力：解决大模型 “知识局限（依赖训练数据）、无工具交互能力” 的问题，支持大模型对接外部知识（如文档、数据库）、工具（如 API、代码执行环境、第三方服务）、多模态数据（如图片、音频），扩展大模型应用边界。
流程编排：提供 “链（Chain）” 与 “智能体（Agent）” 两种核心编排方式 ——“链” 按固定流程执行任务（如 RAG 中的 “检索→生成” 固定流程）；“智能体” 按动态逻辑决策任务执行步骤（如根据用户查询自主判断 “是否需要检索知识、是否需要调用工具”），满足不同复杂度的应用需求。
生态丰富：集成主流大模型（如 OpenAI GPT、Google Gemini、Anthropic Claude、开源的 Llama 系列）、向量数据库（如 Pinecone、Milvus、Chroma）、工具（如 Wikipedia API、Python 代码执行器、邮件发送工具），开发者无需手动适配不同工具的接口，直接通过 LangChain 组件调用。
低代码门槛：提供丰富的预制组件（如 RAG 场景的 RetrievalQA 链、对话场景的 ConversationChain），开发者仅需少量代码即可搭建应用，同时支持深度定制（如自定义链流程、扩展新工具）。

29.LangChain 的核心组件有哪些？

LangChain 的核心组件围绕 “数据输入、处理、流程编排、输出” 全链路设计，主要包括以下 8 类核心组件：
模型 I/O（Model I/O）：负责与大模型交互，包括：① 提示模板（Prompt Templates）：标准化提示格式（如 RAG 中 “结合以下文档回答：{context}n 用户查询：{question}”）；② 模型调用（LLMs/ChatModels）：对接不同大模型（如 GPT-4、Claude 3），支持文本生成、聊天交互；③ 输出解析器（Output Parsers）：将大模型输出转为结构化格式（如 JSON、列表），适配后续处理。
数据连接（Data Connection）：负责接入与处理外部知识，包括：① 文档加载器（Document Loaders）：从本地文件、数据库、API 等来源加载文档；② 文档转换器（Document Transformers）：实现文档分块、清洗、格式转换；③ 向量存储（Vector Stores）：对接向量数据库（如 Pinecone），存储文档向量；④ 检索器（Retrievers）：实现向量检索、Rerank 等功能，获取相关文档。
链（Chains）：按固定流程组合组件，实现特定任务，如：① RetrievalQA 链：整合 “检索器 + 大模型”，实现 RAG 问答；② SequentialChain：按顺序执行多个链（如 “检索→生成→格式美化”）；③ MapReduceChain：拆分复杂任务为子任务并行处理，再汇总结果。
智能体（Agents）：按动态逻辑决策任务步骤，包括：① 智能体类型（如 ZeroShotAgent 基于提示决策、ConversationalAgent 支持多轮对话）；② 工具（Tools）：智能体可调用的外部工具（如 WikipediaQueryRun 调用维基百科 API、PythonREPLTool 执行 Python 代码）；③ 工具调用器（Toolkits）：封装相关工具集（如 SQLDatabaseToolkit 包含数据库查询、表结构查看等工具）。
记忆（Memory）：存储对话历史或任务状态，包括：① 短期记忆（如 ConversationBufferMemory 存储最近 N 轮对话）；② 长期记忆（如 VectorStoreMemory 将对话历史存入向量数据库，支持检索相关历史）；③ 实体记忆（如 EntityMemory 存储用户相关实体信息，如 “用户姓名、偏好”）。
回调（Callbacks）：监控与记录应用运行过程，包括：① 日志记录（如记录模型调用耗时、Token 消耗）；② 进度跟踪（如显示检索、生成步骤的进度）；③ 自定义事件触发（如模型生成完成后自动发送通知）。