模型能力评估与选型与检索增强生成 RAG

• 是否理解指标不是越高越好，而是要与业务目标对齐
• 是否掌握评估集构建中避免偏差（如样本过简单）的方法
• 是否了解阈值设定如何避免"虚高"的陷阱

联动思路是建立"指标分层"：底层是技术指标（Faithfulness、Relevance、Recall），中层是任务指标（任务成功率、首答正确率），顶层是业务指标（点击率、转化、客诉下降）。工程上先用小样本人工标注建立技术指标与业务指标的映射关系，确认技术指标提升确实带来业务改善后再规模化。评估集构建要覆盖真实分布：难例、边界、稀有但高价值场景，而非只挑"模型答得好的"样本。阈值设定用"失败驱动"而非"分数驱动"——先定义什么算不可接受的业务结果，再反推技术指标阈值。避免虚高的方法：用人工校准集（Gold Set）定期校准 LLM-as-Judge，用 Pairwise 强弱排序替代绝对分数，并对评估集做数据污染检查。

分数虚高通常源于：评估集过简单、Judge 与模型同源产生偏差、阈值拍脑袋。关键是让评估指标可追溯、可解释，并与业务闭环挂钩，而不是纸面分数漂亮。

• 是否理解推理模型"测试时计算"的成本含义
• 是否知道推理模型在哪些任务上有明显优势
• 是否具备成本 ROI 判断能力

o1/o3 类推理模型通过增加思考链（Chain-of-Thought）提升复杂推理能力，对应导致 token 消耗显著增加（输出 token 常是普通模型的数倍到数十倍），单次调用成本显著上升。价值体现在：数学、代码、逻辑推理、多步规划等需要深度推理的任务上，准确率明显提升；对简单问答、检索型任务则收益甚微甚至为负。工程上应做"任务分级递送"：简单任务走快模型，复杂任务走推理模型，并设置思考链预算上限（max reasoning），在准确率与成本之间取平衡。评估用"任务级成功率/成本"而非纯准确率。

推理模型不是"更好"，而是"更贵但更准"。是否值得取决于任务的重试成本与失败代价——高价值复杂任务（如复杂代码生成、长链验证）值得，高频简单任务不值得。

• 是否了解中文模型生态与传统英文模型的差异
• 是否掌握中文专用评测集与方法
• 是否考虑合规、数据驻留等中国特有因素

中文模型选型需考虑：中文能力（成语、口语、中文格式、标点）、中文分词与检索插件、合规与备案要求（境内模型需通过备案）、数据驻留。工程上应构建中文业务评测集（真实业务语料 + 中文特色样例），对比 GLM、Qwen、文心、DeepSeek 等在中文理解、中文生成、中文结构化输出上的表现，而非只看通用榜单。中文场景下 DeepSeek 与 Qwen 系列在中文与成本上常具优势，闭源则需评估文心、GLM 的 API 稳定性与合规。选型要结合文档理解、中文检索增强（jieba 分词、中文 embedding）综合评估。

中文场景的特殊性在于语言、合规、生态三方面，不能简单套用英文选型标准。要用真实中文业务数据评测，而非通用中英混合榜单。

• 是否理解多模态模型在文档理解上的能力边界
• 是否知道传统 OCR 与多模态模型的优劣
• 是否具备成本与可靠性权衡能力

多模态模型（GPT-4o、Qwen-VL、Gemini）在结构化文档、表格、图表、版面理解上表现优秀，能直接输出结构化结果，省去传统 OCR+解析管线。但边界在：复杂版面、低清晰度、手写、非规范排版、数学公式、多语言混排上仍会出错，且成本高、延迟大。真实工程多用"分层方案"：简单文本走轻量 OCR，复杂文档走多模态模型，关键高价值字段走人工复核。对图像质量、旋转、镜像等问题要做好预处理与兜底。评估需用真实文档样本集，包含坏样本与边界案例。

多模态模型是文档理解的有力工具但不是万能。关键是把内容分类分级，用最合适的工具处理，并保留人工兜底与失败重试，避免单点依赖。

• 是否理解各基准覆盖的能力维度
• 是否知道基准分数与业务表现的差距
• 是否具备针对业务定制评测的意识

MMLU 测通用知识/多学科，HumanEval 测代码生成，GSM8K 测数学推理，MATH 测竞赛数学，还有中文的 C-Eval、代码的 SWE-bench 等。选基准要匹配任务类型：代码任务用 HumanEval + SWE-bench，数学推理用 GSM8K/MATH，通用能力用 MMLU。但基准有边界：可能存在数据污染（模型训练集含基准题目）、与真实业务分布差异大、覆盖面窄（如 HumanEval 偏简单）。因此真实工程必须"基准 + 自建业务评测集"双轨并行，用业务数据验证基准结论。

基准是快速筛选工具，不是最终决策依据。换基准带来的分数差异可能误导选型，必须结合业务真实评测与污染检查。

