企业官网建设流程全解析

做过大模型落地项目的人都知道，Demo能跑通和真正上线之间，隔着无数个让人头秃的深夜。这篇整理了后台被问得最多的九个问题——从部署框架选型到幻觉治理，从PDF解析到RAG评测，每一条都是真金白银踩过坑之后沉淀下来的答案。

问题一：模型怎么部署的？

问题分析：

很多人对大模型部署的认知还停留在"pip install transformers，然后写个FastAPI包一层"这个阶段。说实话，这个方案在demo阶段完全够用，但一旦上了生产环境，要扛并发、要控成本、要保证稳定性，差距就出来了。自己手写推理服务，最大的问题是连续批处理（continuous batching）和KV Cache的显存管理——这两件事做不好，GPU利用率上不去，并发一高就OOM，单卡能服务的用户数能差出一个数量级。

答案：

推理引擎直接站在巨人肩膀上，别自己造轮子。2026年的主流选择就那几个，按场景挑：

我的生产环境选型经验：

默认选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多大合适？通用场景512_{1024个token（中文大约300}600字）是比较稳的区间。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的人几乎都会遇到的问题。“请根据以下检索内容回答问题"这句提示词，约束力非常弱——模型并没有真正被"锁住”，它仍然倾向于用自己的知识补充、润色甚至覆盖检索内容，尤其是当检索内容不完整、有噪声、或者和模型已有知识冲突的时候。这不是提示词写得不够多，而是约束方式不对。

答案：

光说"根据检索内容回答"是不够的，你需要从结构约束、行为约束、校验机制三个层面同时上锁：

1. 把软约束变成硬约束——结构化提示词模板

不要只写一句模糊的指令，要给出明确的行为规则和输出格式：

你是一个专业的{domain}领域知识助手。请严格遵守以下规则回答用户问题：【核心规则】1. 你只能使用【检索资料】中的信息回答，不允许使用你自己的知识2. 如果检索资料中没有相关信息，必须明确回复"根据现有资料无法回答该问题"，不得猜测或编造3. 回答中的每一个事实性陈述，都必须标注对应的资料来源编号[1][2]4. 不得回答检索资料范围之外的问题，不得对资料内容进行延伸推断5. 如果检索资料之间存在矛盾，以发布时间更新的资料为准，并告知用户存在信息冲突【检索资料】{context}【用户问题】{question}【输出格式】答案：（基于检索资料的简洁回答）引用来源：[1][3]（标注使用了哪些资料片段）置信度：高/中/低（高=资料明确覆盖；中=资料部分覆盖；低=资料不足，建议咨询人工）

关键区别在于：你给了模型明确的拒答触发条件（“资料中没有→必须说无法回答”）和可检验的输出格式（必须标引用、必须标置信度），而不是一句模糊的"根据资料回答"。

2. 加一层前置判断——先判断能不能答，再答

在生成答案之前，先让模型做一个判断任务：

请先判断：以下检索资料是否足以回答用户的问题？- 如果资料完全覆盖问题所需信息 → 可以回答- 如果资料只覆盖部分信息 → 回答能回答的部分，明确标注哪些信息缺失- 如果资料与问题无关或信息不足 → 直接回复无法回答，不要生成答案只输出一个字：是/否

这一步看起来多了一次模型调用，但对抑制幻觉效果非常明显。模型在被要求"先判断再回答"时，会更审慎地评估信息是否充分，而不是上来就开始发挥。

3. 检索质量兜底——解决"资料不够好所以模型发挥"的问题

很多时候模型编造，是因为你给它的资料确实不够或者不对：

Rerank必须加。向量检索Top20里真正相关的可能只有3_{5条，用Rerank模型精排后取Top3}5，噪声少了模型不容易被带偏

混合检索。纯向量检索对专有名词、产品型号、数字的命中率低，必须加BM25关键词检索，两路结果融合

查询改写。用户的口语化问题先改写成适合检索的标准问题表达，再去检索，召回质量提升明显

4. 输出后校验——再加一道保险

生成答案后，用一个校验prompt（可以用同一个模型，也可以用更小更快的模型）检查：

请判断以下回答是否完全由检索资料支撑：- 回答中的每个事实陈述，是否都能在检索资料中找到直接依据？- 是否存在检索资料中没有提到的信息？- 是否存在与检索资料矛盾的内容？只输出：通过/不通过，如果不通过，指出哪些内容无依据。

不通过的回答直接拒绝输出，走兜底话术。

5. 一个反直觉但有效的技巧：把"允许使用自身知识"的口子彻底关死

很多提示词会写"优先使用检索资料，资料不足时可以结合常识"——这句话就是给模型开了编造的口子。模型对"不足"的判断标准和你完全不一样，它觉得资料不够完整就开始自己补。在严肃的业务场景里（客服、合规、医疗），直接把这条路堵死：资料不足就拒答，不要给它"补充"的机会。拒答不可怕，答错才可怕。

问题九：RAG质量怎么测试？能不能上线？

问题分析：

“我问了10个问题，看起来都答对了，可以上线了吧？”——这是最危险的想法。10个问题覆盖不了真实场景，“看起来对"不等于"事实对”，没测拒答场景（不该答的硬答了），没测边界情况，没有量化指标就无法跟踪优化效果，也无法在后续迭代中做回归测试。RAG上线前必须有一套系统化的评估体系。

答案：

我的RAG评估框架分三层，六个核心指标，外加一套上线检查清单：

一、先构建靠谱的测试集

这是评估的基础，测试集质量决定评估结果是否可信：

样本量：至少200~500条问答对，覆盖核心业务场景

样本分布：要和真实用户query的分布一致——包括简单问题、复杂问题、模糊问题、多跳问题

必须包含应拒答样本（占20%~30%）：知识库中没有答案的问题、超出范围的问题，测试模型会不会硬答

标注标准答案和相关chunk：每个问题标注标准答案包含哪些信息点，以及知识库里哪些chunk是相关的

来源：优先用真实用户历史问题，其次是业务专家出题，不要全靠模型生成测试题

二、六个核心指标（必须全部达标才能考虑上线）

记忆口诀：召回九成排名七成五，拒答九成五忠实九成，答案正确八成五。

三、评估方法

检索层指标（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只做辅助建议，不能直接面向终端用户输出结论

最后说一句：RAG系统上线不是终点，是持续运营的起点。上线后要持续收集bad case，迭代切片策略、补充知识库、优化提示词，系统质量是在运营中不断提升的，不是上线时就完美的。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】