尧图网站建设 
简介《大模型典型示范应用案例集》是一份面向大模型从业者、企业技术决策者与高校研究者的行业案例资料聚焦大模型在金融、医疗、教育、制造、汽车等领域的落地实践帮助读者理解技术选型与场景适配思路。资源为单个PDF文件压缩包约84.49MB内容按参编单位首字拼音排序收录了阿里云、百度、华为、腾讯、商汤、复旦大学附属中山医院、国泰君安等众多机构提交的示范案例覆盖智能问答、知识管理、医疗辅助、工业质检、内容生成等方向。案例集以真实业务场景为线索呈现问题定义、技术方案与实施效果便于读者对照自身业务寻找可借鉴的路径。目前已有146人学习下载适合需要了解大模型行业应用全貌、撰写方案或开展课题研究的人员参考。1. 大模型典型示范应用案例集从“能跑通”到“能交付”的最后一公里很多团队在 2024 年都做过同一件事拿一个开源大模型套上 LangChain 或 Coze接一个向量库跑出一个能问答的 Demo然后兴冲冲地拿去给业务方看。结果业务方问了三个问题就冷场了——“这个回答错了怎么办”“并发上来会不会崩”“数据从哪来、存哪去”Demo 和可交付系统之间的差距就是所谓“大模型典型示范应用案例集”真正要解决的东西。它不是一份罗列“某某公司用了大模型”的新闻稿而是一套把 RAG、AI Agent、智能体、大模型微调这些热词背后的工程约束讲清楚的参照系。你如果是正在做 AI Agent 搭建、RAG 知识库落地、或者被老板要求“两周内出个大模型应用”的一线工程师这篇笔记就是把我踩过的坑按案例类型拆开讲一遍让你少走几个通宵。2. 案例集里最常出现的三类应用RAG、Agent、微调到底怎么选2.1 先分清 RAG、Agent、微调各自解决什么问题“大模型典型示范应用案例集”里翻来覆去就是三类检索增强生成RAG、AI Agent智能体、大模型微调。很多人一上来就问“哪个方案最好”这问题本身就问错了。它们解决的是不同层次的问题。RAG 解决的是“模型不知道你的私有知识”。比如公司内部的产品手册、工单记录、专利文档模型训练时没见过你问它它只能编。RAG 的做法是把这些文档切片、向量化、存进知识库用户提问时先检索出相关片段再塞进提示词让模型基于片段回答。它的核心价值是知识可更新、可溯源改一条文档不用重新训练模型。AI Agent 解决的是“模型只会说不会做”。一个智能体不只是回答问题它要能调用工具——查数据库、发请求、写文件、操作浏览器。比如“帮我查一下上周的销售数据并生成报表”这需要 Agent 规划步骤、调用 SQL 工具、再调用图表工具。Agent 的核心是任务分解和工具编排。大模型微调解决的是“模型风格不对或领域术语不熟”。比如你要做一个医疗问答通用模型回答太口语化或者对某些专业缩写理解不准这时候用几千条标注数据做 LoRA 微调让模型学会这个领域的说话方式。微调不擅长注入新知识那还是 RAG 的活它擅长调整行为和格式。选型判断很简单知识频繁变→RAG需要执行操作→Agent输出格式或术语总不对→微调。实际项目里三者经常组合比如 Agent 调用 RAG 检索RAG 的生成模型是微调过的。2.2 用 LangChain4j 搭一个最小 RAG 案例的完整步骤下面这个案例是我在 Java 技术栈里最常用的组合LangChain4j 本地向量库 通义千问 API。选 LangChain4j 是因为很多企业后端是 Spring Boot不想为了一个 RAG 再起一个 Python 服务。如果你用 Python逻辑一样换成 LangChain 即可。第一步引入依赖。Maven 里加这几个dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-dashscope/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-easy-rag/artifactId version0.35.0/version /dependency第二步加载文档并构建知识库。Easy RAG 模块把切片、向量化、存储都封装好了适合快速验证// 指定文档目录支持 pdf、txt、md ListDocument documents FileSystemDocumentLoader.loadDocuments(/data/knowledge); // 用内存向量库做演示生产环境换成 PgVector 或 Milvus EmbeddingStoreTextSegment embeddingStore new InMemoryEmbeddingStore(); // 自动切片并向量化切片大小默认 300 token EmbeddingStoreIngestor.ingest(documents, embeddingStore); // 构建检索器每次取最相关的 5 个片段 ContentRetriever retriever EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .maxResults(5) .minScore(0.7) // 相似度低于 0.7 的丢弃防止无关内容干扰 .build();第三步组装 AI Service 并调用interface Assistant { String chat(String userMessage); } Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(DashScopeChatModel.builder() .apiKey(System.getenv(DASHSCOPE_API_KEY)) .modelName(qwen-plus) .build()) .contentRetriever(retriever) .build(); String answer assistant.chat(我们产品的退款政策是什么); System.out.println(answer);逻辑说明EmbeddingStoreIngestor.ingest内部做了三件事——按段落切片、调用 embedding 模型把每片转成向量、存入向量库。maxResults5表示每次检索返回 5 个最相似片段这个值太小会漏信息太大会让提示词超长且引入噪声5 是我在大多数文档问答场景下的起点。minScore0.7是相似度阈值低于它的片段直接丢弃避免模型被无关内容带偏。这个阈值需要根据你的 embedding 模型调整通义千问的 text-embedding-v2 一般在 0.65 到 0.75 之间比较合适。参数怎么改如果你的文档很长比如技术手册把切片大小从 300 调到 500 到 800同时把maxResults降到 3避免提示词过长。如果发现回答总是漏掉关键信息先把minScore降到 0.6 试试再检查切片是否把关键段落切断了。2.3 一个 Agent 案例让智能体自动查数据库并生成周报Agent 的最小可用案例我一般用“自然语言转 SQL 再生成报表”来演示。这个场景在内部工具里需求最多而且能同时展示工具调用和任务规划。from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain_community.utilities import SQLDatabase from langchain_openai import ChatOpenAI # 连接只读数据库生产环境务必用只读账号 db SQLDatabase.from_uri(mysql://readonly:passlocalhost/sales) tool def query_sales(sql: str) - str: 执行 SQL 查询并返回结果只允许 SELECT if not sql.strip().lower().startswith(select): return 只允许查询操作 return db.run(sql) tool def generate_chart(data: str) - str: 根据数据生成图表描述 # 实际项目里这里调用 matplotlib 或前端图表库 return f已生成图表数据摘要{data[:200]} tools [query_sales, generate_chart] llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, max_iterations5) result executor.invoke({ input: 查一下上周每个销售区域的订单总额并生成图表 }) print(result[output])逻辑说明create_react_agent用的是 ReAct 模式——模型先思考需要什么信息然后选择工具观察结果再决定下一步。max_iterations5是防止 Agent 陷入死循环的保险丝超过 5 步就强制停止。query_sales工具里做了 SQL 前缀检查这是最基本的安全兜底生产环境还应该加表名白名单和行数限制。参数怎么改temperature0是 Agent 场景的必须设置任何创造性都会导致工具调用参数不稳定。max_iterations根据任务复杂度调整查数据库生成报表一般 3 到 5 步够用如果是多表关联加图表再加邮件发送可以放到 8。3. 把案例跑起来之前环境、模型和数据的三个前置决策3.1 模型选型API 调用还是本地部署这是每个案例开始前必须回答的问题。我的判断标准就两条数据敏感度和调用量。数据不能出内网→本地部署。用 vLLM 或 Ollama 跑 Qwen2.5-7B 或 GLM-4-9B一张 24G 显存的卡比如 4090用 4bit 量化能跑 7B 模型吞吐大概每秒 20 到 40 个 token。如果并发要求高上 vLLM 的 PagedAttention同样硬件能撑到 3 到 5 倍吞吐。数据可以出内网、调用量不大→直接用 API。通义千问、DeepSeek、智谱都有免费额度或低价档qwen-plus 大概每百万 token 几块钱做 Demo 和中小规模生产完全够。好处是省去运维坏处是延迟受网络影响而且要注意 API 的并发限制——很多免费档 QPS 只有 1 到 3做压测时容易翻车。混合方案也常见敏感数据走本地小模型做初筛非敏感走 API 做高质量生成。3.2 向量库选型内存、PgVector 还是 MilvusRAG 案例绕不开向量库。我的经验是按数据量和团队技术栈选方案适用数据量优点坑InMemory1 万条以下零依赖启动快重启丢数据不能多进程PgVector10 万到 500 万复用现有 PG支持 SQL 过滤索引构建慢需要调 HNSW 参数Milvus500 万以上分布式性能强运维复杂小团队扛不住Chroma10 万以下轻量Python 友好生产稳定性一般大多数企业案例其实用 PgVector 就够了因为业务数据本来就在 PG 里做元数据过滤时可以直接 JOIN不用在向量库和业务库之间同步。Milvus 适合真正的大规模场景但如果你团队没有专职运维别碰。3.3 文档切片最容易被低估的一步切片策略直接决定 RAG 的上限。我见过太多案例是模型没问题、向量库没问题就是切片把关键信息切断了导致检索永远找不到正确片段。常见做法是按 token 数切比如 300 到 500 token 一片重叠 50 token。但更好的做法是按语义切——用 LangChain 的RecursiveCharacterTextSplitter它优先按段落切段落太长再按句子切最后才按字符切。对于技术文档我还会保留标题层级把标题和内容拼在一起再向量化这样检索时能带上上下文。提示切片后一定要人工抽查 20 到 30 个片段看看有没有把表格切断、把代码块切碎、把问答对拆散。这一步花 10 分钟能省后面几小时的调试。4. 案例落地时最容易翻车的五个地方4.1 检索结果明明相关模型却说“不知道”现象用户问了一个知识库里有明确答案的问题检索也返回了正确片段但模型回答“根据现有信息无法回答”。原因提示词里没有明确要求模型“必须基于检索内容回答”或者检索片段被放在了提示词的末尾模型注意力被前面的系统提示分散了。另一个常见原因是minScore设太高相关片段被过滤掉了。解决把检索内容放在用户问题之前并用明确的分隔符标记。提示词模板改成“以下是与问题相关的资料\n---\n{context}\n---\n请严格基于以上资料回答问题如果资料中没有答案直接说不知道。”同时把minScore降到 0.6 再测。4.2 Agent 调用工具时参数格式总是错现象Agent 决定调用query_sales但传进去的 SQL 是自然语言而不是合法 SQL或者日期格式不对。原因工具的 description 写得太模糊模型不知道参数应该是什么格式。或者工具参数没有类型约束模型自由发挥。解决在tool的 docstring 里写清楚参数格式最好给一个示例。比如“sql: 合法的 MySQL SELECT 语句例如 SELECT SUM(amount) FROM orders WHERE date 2024-01-01”。如果框架支持 Pydantic 参数模型一定要用让模型知道每个字段的类型和约束。4.3 并发一上来就超时或报 429现象单次调用没问题用 JMeter 压到 10 并发就开始大量超时或者 API 返回 429 Too Many Requests。原因API 档位 QPS 限制、本地模型显存不够导致排队、向量库检索没有加缓存。解决第一确认 API 的 QPS 上限在客户端加令牌桶限流超出部分排队而不是直接失败。第二本地部署时用 vLLM 的 continuous batching别用 HuggingFace 默认的串行推理。第三对高频相同问题加一层 Redis 缓存直接返回上次的答案能挡掉 30% 到 50% 的重复请求。4.4 微调后模型变“傻”了现象用 LoRA 微调后模型在训练集上表现很好但通用能力下降问它简单问题都答不好。原因学习率太高、训练轮数太多、数据量太少导致过拟合。LoRA 的 rank 设太大也会让模型过度适应训练数据。解决LoRA 的 rank 从 8 开始试学习率用 1e-4 到 2e-4训练 2 到 3 轮就停。数据量至少 1000 条以上而且要混入 10% 到 20% 的通用指令数据防止灾难性遗忘。每次微调后都要在保留的验证集上测通用能力下降了就回退。4.5 知识库更新后检索结果没变化现象明明更新了文档重新上传了但用户提问还是返回旧答案。原因向量库里的旧向量没有删除新文档和旧文档同时存在检索时旧片段得分更高。或者 embedding 缓存没失效。解决更新文档时先按文档 ID 删除旧向量再插入新向量。如果用 PgVector给文档 ID 建索引删除时用DELETE FROM embeddings WHERE document_id ?。另外检查 embedding 模型是否有缓存层有的话要清掉对应 key。5. 让案例集真正可复用的两个进阶技巧5.1 用评估集把“感觉还行”变成“量化达标”大部分案例做完就完了没人知道它到底好不好。我的习惯是每个 RAG 或 Agent 案例都配一个 50 到 100 条的小评估集每条包含问题、标准答案、必须命中的关键词。跑完自动算三个指标检索命中率正确片段是否在 top5 里、答案准确率关键词是否全部出现、拒答率该说不知道的时候有没有瞎编。# 极简评估脚本不依赖任何评估框架 test_cases [ {q: 退款政策是什么, keywords: [7天, 无理由], should_answer: True}, {q: CEO的私人电话, keywords: [], should_answer: False}, ] hit, correct, refused 0, 0, 0 for case in test_cases: answer assistant.chat(case[q]) if not case[should_answer]: if 不知道 in answer or 无法 in answer: refused 1 continue if all(kw in answer for kw in case[keywords]): correct 1 print(f准确率{correct}/{len(test_cases)}拒答正确率{refused})这个脚本很糙但比没有强。每次改切片、改提示词、换模型跑一遍就知道是变好还是变坏。没有评估集的案例改参数就是玄学。5.2 把案例拆成可替换的模块别写成一坨我早期做案例喜欢把所有逻辑写在一个文件里结果换个向量库要改十几个地方。后来学乖了强制拆成四个模块文档加载器、切片器、检索器、生成器。每个模块定义接口实现可替换。这样从 InMemory 换到 PgVector 只改一个工厂方法从通义千问换到本地模型也只改一个配置。这个习惯的回报在案例集场景下特别明显——当你要对比不同方案时只需要换一个模块其他代码不动。而且新人接手时能清楚看到每个环节的输入输出不用通读全部代码。注意模块化不是过度设计。四个模块、每个模块一个接口加两三个实现代码量不大但可维护性差好几倍。我自己的教训是最早做 RAG 案例时图快所有东西塞在一个 500 行的 Python 文件里后来业务方要换向量库、要加权限过滤、要接新的模型每次改动都提心吊胆。现在不管多小的案例我都先把这四个模块的骨架搭好哪怕实现只有一行。这个习惯让我在后来做智能体案例时省了大量返工时间。希望帮到你。本文还有配套的精品资源点击获取 大模型典型示范应用案例集：RAG、Agent与微调落地实战指南
简介《大模型典型示范应用案例集》是一份面向大模型从业者、企业技术决策者与高校研究者的行业案例资料聚焦大模型在金融、医疗、教育、制造、汽车等领域的落地实践帮助读者理解技术选型与场景适配思路。资源为单个PDF文件压缩包约84.49MB内容按参编单位首字拼音排序收录了阿里云、百度、华为、腾讯、商汤、复旦大学附属中山医院、国泰君安等众多机构提交的示范案例覆盖智能问答、知识管理、医疗辅助、工业质检、内容生成等方向。案例集以真实业务场景为线索呈现问题定义、技术方案与实施效果便于读者对照自身业务寻找可借鉴的路径。目前已有146人学习下载适合需要了解大模型行业应用全貌、撰写方案或开展课题研究的人员参考。1. 大模型典型示范应用案例集从“能跑通”到“能交付”的最后一公里很多团队在 2024 年都做过同一件事拿一个开源大模型套上 LangChain 或 Coze接一个向量库跑出一个能问答的 Demo然后兴冲冲地拿去给业务方看。结果业务方问了三个问题就冷场了——“这个回答错了怎么办”“并发上来会不会崩”“数据从哪来、存哪去”Demo 和可交付系统之间的差距就是所谓“大模型典型示范应用案例集”真正要解决的东西。它不是一份罗列“某某公司用了大模型”的新闻稿而是一套把 RAG、AI Agent、智能体、大模型微调这些热词背后的工程约束讲清楚的参照系。你如果是正在做 AI Agent 搭建、RAG 知识库落地、或者被老板要求“两周内出个大模型应用”的一线工程师这篇笔记就是把我踩过的坑按案例类型拆开讲一遍让你少走几个通宵。2. 案例集里最常出现的三类应用RAG、Agent、微调到底怎么选2.1 先分清 RAG、Agent、微调各自解决什么问题“大模型典型示范应用案例集”里翻来覆去就是三类检索增强生成RAG、AI Agent智能体、大模型微调。很多人一上来就问“哪个方案最好”这问题本身就问错了。它们解决的是不同层次的问题。RAG 解决的是“模型不知道你的私有知识”。比如公司内部的产品手册、工单记录、专利文档模型训练时没见过你问它它只能编。RAG 的做法是把这些文档切片、向量化、存进知识库用户提问时先检索出相关片段再塞进提示词让模型基于片段回答。它的核心价值是知识可更新、可溯源改一条文档不用重新训练模型。AI Agent 解决的是“模型只会说不会做”。一个智能体不只是回答问题它要能调用工具——查数据库、发请求、写文件、操作浏览器。比如“帮我查一下上周的销售数据并生成报表”这需要 Agent 规划步骤、调用 SQL 工具、再调用图表工具。Agent 的核心是任务分解和工具编排。大模型微调解决的是“模型风格不对或领域术语不熟”。比如你要做一个医疗问答通用模型回答太口语化或者对某些专业缩写理解不准这时候用几千条标注数据做 LoRA 微调让模型学会这个领域的说话方式。微调不擅长注入新知识那还是 RAG 的活它擅长调整行为和格式。选型判断很简单知识频繁变→RAG需要执行操作→Agent输出格式或术语总不对→微调。实际项目里三者经常组合比如 Agent 调用 RAG 检索RAG 的生成模型是微调过的。2.2 用 LangChain4j 搭一个最小 RAG 案例的完整步骤下面这个案例是我在 Java 技术栈里最常用的组合LangChain4j 本地向量库 通义千问 API。选 LangChain4j 是因为很多企业后端是 Spring Boot不想为了一个 RAG 再起一个 Python 服务。如果你用 Python逻辑一样换成 LangChain 即可。第一步引入依赖。Maven 里加这几个dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-dashscope/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-easy-rag/artifactId version0.35.0/version /dependency第二步加载文档并构建知识库。Easy RAG 模块把切片、向量化、存储都封装好了适合快速验证// 指定文档目录支持 pdf、txt、md ListDocument documents FileSystemDocumentLoader.loadDocuments(/data/knowledge); // 用内存向量库做演示生产环境换成 PgVector 或 Milvus EmbeddingStoreTextSegment embeddingStore new InMemoryEmbeddingStore(); // 自动切片并向量化切片大小默认 300 token EmbeddingStoreIngestor.ingest(documents, embeddingStore); // 构建检索器每次取最相关的 5 个片段 ContentRetriever retriever EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .maxResults(5) .minScore(0.7) // 相似度低于 0.7 的丢弃防止无关内容干扰 .build();第三步组装 AI Service 并调用interface Assistant { String chat(String userMessage); } Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(DashScopeChatModel.builder() .apiKey(System.getenv(DASHSCOPE_API_KEY)) .modelName(qwen-plus) .build()) .contentRetriever(retriever) .build(); String answer assistant.chat(我们产品的退款政策是什么); System.out.println(answer);逻辑说明EmbeddingStoreIngestor.ingest内部做了三件事——按段落切片、调用 embedding 模型把每片转成向量、存入向量库。maxResults5表示每次检索返回 5 个最相似片段这个值太小会漏信息太大会让提示词超长且引入噪声5 是我在大多数文档问答场景下的起点。minScore0.7是相似度阈值低于它的片段直接丢弃避免模型被无关内容带偏。这个阈值需要根据你的 embedding 模型调整通义千问的 text-embedding-v2 一般在 0.65 到 0.75 之间比较合适。参数怎么改如果你的文档很长比如技术手册把切片大小从 300 调到 500 到 800同时把maxResults降到 3避免提示词过长。如果发现回答总是漏掉关键信息先把minScore降到 0.6 试试再检查切片是否把关键段落切断了。2.3 一个 Agent 案例让智能体自动查数据库并生成周报Agent 的最小可用案例我一般用“自然语言转 SQL 再生成报表”来演示。这个场景在内部工具里需求最多而且能同时展示工具调用和任务规划。from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import tool from langchain_community.utilities import SQLDatabase from langchain_openai import ChatOpenAI # 连接只读数据库生产环境务必用只读账号 db SQLDatabase.from_uri(mysql://readonly:passlocalhost/sales) tool def query_sales(sql: str) - str: 执行 SQL 查询并返回结果只允许 SELECT if not sql.strip().lower().startswith(select): return 只允许查询操作 return db.run(sql) tool def generate_chart(data: str) - str: 根据数据生成图表描述 # 实际项目里这里调用 matplotlib 或前端图表库 return f已生成图表数据摘要{data[:200]} tools [query_sales, generate_chart] llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, max_iterations5) result executor.invoke({ input: 查一下上周每个销售区域的订单总额并生成图表 }) print(result[output])逻辑说明create_react_agent用的是 ReAct 模式——模型先思考需要什么信息然后选择工具观察结果再决定下一步。max_iterations5是防止 Agent 陷入死循环的保险丝超过 5 步就强制停止。query_sales工具里做了 SQL 前缀检查这是最基本的安全兜底生产环境还应该加表名白名单和行数限制。参数怎么改temperature0是 Agent 场景的必须设置任何创造性都会导致工具调用参数不稳定。max_iterations根据任务复杂度调整查数据库生成报表一般 3 到 5 步够用如果是多表关联加图表再加邮件发送可以放到 8。3. 把案例跑起来之前环境、模型和数据的三个前置决策3.1 模型选型API 调用还是本地部署这是每个案例开始前必须回答的问题。我的判断标准就两条数据敏感度和调用量。数据不能出内网→本地部署。用 vLLM 或 Ollama 跑 Qwen2.5-7B 或 GLM-4-9B一张 24G 显存的卡比如 4090用 4bit 量化能跑 7B 模型吞吐大概每秒 20 到 40 个 token。如果并发要求高上 vLLM 的 PagedAttention同样硬件能撑到 3 到 5 倍吞吐。数据可以出内网、调用量不大→直接用 API。通义千问、DeepSeek、智谱都有免费额度或低价档qwen-plus 大概每百万 token 几块钱做 Demo 和中小规模生产完全够。好处是省去运维坏处是延迟受网络影响而且要注意 API 的并发限制——很多免费档 QPS 只有 1 到 3做压测时容易翻车。混合方案也常见敏感数据走本地小模型做初筛非敏感走 API 做高质量生成。3.2 向量库选型内存、PgVector 还是 MilvusRAG 案例绕不开向量库。我的经验是按数据量和团队技术栈选方案适用数据量优点坑InMemory1 万条以下零依赖启动快重启丢数据不能多进程PgVector10 万到 500 万复用现有 PG支持 SQL 过滤索引构建慢需要调 HNSW 参数Milvus500 万以上分布式性能强运维复杂小团队扛不住Chroma10 万以下轻量Python 友好生产稳定性一般大多数企业案例其实用 PgVector 就够了因为业务数据本来就在 PG 里做元数据过滤时可以直接 JOIN不用在向量库和业务库之间同步。Milvus 适合真正的大规模场景但如果你团队没有专职运维别碰。3.3 文档切片最容易被低估的一步切片策略直接决定 RAG 的上限。我见过太多案例是模型没问题、向量库没问题就是切片把关键信息切断了导致检索永远找不到正确片段。常见做法是按 token 数切比如 300 到 500 token 一片重叠 50 token。但更好的做法是按语义切——用 LangChain 的RecursiveCharacterTextSplitter它优先按段落切段落太长再按句子切最后才按字符切。对于技术文档我还会保留标题层级把标题和内容拼在一起再向量化这样检索时能带上上下文。提示切片后一定要人工抽查 20 到 30 个片段看看有没有把表格切断、把代码块切碎、把问答对拆散。这一步花 10 分钟能省后面几小时的调试。4. 案例落地时最容易翻车的五个地方4.1 检索结果明明相关模型却说“不知道”现象用户问了一个知识库里有明确答案的问题检索也返回了正确片段但模型回答“根据现有信息无法回答”。原因提示词里没有明确要求模型“必须基于检索内容回答”或者检索片段被放在了提示词的末尾模型注意力被前面的系统提示分散了。另一个常见原因是minScore设太高相关片段被过滤掉了。解决把检索内容放在用户问题之前并用明确的分隔符标记。提示词模板改成“以下是与问题相关的资料\n---\n{context}\n---\n请严格基于以上资料回答问题如果资料中没有答案直接说不知道。”同时把minScore降到 0.6 再测。4.2 Agent 调用工具时参数格式总是错现象Agent 决定调用query_sales但传进去的 SQL 是自然语言而不是合法 SQL或者日期格式不对。原因工具的 description 写得太模糊模型不知道参数应该是什么格式。或者工具参数没有类型约束模型自由发挥。解决在tool的 docstring 里写清楚参数格式最好给一个示例。比如“sql: 合法的 MySQL SELECT 语句例如 SELECT SUM(amount) FROM orders WHERE date 2024-01-01”。如果框架支持 Pydantic 参数模型一定要用让模型知道每个字段的类型和约束。4.3 并发一上来就超时或报 429现象单次调用没问题用 JMeter 压到 10 并发就开始大量超时或者 API 返回 429 Too Many Requests。原因API 档位 QPS 限制、本地模型显存不够导致排队、向量库检索没有加缓存。解决第一确认 API 的 QPS 上限在客户端加令牌桶限流超出部分排队而不是直接失败。第二本地部署时用 vLLM 的 continuous batching别用 HuggingFace 默认的串行推理。第三对高频相同问题加一层 Redis 缓存直接返回上次的答案能挡掉 30% 到 50% 的重复请求。4.4 微调后模型变“傻”了现象用 LoRA 微调后模型在训练集上表现很好但通用能力下降问它简单问题都答不好。原因学习率太高、训练轮数太多、数据量太少导致过拟合。LoRA 的 rank 设太大也会让模型过度适应训练数据。解决LoRA 的 rank 从 8 开始试学习率用 1e-4 到 2e-4训练 2 到 3 轮就停。数据量至少 1000 条以上而且要混入 10% 到 20% 的通用指令数据防止灾难性遗忘。每次微调后都要在保留的验证集上测通用能力下降了就回退。4.5 知识库更新后检索结果没变化现象明明更新了文档重新上传了但用户提问还是返回旧答案。原因向量库里的旧向量没有删除新文档和旧文档同时存在检索时旧片段得分更高。或者 embedding 缓存没失效。解决更新文档时先按文档 ID 删除旧向量再插入新向量。如果用 PgVector给文档 ID 建索引删除时用DELETE FROM embeddings WHERE document_id ?。另外检查 embedding 模型是否有缓存层有的话要清掉对应 key。5. 让案例集真正可复用的两个进阶技巧5.1 用评估集把“感觉还行”变成“量化达标”大部分案例做完就完了没人知道它到底好不好。我的习惯是每个 RAG 或 Agent 案例都配一个 50 到 100 条的小评估集每条包含问题、标准答案、必须命中的关键词。跑完自动算三个指标检索命中率正确片段是否在 top5 里、答案准确率关键词是否全部出现、拒答率该说不知道的时候有没有瞎编。# 极简评估脚本不依赖任何评估框架 test_cases [ {q: 退款政策是什么, keywords: [7天, 无理由], should_answer: True}, {q: CEO的私人电话, keywords: [], should_answer: False}, ] hit, correct, refused 0, 0, 0 for case in test_cases: answer assistant.chat(case[q]) if not case[should_answer]: if 不知道 in answer or 无法 in answer: refused 1 continue if all(kw in answer for kw in case[keywords]): correct 1 print(f准确率{correct}/{len(test_cases)}拒答正确率{refused})这个脚本很糙但比没有强。每次改切片、改提示词、换模型跑一遍就知道是变好还是变坏。没有评估集的案例改参数就是玄学。5.2 把案例拆成可替换的模块别写成一坨我早期做案例喜欢把所有逻辑写在一个文件里结果换个向量库要改十几个地方。后来学乖了强制拆成四个模块文档加载器、切片器、检索器、生成器。每个模块定义接口实现可替换。这样从 InMemory 换到 PgVector 只改一个工厂方法从通义千问换到本地模型也只改一个配置。这个习惯的回报在案例集场景下特别明显——当你要对比不同方案时只需要换一个模块其他代码不动。而且新人接手时能清楚看到每个环节的输入输出不用通读全部代码。注意模块化不是过度设计。四个模块、每个模块一个接口加两三个实现代码量不大但可维护性差好几倍。我自己的教训是最早做 RAG 案例时图快所有东西塞在一个 500 行的 Python 文件里后来业务方要换向量库、要加权限过滤、要接新的模型每次改动都提心吊胆。现在不管多小的案例我都先把这四个模块的骨架搭好哪怕实现只有一行。这个习惯让我在后来做智能体案例时省了大量返工时间。希望帮到你。本文还有配套的精品资源点击获取