• 是否理解小模型的能力边界
• 是否掌握按任务复杂度分级的思路
• 是否权衡成本、延迟、隐私

选型依据是"任务复杂度 × 质量要求 × 成本预算 × 延迟约束 × 部署环境"。小模型（如 Phi-3.5、Gemma、Qwen-Turbo）适合：简单分类、意图识别、短文本抽取、结构化输出、低延迟高吞吐场景、边缘/离线部署、隐私敏感场景。大模型适合：复杂推理、长文本综合、开放生成、代码。工程上多用"模型路由"：先分类请求，简单走小模型，复杂走大模型，兼顾成本与质量。小模型能力不足时用提示工程、微调补偿，但需评测实际业务效果。

不存在"越大越好"，而是成本效益匹配。小模型推理快、成本低、可在本地部署保障隐私，是降本主力；大模型是质量兜底。分级路由是核心工程手法。

• 是否理解大模型推理的硬件需求
• 是否掌握量化对显存与成本的影响
• 是否具备 TCO（总拥有成本）估算能力

私有化部署成本包括硬件（GPU 服务器）、显存、电力、带宽、运维人力、监控与 GPU 集群管理。以 72B 模型为例，FP16 推理约需 140GB+ 显存，需 2 张 A100/H100 80GB；405B 需 8-16 张 H100。通过 INT8/INT4 量化、Sharding、vLLM 等可显著降低每卡承载。但硬件只是一次性投入，长期成本在运维、GPU 利用率、扩容弹性与工程师人力。真实评估用 TCO 对比 API：若利用率低、任务量小，自托管往往不划算；利用率高、数据敏感、长尾流量大时自托管更优。

私有化不是"省钱"，而是"用固定成本换数据主权与弹性"。需用 TCO 与 GPU 利用率真实测算，避免低估运维与硬件折旧。

• 是否掌握主流推理框架（vLLM、TensorRT-LLM、TGI）的使用
• 是否了解量化、批处理、连续批处理等优化
• 是否知道部署中的常见坑

部署经验核心：用 vLLM/TensorRT-LLM 实现连续批处理（Continuous Batching）与 PagedAttention 提升吞吐；用量化（AWQ/GPTQ/FP8）降低显存；按应用场景选择并发与原大小；做 GPU 预热与冷启动预热；监控显存、吞吐、延迟与错误率。Qwen 与 DeepSeek 在中文与成本上常优于同规模 Llama；DeepSeek-V3 的 MoE 架构需注意多卡部署与显存调度。常见坑：显存碎片、batch 过大导致 OOM、量化精度损失、长上下文显存爆炸。部署后需压测确定真实 QPS 与 P99。

开源模型部署的关键是"正确选框架 + 合理优化 + 压测验证"。框架选型与量化策略决定吞吐与成本，部署后必须用真实流量压测而非拍脑袋。

• 是否理解微调能改变什么、不能改变什么
• 是否掌握过拟合的识别与缓解
• 是否具备微调 vs RAG 决策能力

微调收益包括：学习特定格式/风格、domain 术语、任务指令、压缩复杂提示。但它不能"注入新知识"（知识来自训练数据），也不能解决输入侧问题。过拟合风险：训练集很小、学习率过大、轮数过多，导致模型在训练集上表现好但泛化差，甚至影响通用能力（灾难性遗忘）。缓解：用足量高质量数据、早停、正则、LoRA 低秩微调保持原参数稳定、冻结部分层。决策框架：需学新格式/风格/术语用微调，需补充实时知识用 RAG，两者可结合。

微调是"行为塑造"而非"知识注入"。收益在格式与风格，风险在过拟合与遗忘。工程上优先 LoRA 小成本试探，用留存集评测泛化。

• 是否理解领域微调的成本结构
• 是否掌握 ROI 评估方法
• 是否具备"何时值得投入"的判断力

领域微调投入包括：数据收集与清洗、标注、算力、迭代与维护。ROI 评估要看：任务量大小、微调带来的质量提升（用业务评测量化）、降低的运营成本或提升的收益。值得投入的条件：任务高频且对格式/术语/领域风格有强需求、RAG 与提示工程已到瓶颈、有足量高质量领域数据、且微调收益可长期复用。长期价值在于领域资产沉淀——但需警惕数据过时、模型快速迭代导致微调产物很快失效。若任务低频、数据不足、基座已够用，则不值得投入。

领域微调是重资产投入，要看"杠杆比"：投入产出是否划算、收益是否可持续。高频+数据足+格式需求是核心前提，否则提示工程与 RAG 更划算。

• 是否理解 AI 编程工具的能力边界
• 是否掌握正确的使用方式（拆解任务、上下文注入）
• 是否知道如何评测提升

