本文分享了后台被问得最多的九个大模型落地问题，涵盖部署框架选型、幻觉治理、PDF解析、RAG评测等方面，均为真金白银踩过坑后沉淀的实战经验。内容涉及模型部署的最佳实践、微调避坑指南、RAG切片策略、PDF解析架构、OCR识别率提升、数据清洗技巧、幻觉问题分类治理、提示词优化技巧以及RAG质量测试方法等，旨在帮助读者少走弯路，顺利将大模型项目落地。
做过大模型落地项目的人都知道，Demo能跑通和真正上线之间，隔着无数个让人头秃的深夜。这篇整理了后台被问得最多的九个问题——从部署框架选型到幻觉治理，从PDF解析到RAG评测，每一条都是真金白银踩过坑之后沉淀下来的答案。
问题一：模型怎么部署的？
问题分析：
很多人对大模型部署的认知还停留在"pip install transformers，然后写个FastAPI包一层"这个阶段。说实话，这个方案在demo阶段完全够用，但一旦上了生产环境，要扛并发、要控成本、要保证稳定性，差距就出来了。自己手写推理服务，最大的问题是连续批处理（continuous batching）和KV Cache的显存管理——这两件事做不好，GPU利用率上不去，并发一高就OOM，单卡能服务的用户数能差出一个数量级。
答案：
推理引擎直接站在巨人肩膀上，别自己造轮子。2026年的主流选择就那几个，按场景挑：
| 框架 | 核心优势 | 适合场景 |
|---|---|---|
| vLLM | PagedAttention显存管理极强，吞吐高，OpenAI兼容接口，生态最成熟 | 大规模并发生产服务、多用户API（默认首选） |
| SGLang | RadixAttention前缀缓存命中率高，结构化输出快，长会话表现好 | Agent类应用、多轮对话、system prompt复用多的场景 |
| TGI | HuggingFace官方维护，开箱即用 | 已有HF工作流、需要快速上线的团队 |
| Ollama | 极简上手，模型管理方便 | 本地开发、内网小规模部署 |
| llama.cpp | 纯CPU也能跑，量化体系完善 | 边缘设备、嵌入式、无GPU环境 |
我的生产环境选型经验：
默认选vLLM。高并发场景下，continuous batching带来的吞吐提升是碾压级的。同样一张A100跑7B模型，原生transformers单并发每秒30个token，vLLM多并发能拉到2000+ tokens/s，这不是优化，是质变。
量化方案别乱选。FP8在H100/H200上是首选，精度损失几乎可以忽略；AWQ比GPTQ更稳，尤其长上下文场景；INT4量化一定要用覆盖真实业务序列长度的校准集，不然长文本输出会乱码重复——这个坑我踩过，短文本测着一切正常，序列长度一过2048就开始胡言乱语。
启动参数必须调。–gpu-memory-utilization别设太高，建议0.85留余量给显存碎片；–max-num-seqs根据显存和业务并发合理设置；长上下文场景开–enable-chunked-prefill和–enable-prefix-caching，首token延迟能降一大截。
外围工程别省。进程用systemd或Docker托管，配好自动重启；Prometheus+Grafana监控GPU利用率、TTFT（首字延迟）、吞吐量、队列长度；前端一定要加限流，不然流量尖峰直接把服务打挂。
一个容易被忽略的点：显存估算一定要把KV Cache算进去，别只看模型权重。70B模型FP16权重140GB，但4096序列长度、32路并发下KV Cache还要吃掉30+GB。显存公式：总显存 ≈ 模型权重 + 2×层数×头数×head_dim×序列长度×并发数×字节数 + 20%余量。算不清楚就容易上线后OOM。
问题二：微调的时候出现过什么问题？怎么解决的？
问题分析：
微调这事说起来不复杂，LoRA、QLoRA现在都有成熟工具（LLaMA-Factory之类的点几下就能跑），但真正跑出好效果的人不多。常见的误区是以为"调参就能解决一切"，实际上微调80%的坑都在数据上，剩下20%在训练稳定性和灾难性遗忘上。
答案：
我把踩过的坑按出现频率排了个序：
坑1：显存炸裂——这是入门第一道坎
全量微调13B模型需要约400GB显存（按1:1:6的权重:优化器:激活值比例算），一张H100都不够。解决方案很成熟：
用LoRA，只训练q_proj、v_proj上的低秩矩阵，可训练参数量降到0.5%~1%，显存占用直接砍一个数量级
再叠加QLoRA（4bit NF4量化base model），12GB显存就能微调13B模型
rank值别盲目开大，8~64够用，代码生成这类复杂任务可以到32；alpha通常设成rank的2倍
坑2：loss跑着跑着就炸了（NaN）
这个特别常见，原因五花八门：
学习率太高：LoRA的学习率比全量微调大，但也别超过1e-4，通常1e-5到5e-5是安全区间
混合精度训练的数值溢出：用bf16代替fp16，bf16的动态范围大得多，不容易溢出；A100及以上卡原生支持
数据里有脏数据：超长的无意义字符串、乱码、特殊token，预处理阶段一定要过滤掉超过max_length的样本
坑3：微调后通用能力掉了（灾难性遗忘）
这是最让人头疼的问题——你用客服数据微调完，模型客服话术是学会了，但原本能正常回答的通用问题开始胡说八道。解决思路：
LoRA本身就比全量微调抗遗忘，但target_modules别贪多，不是加的层越多越好
数据里混入5%~10%的通用指令数据（alpaca、sharegpt这类），保持模型通用能力
训练轮次别太多，LoRA 3~5个epoch通常足够，太多轮容易过拟合兼遗忘
验证集必须同时包含领域数据和通用数据，两边都要监控
坑4：训练完效果不如预期，甚至比不微调还差
90%的情况是数据的问题：
数据质量远比数量重要。1000条高质量标注 > 10万条脏数据。微调数据必须去重（语义去重，不只是字面去重）、过滤错误标注、统一格式
指令格式要和推理时一致。训练时用的system prompt、对话模板，推理时必须严格对齐，差一个special token效果都可能掉一截
数据分布要对齐真实场景。别拿网上爬的通用问答数据训你的垂直场景，问法、术语、回答风格都不对，模型学不到东西
EDA看看数据长度分布，如果大量样本都在很短长度，模型会学"偷懒"，回答过于简短
坑5：Loss降了但实际推理没提升
有可能是评测方式有问题，也有可能是数据泄露——训练集和测试集有重叠，loss看着很好但泛化能力为零。一定要在留出的真实业务query上测，别只看训练日志里的loss曲线。
最后说一句：微调不是万能的。如果你的目标是让模型"知道"某些新知识（比如最新产品文档），优先用RAG；微调解决的是"说话风格"、“输出格式”、"任务范式"这类能力问题，不要把知识灌输寄托在微调上。
问题三：RAG切片是怎么切的？
问题分析：
切片（Chunking）是RAG里看起来最简单、实际上对效果影响极大的环节。很多人直接用LangChain的默认RecursiveCharacterTextSplitter，设个chunk_size=500、overlap=100就完事了——这个baseline能跑通，但切得不好，后面Embedding再好、Rerank再强也救不回来。切片的本质矛盾是：切太大，检索不精准，噪声多；切太小，上下文丢了，语义不完整。
答案：
我现在用的是一套分层切片策略，不是单一方法打天下：
第一层：按文档结构切（标题层级优先）
对有结构的文档（Markdown、HTML、带书签的PDF），优先按标题层级切。一个二级标题下的内容作为一个大的语义单元，保证主题完整。这是最符合人类认知的切法——"3.2 退款规则"下面的内容天然是一个整体，不该被随机切断。
第二层：递归字符切分兜底
对没有清晰标题结构的纯文本，用递归切分（RecursiveCharacterTextSplitter）。它的核心是按分隔符优先级递归：先按双换行\n\n分大段，太大了再按单换行\n分，再按句号分，最后才按字符硬切。比固定长度切分聪明得多，能尽量在语义边界处断开。
第三层：语义切分做精细化处理
在递归切分的基础上，对关键段落（比如切分出来长度明显异常的、或者包含关键术语的），用Embedding算相邻句子的相似度，在语义发生明显转折的地方再切一刀。LangChain里的SemanticChunker就是干这个的。注意语义切分算力成本高，不用全量跑，用在关键内容上ROI最高。
几个实战中的关键参数：
Chunk size多大合适？通用场景5121024个token（中文大约300600字）是比较稳的区间。Embedding模型的最佳输入长度是重要参考——比如bge-large-zh-v1.5最佳长度是512，你切太长会被截断或稀释语义
Overlap别乱设。通常取chunk_size的10%~20%，目的是保证被切断的句子至少有一个完整副本在相邻chunk里。overlap太大浪费存储、引入冗余；太小起不到兜底作用
过小的碎片要合并。切完之后如果末尾有不足80字的碎片，把它合并到上一块，避免产生大量无意义的小chunk污染向量库
特殊内容特殊处理，别一刀切：
表格单独处理，不要硬切，最好转成HTML或Markdown表格整块存储
代码块整块保留，按函数或类切
FAQ一问一答作为一个chunk，天然是完整语义单元
长列表（比如产品参数列表）尽量保持完整
问题四：PDF、图片、复杂排版的文字怎么切？
问题分析：
这是RAG项目里最容易被低估、也是坑最多的环节。很多人用PyPDF2或pdfplumber一行extract_text()就以为搞定了，结果遇到双栏排版左右文字交错、表格拆得七零八落、扫描件直接提取不到文字、页眉页脚混在每一页正文里——这些垃圾文本进了向量库，检索质量就废了。做RAG的人迟早会在PDF解析上栽跟头，这不是夸张。
答案：
一套经过实战打磨的三层PDF解析架构，逐级兜底：
第一层：文本层（数字版PDF）
用pdfplumber或pypdfium2提取底层字符流。pdfplumber的优势是能拿到每个字符的坐标、字体大小，方便后续做版面分析。这一步解决80%的"原生数字PDF"。
但注意：提取完不能直接用，必须做版面还原——
双栏排版问题：按x坐标把字符分成左右两栏，分别按y坐标排序阅读，不能按PDF内部流顺序直接拼接
字体大小识别标题：用字体大小聚类区分标题和正文，重建文档层级结构
第二层：结构层（复杂排版、表格）
第一层提出来但版面混乱的，走结构层：
表格识别：pdfplumber自带的table提取对规则表格够用；复杂表格（合并单元格、跨页、无线表格）用TableFormer模型（docling里集成了）或camelot，输出带行列结构的HTML/Markdown表格
版面分析：用layoutparser或docling识别页面上的标题、正文、表格、图片、页眉页脚区域，按阅读顺序重排
强烈推荐试试IBM开源的docling，一个工具把PDF解析、版面分析、表格识别、OCR全串起来了，直接输出结构化Markdown，省去大量手工拼接的工作。比以前"文本提取+正则+手工修版"的土办法效率高太多
第三层：视觉层（扫描件、图片PDF）
文本层几乎提不出内容的（纯扫描件），必须走OCR：
OCR引擎选型：中文场景PaddleOCR或RapidOCR是首选，比Tesseract中文识别准确率高一个档次；有预算的话用商业API（百度、阿里、腾讯），效果更稳
OCR不是跑一次就完事，输出的是带坐标的文本框，需要自己按坐标聚合成段落、判断阅读顺序、区分表格区域——这块docling也帮你做了
路由逻辑很重要：先判断每页能提取出的文本量，低于阈值才走OCR，OCR很贵（不管是算力成本还是API费用），能少跑就少跑
图片处理：
纯图片（截图、拍照）直接走OCR管线
如果图片里有流程图、架构图等关键信息，OCR只能提取文字，图里的逻辑关系提不出来——这种情况要么人工补充文字描述，要么用多模态大模型（如GPT-4V、Qwen-VL）做图片理解，生成文字描述再入库
一句话总结：PDF解析不是"先跑通再说"的边角料，是需要单独设计的子系统。解析出来的文本质量决定了RAG效果的上限——你在垃圾文本上做Embedding，后面所有环节都是在垃圾上盖楼。
问题五：OCR识别率准吗？怎么处理？
问题分析：
OCR没有100%准确的，尤其是扫描质量差的老文档、手写内容、低分辨率图片、带水印或复杂背景的页面。“田"和"由”、“0"和"O”、“甲方"识别成"田方”、数字金额识别错一位数——这些错误进了知识库，检索出来就是错的，大模型再基于错误文本生成回答，结果可想而知。OCR准确率取决于图片质量、模型能力、后处理三个环节，只优化一个，效果有限。
答案：
OCR准确率提升是个系统工程，分三步走：
第一步：输入图片预处理（最容易做、ROI最高）
很多时候OCR不准不是模型不行，是输入图片太烂：
去噪和增强：用CLAHE（自适应直方图均衡化）处理光照不均，高斯滤波去椒盐噪声，二值化处理低对比度文档
纠偏：检测倾斜角度并矫正，歪斜超过5度识别率就会明显下降
去水印：有水印的页面，先做水印去除再OCR，不然水印文字会被识别成正文
超分辨率：分辨率太低的图片先做高清化放大，再送去OCR。实测模糊图片原图准确率62%，高清化后能到85%以上
第二步：选对OCR引擎和配置
中文场景优先PaddleOCR/RapidOCR，别用Tesseract（中文识别率惨不忍睹）
场景文字（拍照、倾斜、艺术字）用DBNet+CRNN的组合比传统方案鲁棒
手写体是老大难，通用OCR效果差，有条件针对业务数据微调OCR模型
表格OCR单独用表格结构识别模型，不要用通用OCR跑表格（单元格全乱）
第三步：后处理纠错（这步不能省）
这是提升有效准确率的关键：
领域词典纠错：构建你的业务领域专有名词词典（产品名、人名、专业术语），OCR结果中词典匹配不上的词做模糊匹配纠错。比如医疗场景里"脑梗寨"自动纠正为"脑梗塞"
N-gram语言模型纠错：用行业语料训练N-gram模型，检测OCR结果中不合理的字符组合并纠正。“田方"在合同语境中明显不合理，自动纠正为"甲方”
大模型纠错兜底：对OCR结果的关键段落（金额、日期、专有名词密集区），用大模型做语义纠错：“以下是OCR识别结果，可能存在错误，请根据上下文语义纠正明显的识别错误，保留原始格式”
置信度过滤：OCR输出的每个字符/文本块都有置信度，低于阈值的标记出来人工复核，或者直接丢弃存疑片段
实战经验：不要指望OCR一步到位做到100%。更好的策略是分层处理——关键文档（合同、财务报表）OCR后走人工抽检或大模型全量纠错；普通文档接受少量错误，依靠检索和Rerank的冗余度兜底（一个词识别错了，前后文大概率还能命中）。
问题六：数据怎么清洗的？页眉页脚用大模型清吗？
问题分析：
"Garbage in, garbage out"在RAG里是铁律。企业文档里充满了噪声：页眉页脚、页码、水印文字、重复的免责声明、目录、参考文献、广告信息、重复段落。这些东西如果不清理干净进了向量库，用户问业务问题时可能检索到页脚的公司电话，或者被重复内容稀释检索分数。清洗策略要分轻重——简单规则能解决的不要用大模型，大模型成本高且慢，全量跑不划算。
答案：
我的清洗管线是从便宜到贵、从粗到细分层处理：
第一层：规则清洗（成本≈0，覆盖80%场景）
页眉页脚的清除优先用规则，不要上来就用大模型：
PDF/docx里的页眉页脚：用解析工具的版面分析能力直接识别header/footer区域丢弃。docling、pdfplumber都能拿到区域类型标签；python-docx处理Word文档可以直接访问sections里的header/footer删除
页码去除：正则匹配行首行尾的纯数字（^\d+$），结合位置信息（页面顶部/底部）判断
重复行检测：统计所有行的出现频率，每页都出现的相同内容（公司名、保密声明、“第X页 共Y页”）就是页眉页脚，自动标记删除
多余空白：合并多个空行、去除全角空格和特殊空白字符、去除零宽字符
目录和参考文献：通过关键词（“目录”、“Contents”、“参考文献”、“References”）+页码模式匹配识别并去除（注意：如果用户会问"文档包含哪些章节"，目录要保留，可单独存成一个chunk）
第二层：统计和启发式清洗
重复内容去重：不只是完全重复，还要做相似度去重（MinHash或Embedding相似度>0.95的文档块去重）。企业文档里同一段内容出现在多个文档里的情况非常普遍
短行/乱码过滤：过滤掉长度过短（少于5个字且无实质含义）、乱码比例高（特殊字符比例超过30%）的段落
水印文字：常见水印文字（“机密”、“内部资料”、下载站点URL）用关键词+位置特征过滤
第三层：大模型清洗（精准但贵，只对规则处理不了的内容用）
规则搞不定的内容才请大模型出手，而且不是全量跑：
复杂排版残留的噪声：比如表格解析后残留的错位文字、OCR后残留的碎片化乱码
语义层面的去重和合并：相邻的语义重复但字面不完全相同的段落
关键文档的精细清洗：合同条款、规章制度等核心知识，大模型清洗后再人工抽检
不建议用大模型清页眉页脚的原因：
成本太高。1000页文档，每页都调一次大模型，费用和时间都不划算
杀鸡用牛刀。页眉页脚是结构性噪声，规则和版面分析识别准确率已经很高（95%+）
误伤风险。大模型可能把正文里的重要内容误判为页头页脚删掉
速度太慢。规则处理毫秒级，大模型处理每秒几个请求，大批量文档根本跑不动
清洗完成后的质量检查：随机抽5%~10%的文档人工过一遍，检查是否有重要内容被误删、噪声是否清理干净。清洗是个迭代过程，发现新模式的噪声就加规则，直到抽检质量达标。
问题七：出现过幻觉吗？怎么治理？
问题分析：
幻觉不是大模型的bug，是它的生成机制决定的——模型本质是在预测"下一个最可能的token"，而不是在"陈述事实"。RAG能大幅减少幻觉，但不能完全消除。我在企业客服、合同问答、医疗咨询几个场景都遇到过幻觉问题，总结下来幻觉分三种类型，每种的成因和治理方法完全不同，混在一起治是治不好的。
答案：
先分类，再对症下药：
类型一：知识滞后型幻觉
模型用训练数据里的旧知识回答新问题。比如产品已经下架了还在推荐、旧政策已经作废还在引用、活动结束了还说能参与。
治理方法：
知识时效管理：入库文档打时间标签，定期自动识别长期未更新的内容，过期知识降权或归档
RAG检索时加入时间衰减因子，优先召回最新版本的文档
核心业务维护一份FAQ标准答案库，统一口径，优先级高于通用文档检索
建立知识更新机制：业务规则变更时主动触发知识库更新，不要等用户问错了才发现
类型二：脑补编造型幻觉（危害最大）
知识库没有相关内容，但模型强行编造。私自承诺退款时效、编造不存在的产品功能、虚构客服权限。
治理方法：
强制拒答机制：检索置信度低于阈值时，不允许模型自由发挥，直接走兜底话术（“抱歉，在知识库中没有找到相关信息，建议您联系人工客服”）
三层防错架构：
知识层：清洗过期、矛盾、重复内容，保证库里没有错误知识
推理层：强制先检索后作答，用固定思维链锁死回答路径，禁止跨场景混用知识
输出层：主模型生成+校验模型审核的双模型结构，另一个模型检查回答里的事实是否都有上下文支撑
提示词强约束：明确告诉模型"只根据提供的资料回答，资料里没有的内容明确说不知道，不猜测、不推断、不补充你知道的相关信息"
类型三：逻辑推理型幻觉（最难排查）
知识库里有正确内容，但模型用错了。把A产品的规则套到B产品、把普通用户的权益给了VIP、把特例当通用规则、颠倒流程顺序。这类幻觉最隐蔽，因为回答里每个字都能在知识库里找到出处，只是组合错了。
治理方法：
Rerank阶段严格筛选，不要把不相关的片段塞给模型，上下文越杂越容易混
复杂问题做子问题拆解，分步检索、分步回答，降低单次推理复杂度
结构化输出：要求模型先列出引用的知识片段编号，再给出答案，方便校验
关键场景（金融、医疗、合规）加规则引擎硬校验，模型输出后用业务规则检查是否违反硬性约束（退款时限不超过X天、赔付比例不超过Y%）
一个非常有效的手段：溯源引用
要求模型的每个关键事实陈述都标注来源chunk编号。这样做有三个好处：
模型自己在标注引用时会"自我检查"，没有来源的话它自己会发现
方便人工审核和用户验证（点击引用跳转到原文）
出现错误时可以快速定位是检索问题还是生成问题
幻觉治理没有银弹，目标不是降到0（几乎不可能），而是降到业务可接受的范围内（通常要求<10%，强监管场景<5%），并且对严重错误（金额错误、合规错误）有硬拦截机制。
问题八：提示词写了"根据检索内容回答"但模型仍编造，怎么解决？
问题分析：
这是做RAG的人几乎都会遇到的问题。“请根据以下检索内容回答问题"这句提示词，约束力非常弱——模型并没有真正被"锁住”，它仍然倾向于用自己的知识补充、润色甚至覆盖检索内容，尤其是当检索内容不完整、有噪声、或者和模型已有知识冲突的时候。这不是提示词写得不够多，而是约束方式不对。
答案：
光说"根据检索内容回答"是不够的，你需要从结构约束、行为约束、校验机制三个层面同时上锁：
- 把软约束变成硬约束——结构化提示词模板
不要只写一句模糊的指令，要给出明确的行为规则和输出格式：
你是一个专业的{domain}领域知识助手。请严格遵守以下规则回答用户问题：【核心规则】1. 你只能使用【检索资料】中的信息回答，不允许使用你自己的知识2. 如果检索资料中没有相关信息，必须明确回复"根据现有资料无法回答该问题"，不得猜测或编造3. 回答中的每一个事实性陈述，都必须标注对应的资料来源编号[1][2]4. 不得回答检索资料范围之外的问题，不得对资料内容进行延伸推断5. 如果检索资料之间存在矛盾，以发布时间更新的资料为准，并告知用户存在信息冲突【检索资料】{context}【用户问题】{question}【输出格式】答案：（基于检索资料的简洁回答）引用来源：[1][3]（标注使用了哪些资料片段）置信度：高/中/低（高=资料明确覆盖；中=资料部分覆盖；低=资料不足，建议咨询人工）
关键区别在于：你给了模型明确的拒答触发条件（“资料中没有→必须说无法回答”）和可检验的输出格式（必须标引用、必须标置信度），而不是一句模糊的"根据资料回答"。
- 加一层前置判断——先判断能不能答，再答
在生成答案之前，先让模型做一个判断任务：
请先判断：以下检索资料是否足以回答用户的问题？- 如果资料完全覆盖问题所需信息 → 可以回答- 如果资料只覆盖部分信息 → 回答能回答的部分，明确标注哪些信息缺失- 如果资料与问题无关或信息不足 → 直接回复无法回答，不要生成答案只输出一个字：是/否
这一步看起来多了一次模型调用，但对抑制幻觉效果非常明显。模型在被要求"先判断再回答"时，会更审慎地评估信息是否充分，而不是上来就开始发挥。
- 检索质量兜底——解决"资料不够好所以模型发挥"的问题
很多时候模型编造，是因为你给它的资料确实不够或者不对：
Rerank必须加。向量检索Top20里真正相关的可能只有35条，用Rerank模型精排后取Top35，噪声少了模型不容易被带偏
混合检索。纯向量检索对专有名词、产品型号、数字的命中率低，必须加BM25关键词检索，两路结果融合
查询改写。用户的口语化问题先改写成适合检索的标准问题表达，再去检索，召回质量提升明显
- 输出后校验——再加一道保险
生成答案后，用一个校验prompt（可以用同一个模型，也可以用更小更快的模型）检查：
请判断以下回答是否完全由检索资料支撑：- 回答中的每个事实陈述，是否都能在检索资料中找到直接依据？- 是否存在检索资料中没有提到的信息？- 是否存在与检索资料矛盾的内容？只输出：通过/不通过，如果不通过，指出哪些内容无依据。
不通过的回答直接拒绝输出，走兜底话术。
- 一个反直觉但有效的技巧：把"允许使用自身知识"的口子彻底关死
很多提示词会写"优先使用检索资料，资料不足时可以结合常识"——这句话就是给模型开了编造的口子。模型对"不足"的判断标准和你完全不一样，它觉得资料不够完整就开始自己补。在严肃的业务场景里（客服、合规、医疗），直接把这条路堵死：资料不足就拒答，不要给它"补充"的机会。拒答不可怕，答错才可怕。
问题九：RAG质量怎么测试？能不能上线？
问题分析：
“我问了10个问题，看起来都答对了，可以上线了吧？”——这是最危险的想法。10个问题覆盖不了真实场景，“看起来对"不等于"事实对”，没测拒答场景（不该答的硬答了），没测边界情况，没有量化指标就无法跟踪优化效果，也无法在后续迭代中做回归测试。RAG上线前必须有一套系统化的评估体系。
答案：
我的RAG评估框架分三层，六个核心指标，外加一套上线检查清单：
一、先构建靠谱的测试集
这是评估的基础，测试集质量决定评估结果是否可信：
样本量：至少200~500条问答对，覆盖核心业务场景
样本分布：要和真实用户query的分布一致——包括简单问题、复杂问题、模糊问题、多跳问题
必须包含应拒答样本（占20%~30%）：知识库中没有答案的问题、超出范围的问题，测试模型会不会硬答
标注标准答案和相关chunk：每个问题标注标准答案包含哪些信息点，以及知识库里哪些chunk是相关的
来源：优先用真实用户历史问题，其次是业务专家出题，不要全靠模型生成测试题
二、六个核心指标（必须全部达标才能考虑上线）
| 指标 | 含义 | 达标标准 | 不达标说明什么 |
|---|---|---|---|
| Hit Rate@3 | Top3检索结果中至少包含1个相关片段的比例 | ≥90% | 检索有问题，相关内容根本没找到 |
| MRR | 第一个相关结果的平均倒数排名 | ≥0.75 | 排序有问题，正确内容排太后 |
| Context Recall | 标准答案的信息点被检索上下文覆盖的比例 | ≥85% | 召回不全，有信息遗漏 |
| Faithfulness（忠实度） | 生成答案中的事实可被上下文验证的比例 | ≥90%（强监管≥95%） | 幻觉问题，模型在编造 |
| Refusal Accuracy（拒答准确率） | 应该拒答的问题正确拒答的比例 | ≥95% | 模型在不该回答的时候乱答 |
| Answer Correctness（答案正确率） | 端到端回答正确的比例 | ≥85% | 整体效果 |
记忆口诀：召回九成排名七成五，拒答九成五忠实九成，答案正确八成五。
三、评估方法
检索层指标（Hit Rate、MRR、Context Recall）：可以自动计算，基于你标注的相关chunk
生成层指标（Faithfulness、Answer Correctness）：用"LLM-as-Judge"自动评估+人工抽检结合。让一个强模型（GPT-4级别）判断答案的事实正确性，再抽20%~30%人工复核
拒答准确率：在专门的负样本集上测，这个指标是红线——该拒答不拒答，在业务场景里就是事故
四、上线前最后检查清单
[ ] 六个核心指标全部达标
[ ] 在真实用户灰度流量上跑过至少1周，收集bad case迭代过至少一轮
[ ] 压测通过：目标并发下P99延迟满足业务要求，无OOM、无服务崩溃
[ ] 有bad case回流机制：用户点"踩"或人工质检发现错误，能进入迭代队列
[ ] 有人工兜底通道：置信度低的问题自动转人工，不是所有问题都硬答
[ ] 监控告警：命中率骤降、拒答率异常升高、延迟飙升都有告警
[ ] 灰度发布：先切5%流量，观察无误再逐步放量
能不能上线的判断标准：
不是看"答对了多少"，而是看**“答错的后果有多严重，以及你有没有兜底机制”**。
内部知识问答场景（员工查制度、查文档）：幻觉率<15%，有明显错误能被用户识别纠正，可以上线
客户服务场景：幻觉率<10%，关键信息（金额、时限、规则）准确率>95%，不自动承诺任何具体赔付/退款，可以上线
强监管场景（医疗、金融投资、法律）：必须有双人复核或人工最终确认，RAG只做辅助建议，不能直接面向终端用户输出结论
2026年AI行业最大的机会，毫无疑问就在应用层！
字节跳动已有7个团队全速布局Agent
大模型岗位暴增69%，年薪破百万！
腾讯、京东、百度开放招聘技术岗，80%与AI相关……
如今，超过60%的企业都在推进AI产品落地，而真正能交付项目的大模型应用开发工程师**，**却极度稀缺！
落地AI应用绝对不是写几个prompt，调几个API就能搞定的，企业真正需要的，是能搞定这三项核心能力的人：
✅RAG：融入外部信息，修正模型输出，给模型装靠谱大脑
✅Agent智能体：让AI自主干活，通过工具调用（Tools）环境交互，多步推理完成复杂任务。比如做智能客服等等……
✅微调：针对特定任务优化，让模型适配业务
目前，脉脉上有超过1000家企业发布大模型相关岗位，人工智能岗平均月薪7.8w！实习生日薪高达4000！远超其他行业收入水平！
技术的稀缺性，才是你「值钱」的关键！
具备AI能力的程序员，比传统开发高出不止一截！有的人早就转行AI方向，拿到百万年薪！👇🏻👇🏻
AI浪潮，正在重构程序员的核心竞争力！现在入场，仍是最佳时机！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
⭐️从大模型微调到AI Agent智能体搭建
剖析AI技术的应用场景，用实战经验落地AI技术。从GPT到最火的开源模型，让你从容面对AI技术革新！
大模型微调
掌握主流大模型（如DeepSeek、Qwen等）的微调技术，针对特定场景优化模型性能。
学习如何利用领域数据（如制造、医药、金融等）进行模型定制，提升任务准确性和效率。
RAG应用开发
- 深入理解检索增强生成（Retrieval-Augmented Generation, RAG）技术，构建高效的知识检索与生成系统。
- 应用于垂类场景（如法律文档分析、医疗诊断辅助、金融报告生成等），实现精准信息提取与内容生成。
AI Agent智能体搭建
- 学习如何设计和开发AI Agent，实现多任务协同、自主决策和复杂问题解决。
- 构建垂类场景下的智能助手（如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等）。
如果你也有以下诉求：
快速链接产品/业务团队，参与前沿项目
构建技术壁垒，从竞争者中脱颖而出
避开35岁裁员危险期，顺利拿下高薪岗
迭代技术水平，延长未来20年的新职业发展！
……
那这节课你一定要来听！
因为，留给普通程序员的时间真的不多了！
立即扫码，即可免费预约
「AI技术原理 + 实战应用 + 职业发展」
「大模型应用开发实战公开课」
👇👇
👍🏻还有靠谱的内推机会+直聘权益！！
完课后赠送：大模型应用案例集、AI商业落地白皮书