AI 编程工具在"补全、重构、测试生成、小函数实现、样板代码、代码解释"上能显著提升效率，有研究显示完成任务耗时可降低 30-50%。但边界在：复杂项目上下文理解、跨文件架构改、模糊需求、安全/性能敏感代码上仍需人工把关。正确用法：把大任务拆成小步、注入相关文件上下文（多文件上下文）、用 AGENTS.md/CLAUDE.md 描述项目约束、让模型先写方案再实现。Copilot 重补全、Cursor 重上下文编辑、Codex 重 Agent 化自主执行。提升需用任务完成率、代码审查通过率、缺陷率评测，而非只看行数。

代码模型是"结对编程搭档"而非"替代程序员"。提升幅度取决于任务拆解与上下文管理质量，关键在人与模型的协作方式。

• 是否理解多模态统一处理的收益场景
• 是否掌握输入失败与成本兜底策略
• 是否具备成本与可靠性的权衡

收益场景：发票/合同/票据的图文混合解析、医疗影像+报告、视频内容理解、客服多模态交互（语音+文字+图片）、设计稿转代码。统一多模态模型省去"文本+图像+音频"多模型拼装，简化管线并保持上下文一致。兜底策略：对输入做质量校验（模糊、损坏、格式不支持时降级到专用模型或人工）；对解析失败走重试与降级；用内容分级控制成本（只对高价值复杂内容走多模态大模型）；对关键输出人工复核。成本可通过 token 预算、缓存、批处理控制。

多模态统一处理的价值在跨模态一致性与管线简化，但输入质量与成本是落在工程上的硬约束。必须设计失败兜底与内容分级，避免全量走贵模型。

• 是否理解蒸馏的原理与收益
• 是否掌握能力损失评估方法
• 是否具备"是否值得部署"的决策能力

蒸馏用大模型输出训练小模型，目的是在成本、延迟、离线/边缘场景中获得接近大模型的能力。价值：小模型推理快、成本低、可本地部署保护隐私。但能力损失真实存在：复杂推理、长上下文、开放生成上小模型明显弱于大模型。判断是否值得部署：用业务任务评测集对比"大模型 vs 蒸馏小模型"的成功率、质量与成本，设定"损失阈值"（如质量下降 <5% 且成本下降 >50% 则可接受）。对损失不可接受的任务路由回大模型，形成"大模型蒸馏 + 分级路由"组合。

蒸馏的价值是"用质量换成本"，关键是量化损失边界。必须用任务级评测而非单一指标判断，把损失可接受的部分下沉到小模型。

• 是否理解测试时计算的原理
• 是否掌握收益与成本的权衡
• 是否知道何时关闭思考链

测试时计算（让模型多思考、多步验证）在数学、代码、逻辑推理、长链规划、歧义消解等任务上收益明显；在简单问答、事实检索、结构化抽取上收益甚微甚至因过度思考而误判。预算设定：对推理类任务设置 max reasoning effort 或思考 token 上限，结合延迟 SLA 与成本预算反推。关闭思考链的场景：简单任务、需要快速响应、结构化输出、成本敏感、任务不需要深度推理时。工程上用"任务分级 + 路由"决定每个请求是否开启思考，并用业务评测确认收益与成本平衡点。

测试时计算是"用更多计算换更准"，不是免费午餐。收益分布极不均匀，只有推理密集任务值得。必须用预算与路由控制，避免对简单任务也开思考链。

• 是否理解长上下文的注意力与缓存成本
• 是否掌握长窗口与 RAG/摘要的取舍
• 是否具备成本与质量权衡能力

长上下文自然带来高注意力计算与缓存成本，且存在"Lost in the Middle"等问题（中部信息召回差）。权衡：窗口越长，输入 token 成本与 KV 缓存成本越高，延迟越高。应切长窗口而非 RAG/摘要的场景：信息高度相互依赖、需要全局上下文、单词条信息无法独立理解、检索难以定位（如整篇合同、长代码文件）、保留原始措辞很重要。RAG 适合信息可独立检索、检索效果好；摘要适合概括性需求。工程上多用"分级"：先检索，必要时注入长上下文，避免盲目全量灌入。

长窗口是"空间换质量"，但成本高且中部召回差。只在信息密集依赖、难以检索时用长窗口，否则 RAG/摘要更省。核心是理解信息供给方式与成本。

• 是否理解小模型的能力特点
• 是否掌握小模型的适用场景
• 是否权衡成本与质量

小模型（Phi-3.5、Gemma 2、Qwen-Turbo）的价值在：低延迟、低成本、可边缘/本地部署、隐私友好。适用场景：简单分类、意图识别、实体抽取、短文本标准化、代码补全、路由决策、结构化输出。边界：复杂推理、长文本综合、开放生成、多步规划上能力弱。真实工程把大模型"蒸馏"或"路由"给小模型处理简单任务，用大模型兜底复杂任务，形成金字塔架构。部署用量化+推理框架优化，小模型可跑在单卡甚至 CPU/边缘设备。

小模型是"降本与隐私"的主力，不是"低质"的代名词。价值在于用路由把合适任务交给它，前提是能力边界要清晰并用评测验证。

• 是否理解数据污染的含义与危害
• 是否掌握检测方法
• 是否具备防污染的组织机制

数据污染指模型训练数据包含评测集样本，导致评测分数虚高。检测方法：n-gram 重叠检测（评测样本与训练数据/公开数据高相似）、改写检测（paraphrase）、时间戳校验（评测集发布晚于训练）、漏出检测工具（如 Contamination 数据集）、用"防污染"的私密评测集（不进训练）。降低影响：使用自建业务评测集、分版本隔离评测集、随机采样、定期更换评测集、对评测结果做多重交叉验证。评估加"污染审计"报告，标注哪些分数可能受污染。

数据污染是评测可信度的最大威胁之一。检测靠 n-gram 与私密集，缓解靠自建+版本隔离+定期轮换，结论要标注污染风险。

• 是否理解灰度发布与回退机制
• 是否掌握回退触发条件
• 是否具备上线稳定性管理能力

模型升级应采用灰度发布（canary）：先小流量（如 5%）验证，再逐步放大。回退触发条件：关键指标恶化（任务成功率下降、延迟超标、错误率上升、幻觉率上升、用户投诉增加）、A/B 对比为负、修复的 bug 复发。回退策略：保留旧版本模型快照与配置，支持一键回退；用路由/流量开关在新旧版本间切换；回退后保留监控数据用于分析。工程上要预设"回退阈值"并在升级前写好回退预案，避免升级失败时手忙脚乱。

模型升级必须可回退。灰度+监控+一键回退是标准工程纪律，触发条件要量化（指标阈值），预案要提前写好。

• 是否理解 Self-RAG 与 Corrective-RAG 的原理
• 是否掌握其适用场景
• 是否权衡复杂度与收益

Self-RAG 让模型在生成时自我反思检索是否需要、段落是否相关，动态决定检索与否；Corrective-RAG 在检索结果质量差时"纠正"（重写查询、换检索策略、放弃检索）。真实应用：多步骤问答、检索结果质量不稳定、需要减少幻觉的场景。代价是增加推理步骤与延迟、复杂度上升。工程上并非所有场景都值得，简单检索效果好时用基础 RAG 即可；检索结果差、查询复杂、幻觉代价高时引入 Correction/Self-Reflection。

Advanced RAG 用"自我检查/纠正"换质量，但增加复杂度与延迟。取舍在检索质量与幻觉代价——检索本就很稳时不必上。

• 是否了解常见 Embedding 模型及其差异
• 是否理解领域微调 Embedding 的收益
• 是否具备检索质量评估能力

Embedding 选型要看维度、压缩率、语言支持、检索质量（Recall@k、MRR）。常见有 OpenAI embedding、BGE、BGE-M3、Qwen-Embedding、M3E 等，中文场景 BGE/Qwen 表现好。领域微调 Embedding（用领域数据训练/微调）能在领域术语与语义上提升检索质量，但需标注数据与算力，收益需用领域评测集验证（对比微调前后 Recall@k/MRR）。真实收益：领域术语、同义表达、专业缩写检索更准。若通用 Embedding 已够用，微调收益有限，先评估再投入。

Embedding 是 RAG 的检索底座。选型重语言与检索质量，领域微调是"锦上添花"，需用检索指标量化收益，避免盲目投入。

• 是否理解 HyDE 的原理
• 是否知道提升幅度与边界
• 是否权衡成本

HyDE 先用 LLM 针对查询生成一个"假设文档"（回答），再对这个假设文档做 Embedding 检索，从而让查询与文档的语义更接近，缓解"查询-文档"的词汇/语义鸿沟。真实提升幅度：在查询与文档语言差异大、查询简短模糊时提升明显（检索 Recall 可提升数个点）；但查询与文档本就匹配好时提升有限甚至无效。代价是额外一次 LLM 生成调用，增加延迟与成本。适用：查询含糊、检索质量差、需要跨语言/风格匹配的场景；对检索已很稳的场景收益低。

HyDE 用"生成假设文档"拉近查询与文档语义，提升在查询-文档鸿沟大时明显，但要付出一次 LLM 调用成本，需按场景权衡。

• 是否理解两者的定位差异
• 是否掌握各自的优势场景
• 是否具备工程选型判断力

LlamaIndex 专注"数据框架"，擅长 RAG：文档加载、索引、切分、检索、查询引擎开箱即用，对 RAG/Agentic RAG 深度优化。LangChain 是通用"编排框架"，擅长 Agent、工具调用、链条编排、多模型多工具集成，生态广但抽象层多、版本变动大易踩坑。选型：以 RAG 为主选 LlamaIndex，以 Agent/通用编排为主选 LangChain；两者可结合或直接用自己的轻量封装。真实工程常因 LangChain 抽象过多而选择自建或 LlamaIndex 简化。

LlamaIndex 面向 RAG 数据框架，LangChain 面向通用编排。选型看核心诉求，警惕抽象层较多的框架带来的维护成本与版本漂移。

• 是否理解长文档 RAG 的挑战
• 是否掌握切分与检索策略
• 是否知道如何保持上下文

长文档 RAG 挑战：文档长、切分失语义、检索命中难、上下文超限。方案：分层切分（章节-段落-句子）、小粒度检索+大粒度上下文（retrieve 小块、注入所在大块）、重排序（Reranker）提升精准、多级索引（标题+正文）、长上下文模型兜底。对需要全局理解的文档（如整本合同、长报告），用"章节级摘要+按需检索细节"或直接切长窗口。工程上要平衡召回质量与 token 成本，用 LongReranker 等定位关键段落。

长文档 RAG 的核心是"小而准的检索 + 大而全的上下文"。用分层切分与重排序解决召回，用长上下文兜底全局理解。

• 是否理解多模态 RAG 的原理
• 是否掌握多模态检索与生成方案
• 是否了解生产挑战

Multimodal RAG 让检索与生成同时处理文本与图像（图表、图片、PDF 版面）。方案：多模态索引（图像用 CLIP 类 embedding 或图文混合 embedding）、检索后按需注入图像或图像描述、多模态模型生成。生产应用：图表问答、文档版面理解、图片内容检索、产品图片客服。挑战：多模态 embedding 对齐难、图像 token 成本高、检索混合排序难、图像质量兜底。工程上常"先转文本+图像描述建立索引，必要时再取原图给多模态模型"，平衡成本与准确。

Multimodal RAG 的价值在图文混合检索，但成本与对齐是难点。常用"文本/描述建索引 + 按需取图"的混合方案控制成本。

• 是否掌握向量数据库的选型
• 是否了解性能与运维要点
• 是否具备生产经验

Qdrant 轻量、易部署、单机性能好、Rust 实现、支持 HNSW 与过滤，适合中小规模与快速上线的场景；Milvus 功能全、生态成熟、支持分布式与大规模、有 Attu 等运维工具，但部署与运维更重。生产要点：向量维度与索引参数（HNSW 的 M、ef_construction）调优、内存与磁盘平衡、元数据过滤配合、冗余与备份、监控 QPS 与召回。选型：规模小用 Qdrant，规模大/需分布式用 Milvus，均需压测验证召回与延迟。

向量库选型看规模与运维能力。Qdrant 轻量、Milvus 大规模分布式，都要做索引调优与压测，生产注意监控与备份。

• 是否理解两者的成本与能力差异
• 是否掌握判断依据
• 是否具备混合方案意识

RAG 与长上下文是"互补"而非"替代"：RAG 用检索降低成本、专注相关段落，适合信息可检索、语料大、成本敏感的场景；长上下文一次性注入适合信息高度依赖、检索困难、需全局视角的场景。判断依据：信息量大小（语料大用 RAG）、信息相关性（高度独立用 RAG，高度依赖用长窗口）、成本预算（长窗口贵）、检索质量（检索差用长窗口）。真实工程常组合：先检索用小窗口，复杂全局问题切长窗口。

两者针对不同信息供给问题。RAG 省成本、专注相关，长窗口得全局、成本高。判断靠信息规模、相关性与预算，常组合使用。

• 是否理解引用追踪的价值
• 是否掌握实现方法
• 是否了解验证与溯源

引用追踪让生成结果可溯源到具体文档，提升可信度与可审计性。实现：切分时保留文档 ID 与段落位置；生成时通过 prompt 要求模型引用来源（如分段编号）；用"引用-内容"匹配验证引用是否真实对应、是否过度引用；前端展示引用与可点击跳转。验证引用真实性：将引用段落与生成文本做相似度/包含匹配，防止模型"编造引用"。生产上引用是合规与信任的关键，尤其在金融、医疗、法务场景。

引用追踪是 RAG 可信度的关键。保留来源元数据 + 生成时引用 + 引用真实性校验，形成可审计闭环，防止编造引用。

• 是否理解中文分词对检索的影响
• 是否掌握中文 Embedding 与检索策略
• 是否了解中文切分与重排序

中文无空格分词，直接按字符切分可能破坏语义。中文 RAG 特殊性：切分要按中文标点/段落/语义断句，避免句子被截断；Embedding 要选中文优化的模型（BGE、Qwen-Embedding、M3E）；检索可用 jieba/HanLP 分词做关键词辅助，但语义检索主要靠 Embedding；同义词、口语、专业术语需在索引与查询处理上增强。中文检索质量用 Recall@k 与中文语料评测，分词结果影响关键词匹配但语义检索受 Embedding 影响更大。

中文 RAG 的关键在切分粒度与中文 Embedding。分词辅助关键词检索，语义检索靠 Embedding，需用中文语料评测调优。

• 是否理解元数据过滤的作用
• 是否掌握实现方式
• 是否了解企业应用场景

元数据过滤用文档的元数据（部门、时间、权限、类型、版本、语言）在检索前缩小范围，提升精度、降低噪声、实现权限控制。实现：切分时抽取并存储元数据，检索时按元数据条件过滤（如"限本部门 2024 年文档"），结合向量检索（hybrid filter）。企业价值：多租户数据隔离（按权限过滤）、时效性控制（按时间）、多源去重（按来源）、定向检索（按类型）。元数据过滤显著提升企业 RAG 的准确性与合规性。

元数据过滤是"检索前的缩小范围"，提升精度并实现权限与时效控制，是企业 RAG 的合规与准确性基石。

• 是否理解 GraphRAG 的原理
• 是否掌握适用场景
• 是否了解其复杂度与成本

GraphRAG 用图结构（实体-关系）组织知识，支持多跳推理、全局型问题、实体间关系查询。适用场景：需要跨实体推理、关系复杂、全局性问题（如"所有相关方之间的关系"）、知识图谱型数据。复杂度与成本：建图需实体抽取与关系建模（成本高、需 LLM 抽取）、图存储与查询、图遍历与检索、易出错。不适合：简单事实检索、单实体查询、成本敏感场景。真实工程常"图 + 向量"混合：图用于关系与多跳，向量用于语义检索。

GraphRAG 强在多跳与全局关系推理，但建图与查询成本高。用"图+向量混合"平衡，只对需要关系推理的场景上图。

• 是否理解切分粒度的影响
• 是否掌握不同切分策略
• 是否了解切分与检索的权衡

切分粒度影响召回质量：过大则含噪声、hit 命中差、embedding 语义稀释；过小则语义断裂、上下文不足。策略：固定字符（简单但易切断语义）、按语义/段落/标点切分、递归切分（先大块再小块）、按文档结构（标题-段落）切分、父子切分（retrieve 小块、注入大块）。选择要结合文档类型与 Embedding 特性，用评测集对比不同切分策略的 Recall@k/MRR。同一文档可多粒度索引，提升召回。

切分是 RAG 的"地基"，粒度直接影响召回。需结合文档结构、Embedding 与评测调优，常见用父子切分兼顾精度与上下文。

• 是否理解 Agentic RAG 的多步流程
• 是否掌握失败模式
• 是否了解评估指标定义

Agentic RAG 让 Agent 自主决定检索步骤：查询重写、多步检索、验证、反思，复杂查询（多实体、歧义、需多源交叉）上比单轮 RAG 更准。收益：多跳问题、需多源整合、查询模糊时提升明显。失败模式：Agent 循环不收敛、检索步数失控、重写引入新错误、验证误判、成本/延迟失控。评估指标：任务成功率、平均检索步数、答案正确率（Faithfulness）、成本与延迟、失败率。需定义"何时终止"与"步骤预算"，防止无限循环。

Agentic RAG 用"多步自主检索"换复杂查询的准确，但引入循环与成本风险。评估要同时看成功率与步骤/成本，防失控。

• 是否理解语义缓存与 KV 缓存的区别
• 是否掌握命中判定与一致性
• 是否了解失效与过期处理

语义缓存用查询的语义相似度判断命中（相似查询复用结果），KV 缓存缓存 prompt 前缀的 KV 计算。命中判定：语义缓存用 embedding 相似度阈值判定"是否足够相似"，需防误命中（语义相似但答案不同）；KV 缓存用前缀匹配。一致性：缓存结果需校验底层数据是否变化，数据更新时主动失效相关缓存；设 TTL 与版本号。避免过期：缓存带数据版本/时间戳，底层文档更新时级联失效；高时效场景（新闻、实时数据）降低缓存命中率或禁用。

缓存降本提速，但一致性是核心风险。语义缓存要防误命中，KV 缓存要前缀匹配，数据更新需级联失效+版本控制。

• 是否理解 Prompt 模板的工程化
• 是否掌握版本管理方式
• 是否了解可追溯与回滚

RAG 的 Prompt 模板变化会显著影响输出质量，需工程化管理。模板拆分：系统提示、检索指令、格式约束、few-shot 分离；版本管理：纳入 Git，模板带版本号与变更记录；发布：模板与代码/CD 一起发布，支持灰度与回滚；运行时记录模板版本与输出，便于追溯与定位问题。A/B 测试模板对比。用模板仓库（如 Promptfoo）统一管理评测，改动模板后跑回归。

Prompt 模板是"代码资产"，要版本化、可追溯、可回滚。模板改动需回归评测，避免"玄学"式改动。

• 是否理解 A/B 测试在 RAG 中的应用
• 是否掌握实验设计与指标
• 是否了解结果分析

RAG A/B 测试用于对比切分、检索、重排、Prompt 等改动。设计：随机分流、对照组（现有）与实验组（改动）、样本量足够、避免污染（同一用户/文档）。指标：端到端任务成功率、答案质量（人工或 LLM 评估）、检索指标（Recall@k）、延迟与成本。分析：统计显著性、按场景/用户分群分析、结合业务指标。经验：先离线评测快速筛选，再在线 A/B 验证；关注代理指标（quality）与业务指标（conversion）双重验证；避免"只涨分数不涨业务"。

RAG A/B 测试要随机分流、指标分层（质量+业务）、统计检验。先离线筛再在线验，避免纸面分数与业务脱节。

• 是否理解各指标含义
• 是否掌握指标局限
• 是否了解评估方法

Faithfulness（忠实度）：生成内容是否忠于检索上下文，是否幻觉；Relevance（相关性）：检索/生成内容与问题是否相关；Recall（召回率）：检索是否覆盖所有必要信息。综合反映 RAG 的"检索准不准、生成忠不忠"。局限：指标依赖自动评估（LLM-as-Judge）或人工，存在主观性；Recall 难定义"完整答案"；指标间可能冲突（高相关但低忠实）。工程上分层评估：检索层（Recall@k、MRR）与生成层（Faithfulness、Relevance、正确率），结合人工抽查校准。

指标各司其职：Recall 看检索覆盖，Relevance 看相关性，Faithfulness 看生成忠实。需分层评估+人工校准，避免唯指标。

• 是否理解增量索引的意义
• 是否掌握实现方式
• 是否了解一致性保障

增量索引指文档新增/修改/删除时只更新受影响部分，而非全量重建。实现：文档变更检测（监听数据源/定时扫描）、变更入队处理、按文档 ID 更新向量（新增 embedding、删除旧、更新元数据）、向量库支持 upsert/delete。一致性：读取与索引之间延迟（滚动窗口）、更新失败重试、版本控制。生产上批量（定时）与实时（事件驱动）结合，监控索引延迟与失败率。增量索引显著降低频繁更新的成本与延迟。

增量索引避免全量重建，靠变更检测+按 ID upsert/delete 实现。需管理索引延迟与一致性，监控更新失败。

• 是否理解 Lost in the Middle 现象
• 是否掌握 LongReranker 等方案
• 是否了解长文档处理策略

"Lost in the Middle"指模型对长上下文中部信息召回/利用差的现象。解决方案：重排序（LongReranker 等长文档重排器）把关键段落提到前面；结构化摘要（先章节摘要再定位细节）；分层检索（小粒度检索+大块上下文）；把关键信息放首尾或多次强调；用长上下文模型+针对性设计。工程上组合：检索+重排+父子上下文+必要时长窗口，缓解中部信息丢失，提升长文档问答准确率。

Lost in the Middle 是长上下文共性缺陷，重排序与关键信息前置是主要缓解手段，配合分层检索与长窗口。

• 是否了解 Claude 的生产表现
• 是否掌握稳定性评估维度
• 是否了解限流与降级

Claude 3.5/4 在代码、长上下文、指令遵循、写作上表现优，生产稳定性总体良好。评估维度：可用性（SLA/故障率）、输出一致性（同输入结果稳定）、质量稳定性（版本间波动）、限流（速率限制与配额）、延迟波动。生产注意：不同版本/日期准确率有波动，需监控；限流需设计重试与降级；长上下文与工具调用质量影响稳定性。配合多供应商路由与监控告警，用 fallback 保障。

闭源模型稳定性评估看可用性、一致性、延迟与限流。生产需监控波动、处理限流降级、多供应商兜底。

• 是否理解两者的代码能力差异
• 是否掌握风格与上下文差异
• 是否具备选型判断

两者代码能力都强，但在细节上：Claude 3.5 Sonnet 在长文件重构、多文件准确、代码审查、指令遵循上常被评测（如 SWE-bench）认可为领先；GPT-4o 在通用性、生态（工具链、Function Calling 成熟度）、补全与解释上均衡。工程选型：重代码代理/长上下文编码场景偏好 Claude，通用多模态与生态集成偏好 GPT-4o。真实差异需用本团队代码任务评测（SWE-bench 子集 + 业务代码），而非只看榜单。可多供应商路由。

两者各有侧重，Claude 在长上下文代码与审查上强，GPT-4o 生态通用均衡。选型用业务代码评测，可路由组合。

• 是否理解闭源 API 的 SLA 含义
• 是否掌握常见故障模式
• 是否具备容错设计能力

闭源 API 的 SLA 通常指可用性（如 99.9%），但不保证输出质量与延迟。常见故障模式：限流（429）、超时、5xx 错误、模型版本变更导致输出漂移、区域性故障（跨区不可用）、软性降级（慢而不挂）。容错设计：超时与重试（指数退避）、限流退避、多供应商路由、降级（降小模型/缓存/人工）、熔断（连续失败后切走）、监控告警。生产不能单点依赖某 API，需冗余与可观测性。

闭源 API 的 SLA 只覆盖可用性，不覆盖质量与延迟。真实工程要设计超时重试、限流退避、多供应商与熔断降级。

• 是否理解两者的原理与差异
• 是否掌握适用场景
• 是否具备成本与效果权衡

Prompt tuning（软提示）训练少量连续参数，成本低、适合快速适配、但表达能力有限且对模型特定；LoRA 微调低秩适配器，表达能力更强、可针对任务/领域，但需训练数据与算力、有一定部署成本。适用边界：简单任务、标注少、快速试探用 Prompt tuning；需要学习格式/风格/领域、数据足、效果要求高用 LoRA。两者都保持基座不变，可叠加。选择看任务复杂度、数据量与效果要求。

Prompt tuning 轻量表达受限，LoRA 更强但需数据与算力。按任务复杂度、数据量与效果要求选择，可叠加。

• 是否了解各厂商稳定性特征
• 是否掌握评估维度
• 是否具备多供应商视角

三家各有特点：OpenAI GPT 生态成熟、历史最长、可用性总体稳定但也不排除故障；Anthropic Claude 在代码与长上下文稳定、但规模与限流或更敏感；Google Gemini 集成谷歌生态、多模态强、价格常具竞争力但 API 稳定性与质量波动需评估。真实差异需结合区域、时区、具体任务评测（延迟、错误率、输出一致性）。生产上多供应商路由+监控，降低单一供应商故障影响。

三家的稳定性差异需看具体任务与故障分布，不能一概而论。生产用多供应商路由+监控降低单点风险。

• 是否理解 RAG 延迟构成
• 是否掌握 P99 优化方法
• 是否具备工程权衡

RAG 端到端延迟 = 检索（embedding + 向量检索）+ 重排 + LLM 生成 + 网络。P99 常受长尾影响（大文档、长生成、并发抖动）。优化：Embedding 与检索用专用并行/缓存、生成用流式、控制 max_tokens、模型路由（简单走小模型）、缓存（KV/语义）、并行检索多路、优化向量库。真实 P99 目标看业务（在线交互 <1-2s，批处理宽松）。需压测定位瓶颈，前端用流式降低首 token 延迟。

RAG 延迟由检索+生成多段构成，P99 看长尾。用流式、缓存、路由、并发并行与 max_tokens 优化，压测定位瓶颈。

• 是否理解递归检索与多跳问答
• 是否掌握应用场景
• 是否了解挑战

递归检索：先小粒度检索关键信息，再基于结果递归检索更大上下文（小-大），解决检索信息不足；多跳问答：问题需多步推理，跨多个文档/实体，需迭代检索。应用：复杂业务问答、需要多文档综合、关系链查询。挑战：步骤多易局部最优、检索方向错误、成本与延迟上升、判断"何时停止"难。工程上给检索步数预算、融入反思与验证、用图/结构化线索辅助。

递归检索与多跳问答应对"信息不足+需多步"的复杂查询，但需步数预算与反思防失控，成本与方向是挑战。

• 是否理解 Function Calling 的失败模式
• 是否掌握影响因素
• 是否了解提升方法

Function Calling 的真实成功率因模型、工具描述、输入而异，通常在 70-95% 范围，复杂工具/多参数时下降。失败模式：参数格式错误、字段缺失、调用错误工具、幻觉参数、未调用。影响因素：工具描述（名称、参数、示例清晰度）、模型能力、输入复杂度、工具数量。提升：精心写工具描述（含 schema、示例、默认值）、参数校验与纠错、few-shot、减少工具数量、失败重试（模型自纠）、用结构化输出约束 JSON。

Function Calling 成功率受工具描述与输入影响，失败模式多样。用清晰 schema、示例、校验纠错与重试提升。

• 是否掌握常见失败模式
• 是否理解诊断方法
• 是否具备规避策略

常见失败模式：参数错误（类型/缺失/格式）、工具选择错误、幻觉工具/参数、循环调用、工具超时、解析失败、上下文污染。诊断：记录工具调用日志、schema 校验、追踪调用链、评估失败分布。规避：清晰工具描述、参数校验、输出格式约束、重试与自纠、工具并发与超时控制、工具数量收敛、失败兜底（返回错误/人工）。工程上把工具调用纳入可观测性，统计失败率与根因。

Tool Use 失败模式主要围绕参数、选择、解析与循环。用 schema 校验、日志追踪、重试与兜底系统规避。

• 是否理解语义缓存原理
• 是否掌握命中率影响因素
• 是否了解维护成本

语义缓存用查询语义相似度复用结果，命中率取决于查询重复度与相似度阈值。查询高度重复（如 FAQ、固定模板）命中率高；长尾/个性化查询命中率低。阈值设定：过高则命中少，过低则误命中（返回错误结果）。维护成本：embedding 生成、相似度计算、缓存失效与一致性、存储管理。适用：高频相似查询、结果稳定、成本敏感场景。需监控命中率与误命中率，动态调阈值。

语义缓存命中率看查询重复度与阈值，需防误命中。维护要管理失效一致性，动态调阈值。适合高频相似查询。