最近整理学习路线时我最大的感受是AI与LLM工程这个方向听上去特别宏大真入门却要落到非常具体的模块上。尤其是GenAI和RAG两个词放在一起时很多人会误以为需要先推导Transformer公式再去训练一个几十亿参数的模型。其实不是。对绝大多数想把内部文档变成智能问答系统的人来说第一站是理解大语言模型的能力边界第二站是把外部知识接入模型第三站才是评估、调优和上线。这基本就是一套以RAG为核心的工程实践。如果你最近在看《AI LLM Engineering Mastery: GenAI, RAG Complete Guide》这类系统课程第一部分的实际内容往往不会太偏理论而是带着你先把一个问答系统跑起来。我建议所有刚接触这个方向的人不要急着收藏一堆模型链接先把AI、LLM、GenAI、RAG这四组词在脑子里重新排一下序。下面这篇文章按我自己的实测和踩坑顺序把从概念、最小Demo、质量指标到生产化改造的链路完整写下来。如果你正打算系统学习RAG或者已经写过简单Demo但不知道下一步怎么走可以对照这份路径补漏洞。1. 先分清AI、LLM、GenAI、RAG之间的关系1.1 AI范围最大LLM是模型而不是应用AI这个概念很早就有泛指让机器完成原本需要人类智能才能完成的任务。LLM是大语言模型是具体到“用海量文本学习语言规律”的一类模型。你可以把LLM理解成一个推理核心接收文字输出新文字。平时常说的GPT类模型、开源系列大模型都是这个层面的产物。很多初学者看到“LLM框架”这个词时会以为是某个UI界面或工具平台。其实框架的作用是帮你调用LLM、管理提示词、组织数据核心模型还是独立存在的。学习LLM工程第一件事就是不要把模型和应用混在一起。模型解决生成能力应用解决用户需求。1.2 GenAI描述能力RAG描述的是架构方案GenAI是生成式AI指的是能生成文本、图片、音频、视频这类新内容的算法体系。RAG是检索增强生成是一种解决“模型不知道你的内部知识”问题的架构方案。它让模型在回答问题前先从一个外部知识库里检索出相关片段再把片段和问题一起交给模型。把四组词放一起看层次就很清楚AI是学科范围LLM是模型形态GenAI是能力方向RAG是工程方法。它们不是四个并列的新技术。很多资料把它们频繁放在一起是因为它们刚好拼出一套完整的学习路径。1.3 应用型学习路线和算法型学习路线怎么选这个选择决定你后面几个月怎么安排时间。应用型路线重点在提示词工程、RAG、Agent、评估、部署、接口设计。优点是短期内能看到一个能演示的系统。算法型路线重点在模型结构、训练、微调、数据配比、分布式训练。需要较强的数学功底周期也长很多。对绝大多数开发者我建议先走应用型路线。不是算法不重要而是系统没有真正跑起来之前你很难理解数据、损失、收敛这些概念对最终效果的影响。1.4 学习环境准备没有GPU也能开始一个能运行Python的开发环境是底线。如果只有普通笔记本优先用云厂商模型API或者本地小模型。不要一开始就要求自己必须有一张高端显卡。内存8GB也能跑基础代码16GB或以上更舒服。如果本地想跑7B级别开源模型通常建议显存尽量在6GB以上但不是必须。软件层面建议准备好这些Python 3.10或更高版本虚拟环境工具比如venv或conda一个代码编辑器推荐VS Code若干测试文档比如PDF、TXT、Markdown环境准备好之后第一步不是下载模型而是先用一份小文档把RAG流程跑通。2. RAG为什么是GenAI应用中最该先掌握的架构2.1 解决幻觉和知识过时问题大语言模型最常被吐槽的问题之一就是幻觉模型非常自信地编造答案。幻觉的主要原因是模型训练时只见过截止到某个时间点的数据。你问它最近发生的事它只能根据“最像”的路径生成。RAG把最新数据或私有数据提前放入模型上下文模型有了参考资料胡编概率会明显下降。它不是从原理上根除了幻觉而是让模型更倾向于在给定范围内作答。这个思路简单但非常实用。2.2 解决私有数据不能进模型训练集的问题企业里最常见的场景是员工想知道合同标准怎么定、报销流程是什么、以往项目文档里有哪些结论。这些数据不会出现在公开训练集里也不能为了训练“专属模型”就把数据随便上传。RAG的检索方式不需要让模型记住这些数据只需要在查询时把相关片段作为上下文传入。效果和成本都可控这也是RAG在企业知识库场景里几乎成为标配的原因。2.3 RAG与微调的本质区别微调是改变模型权重让模型本身的行为发生变化。RAG是改变模型输入让模型看到更多相关信息。两者适用场景完全不同希望模型学会特定输出格式、特定语气、特定工具调用方式优先考虑微调。希望模型知道某个新知识或某类内部文档内容优先考虑RAG。现实项目里RAG和微调经常同时出现。比如用微调让模型习惯企业的回复风格再用RAG获取事实细节。2.4 整套RAG流程从加载到生成一个完整RAG系统至少要经历这些环节加载文档 - 解析内容 - 清洗文本 - 分块 - 向量化 - 建立索引 - 检索相关块 - 组装提示词 - 模型生成 - 返回并记录日志每一步都会影响最终质量。文档解析做得差后面的检索再好也拿不到正确答案。分块太大检索结果可能带进大量无关信息分块太小又会缺失上下文。很多新手早期只关心“模型回答好不好”忽略前面几个步骤。等你把日志打开看到模型真正接收到的上下文是什么就会发现答案不稳定多半发生在更前面的环节。3. 搭建一个最小可运行的RAG Demo3.1 最小验证目标一个文件、一个问题、一个回答实践RAG的第一步不需要搭前端也不需要接数据库。我的建议是定义一个最小目标给定一份TXT或PDF文档程序能回答一个从文档里能找到答案的问题并把检索到的文档片段打印出来。这个目标能验证三件事文档加载和解析是否正常分块和向量检索能否命中相关片段模型能否根据片段生成有效回答这三件事都正常再考虑加语义缓存、权限、Web界面都不迟。3.2 一个可参考的Python流程示意下面这段代码是流程示意具体包名要按你实际安装的框架替换。重点不是命令而是顺序。# 示意代码RAG最小流程 from loader import DocumentLoader from splitter import RecursiveCharacterSplitter from embedder import EmbeddingModel from vector_store import VectorStore from llm import ChatModel loader DocumentLoader() docs loader.load(internal_doc.pdf) splitter RecursiveCharacterSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split(docs) embedding EmbeddingModel(model_nameyour-embedding-model) vector_store VectorStore() vector_store.add(chunks, embedding) question 公司报销流程是什么 hits vector_store.search(question, top_k5) context \n\n.join([item.text for item in hits]) prompt f请根据以下资料回答问题。 资料 {context} 问题{question} llm ChatModel() answer llm.generate(prompt) print(answer)如果你用LangChain、LlamaIndex或Dify这类平台对应API会有差别但数据流向一致。先跑通数据流再深挖每步的底层细节。3.3 跑通后如何判断成功我一般会关注三个现象而不是只看最终答案。首先检索结果是否正确。如果检索出来的片段里没有正确答案模型答不上来是合理的这时候调生成参数没意义要改的是分块和向量化。其次模型是否还在凭空生成。把提示词里的上下文去掉再跑一次对比两次答案差异能大体判断模型是被RAG约束住了还是全凭记忆输出。第三运行时间和资源占用。一次调用几秒还是几十秒内存占用有没有持续上涨日志有没有反复报错。这些比单次回答质量更值得记录。第一次测试要严格限制在单文档、单问题上。不要一上来就批量处理几百个文件否则报了错你都不知道是哪个环节出的问题。注意这里不要一上来就开最大并发先用一条样例确认输入、输出和日志都正常。4. 建立RAG评估体系知识库指标和测试集4.1 检索质量Recall、Precision、MRR、NDCGRAG知识库质量首先看检索阶段能不能把正确文档找出来。常见指标包括Recall与某个问题相关的文档有多少被检索到了。Precision检索到的文档里多少是真正相关的。MRR第一个正确答案排在第几位越靠前越好。NDCG把排序权重算进去正确答案越靠前得分越高。不需要第一次就把所有指标都测一遍。可以先看召回率。如果召回率低说明分块、向量化或索引方式有问题后面重排序做得再好也救不回来。4.2 生成质量正确性、忠实度、完整性检索对了模型回答也可能跑偏。生成质量可以从三个维度看正确性答案是否和标准答案一致。忠实度答案是否严格基于检索片段不添加模型编造的信息。完整性是否覆盖问题的所有必要方面。很多团队会给每轮回答打0到5分。定期人工抽查再配合代码自动评估能形成一个比较稳定的质量基线。4.3 稳定性指标延迟、成功率、成本评估RAG系统能不能上线不能只看一个答案好不好还要持续观察P50和P95延迟多数请求和较慢请求分别耗时多少。成功率超时、空结果、非预期报错的占比。Token消耗每次问答平均消耗多少输入和输出Token。失败重试任务卡住时程序能不能自动重试还是直接崩溃。这些数据可以从日志里统计。等系统运行一段时间后再反推就能判断是否需要加缓存、升级检索或调整模型。4.4 如何搭建一个小型离线测试集一开始模型效果不理想先别急着调参数先建一个固定测试集。测试集不需要特别大30到50个问题足够。每个问题带上问题本身应该命中的文档编号或片段标准答案然后把这套测试集固定。每次修改分块策略、提示词或模型都在同一套测试集上跑一遍对比得分。分数下降就回滚分数上升再继续。这套方法不需要复杂框架用一份JSON文件记录都行。但它能避免“今天改一下感觉不错明天改一下又坏了”的玄学状态。5. 文档解析、分块与检索精度真实项目里的隐藏坑5.1 PDF解析表格、扫描件、双栏布局真实企业文档不会像样例文本那么干净。最常见的是PDF。PDF看起来格式固定内部却可能是文字流、图片、图表、扫描件。解析工具处理不好表格错位扫描件里的文字直接消失。我踩过比较典型的坑是双栏论文被按单栏顺序切语义完全断裂。遇到这种情况要先做版面分析或者转成结构化文本再切。如果必须处理扫描件先做OCR并且要提前知道OCR质量本身会引入新的变量。真实项目里的第一个排查点往往不是模型而是PDF解析结果。先用脚本把解析后的文本打印前几百字看看能少走很多弯路。5.2 分块大小和重叠度怎么设分块是RAG里最常调的一个变量没有绝对正确值。分块太小比如100个字符检索到的高相关片段可能缺失上下文模型看得懂却不知道上下文在讲什么。分块太大比如2000个字符向量化后主题被稀释检索相关性下降还容易超过模型上下文窗口。常用做法是设置500到800字符的基础大小同时加50到100字符的重叠度让相邻块语义尽量衔接。更进阶的做法是按结构切分先按章、节、标题、段落识别再在段内按长度微调。这样能最大程度保留原有语义尤其适合长文档和规范类资料。5.3 混合检索、重排序与元数据过滤只靠向量相似度检索速度确实快但对精确编号、专业缩略词和特定人名不一定友好。不少项目会把向量检索和传统关键词检索结合先召回更多候选再用重排序模型精排。这样能兼顾语义匹配和精确匹配。判断是否要加这一步一个简单的标准是检索结果经常漏掉含关键编号的文档或用户问题里有很多专有名词。如果日常文档本身很常规先不要急着加太多组件。5.4 Agentic RAG、Ontology RAG、GraphRAG这些变体该不该追当前很多资料会把RAG扩展成Agentic RAG、Ontology RAG、GraphRAG等概念。它们解决的是同一类问题普通向量检索对复杂关系和多跳问题理解不够。Agentic RAG更接近“让模型自己判断应该查哪个知识库、要不要追问、要不要调用工具”。Ontology RAG或GraphRAG则更强调实体和关系图谱适合有明确关系结构的领域。要不要追这些变体我的建议是先把标准RAG跑稳再评估问题是不是真的出在检索方式上。如果用户问题大多是“某合同金额是多少”这种单点查询没有复杂关系追热词只会增加维护成本。6. LLM工程中的关键参数精度、采样和模型选择6.1 FP32、FP16、BF16精度问题为什么重要训练和推理大模型时模型权重和激活值需要按某种数据类型存储。不同精度的区别在内存、速度和数值表达范围。FP32是单精度浮点精度高内存占用大。FP16是半精度内存和计算更快但表示范围窄训练时容易溢出。BF16是Brain浮点动态范围接近FP32尾数精度更低在分布式训练里很常用。精度选择不是简单的“越低越快”。模型经过低精度量化后可能变小变快但效果会随量化强度变化。落地时先在小验证集上对比再决定是否使用低精度。如果你主要用成熟API通常不需要自己处理这些。等遇到本地推理或微调再真正开始关心精度问题。6.2 温度、Top_P、Max_Tokens怎么调生成模型通常有一组采样参数需要关注。温度控制随机性。温度越低输出越保守稳定适合RAG问答温度越高输出越多样适合创意内容。Top_P控制候选词的概率累积范围调小一点会让输出更集中。Max_Tokens限制单次生成最大长度设置过短会截断答案设置过长会浪费响应时间。RAG场景里我一般把温度放在比较低的位置比如0到0.3Top_P按默认或略调小。先固定一组参数评估后再微调不建议频繁改。6.3 RAG和微调如何组合使用如果RAG已经解决了“模型不知道事实”的问题还需要微调吗要看是否还有别的卡点。比如模型总不按企业格式输出或者需要学会调用特定工具RAG帮不上忙微调更直接。反过来如果只是知识覆盖面不够微调成本高且更新麻烦先继续优化RAG更划算。生产系统里常见情况是RAG负责知识提示词负责格式约束微调负责更贴合团队风格的表达。先把前两者做好遇到瓶颈再考虑微调这是成本更低的优化顺序。7. 从Demo到生产RAG系统的工程化改造7.1 异步索引与任务队列Demo阶段用户传一个文档
掌握RAG与LLM工程：从概念到生产化落地的完整学习路径
最近整理学习路线时我最大的感受是AI与LLM工程这个方向听上去特别宏大真入门却要落到非常具体的模块上。尤其是GenAI和RAG两个词放在一起时很多人会误以为需要先推导Transformer公式再去训练一个几十亿参数的模型。其实不是。对绝大多数想把内部文档变成智能问答系统的人来说第一站是理解大语言模型的能力边界第二站是把外部知识接入模型第三站才是评估、调优和上线。这基本就是一套以RAG为核心的工程实践。如果你最近在看《AI LLM Engineering Mastery: GenAI, RAG Complete Guide》这类系统课程第一部分的实际内容往往不会太偏理论而是带着你先把一个问答系统跑起来。我建议所有刚接触这个方向的人不要急着收藏一堆模型链接先把AI、LLM、GenAI、RAG这四组词在脑子里重新排一下序。下面这篇文章按我自己的实测和踩坑顺序把从概念、最小Demo、质量指标到生产化改造的链路完整写下来。如果你正打算系统学习RAG或者已经写过简单Demo但不知道下一步怎么走可以对照这份路径补漏洞。1. 先分清AI、LLM、GenAI、RAG之间的关系1.1 AI范围最大LLM是模型而不是应用AI这个概念很早就有泛指让机器完成原本需要人类智能才能完成的任务。LLM是大语言模型是具体到“用海量文本学习语言规律”的一类模型。你可以把LLM理解成一个推理核心接收文字输出新文字。平时常说的GPT类模型、开源系列大模型都是这个层面的产物。很多初学者看到“LLM框架”这个词时会以为是某个UI界面或工具平台。其实框架的作用是帮你调用LLM、管理提示词、组织数据核心模型还是独立存在的。学习LLM工程第一件事就是不要把模型和应用混在一起。模型解决生成能力应用解决用户需求。1.2 GenAI描述能力RAG描述的是架构方案GenAI是生成式AI指的是能生成文本、图片、音频、视频这类新内容的算法体系。RAG是检索增强生成是一种解决“模型不知道你的内部知识”问题的架构方案。它让模型在回答问题前先从一个外部知识库里检索出相关片段再把片段和问题一起交给模型。把四组词放一起看层次就很清楚AI是学科范围LLM是模型形态GenAI是能力方向RAG是工程方法。它们不是四个并列的新技术。很多资料把它们频繁放在一起是因为它们刚好拼出一套完整的学习路径。1.3 应用型学习路线和算法型学习路线怎么选这个选择决定你后面几个月怎么安排时间。应用型路线重点在提示词工程、RAG、Agent、评估、部署、接口设计。优点是短期内能看到一个能演示的系统。算法型路线重点在模型结构、训练、微调、数据配比、分布式训练。需要较强的数学功底周期也长很多。对绝大多数开发者我建议先走应用型路线。不是算法不重要而是系统没有真正跑起来之前你很难理解数据、损失、收敛这些概念对最终效果的影响。1.4 学习环境准备没有GPU也能开始一个能运行Python的开发环境是底线。如果只有普通笔记本优先用云厂商模型API或者本地小模型。不要一开始就要求自己必须有一张高端显卡。内存8GB也能跑基础代码16GB或以上更舒服。如果本地想跑7B级别开源模型通常建议显存尽量在6GB以上但不是必须。软件层面建议准备好这些Python 3.10或更高版本虚拟环境工具比如venv或conda一个代码编辑器推荐VS Code若干测试文档比如PDF、TXT、Markdown环境准备好之后第一步不是下载模型而是先用一份小文档把RAG流程跑通。2. RAG为什么是GenAI应用中最该先掌握的架构2.1 解决幻觉和知识过时问题大语言模型最常被吐槽的问题之一就是幻觉模型非常自信地编造答案。幻觉的主要原因是模型训练时只见过截止到某个时间点的数据。你问它最近发生的事它只能根据“最像”的路径生成。RAG把最新数据或私有数据提前放入模型上下文模型有了参考资料胡编概率会明显下降。它不是从原理上根除了幻觉而是让模型更倾向于在给定范围内作答。这个思路简单但非常实用。2.2 解决私有数据不能进模型训练集的问题企业里最常见的场景是员工想知道合同标准怎么定、报销流程是什么、以往项目文档里有哪些结论。这些数据不会出现在公开训练集里也不能为了训练“专属模型”就把数据随便上传。RAG的检索方式不需要让模型记住这些数据只需要在查询时把相关片段作为上下文传入。效果和成本都可控这也是RAG在企业知识库场景里几乎成为标配的原因。2.3 RAG与微调的本质区别微调是改变模型权重让模型本身的行为发生变化。RAG是改变模型输入让模型看到更多相关信息。两者适用场景完全不同希望模型学会特定输出格式、特定语气、特定工具调用方式优先考虑微调。希望模型知道某个新知识或某类内部文档内容优先考虑RAG。现实项目里RAG和微调经常同时出现。比如用微调让模型习惯企业的回复风格再用RAG获取事实细节。2.4 整套RAG流程从加载到生成一个完整RAG系统至少要经历这些环节加载文档 - 解析内容 - 清洗文本 - 分块 - 向量化 - 建立索引 - 检索相关块 - 组装提示词 - 模型生成 - 返回并记录日志每一步都会影响最终质量。文档解析做得差后面的检索再好也拿不到正确答案。分块太大检索结果可能带进大量无关信息分块太小又会缺失上下文。很多新手早期只关心“模型回答好不好”忽略前面几个步骤。等你把日志打开看到模型真正接收到的上下文是什么就会发现答案不稳定多半发生在更前面的环节。3. 搭建一个最小可运行的RAG Demo3.1 最小验证目标一个文件、一个问题、一个回答实践RAG的第一步不需要搭前端也不需要接数据库。我的建议是定义一个最小目标给定一份TXT或PDF文档程序能回答一个从文档里能找到答案的问题并把检索到的文档片段打印出来。这个目标能验证三件事文档加载和解析是否正常分块和向量检索能否命中相关片段模型能否根据片段生成有效回答这三件事都正常再考虑加语义缓存、权限、Web界面都不迟。3.2 一个可参考的Python流程示意下面这段代码是流程示意具体包名要按你实际安装的框架替换。重点不是命令而是顺序。# 示意代码RAG最小流程 from loader import DocumentLoader from splitter import RecursiveCharacterSplitter from embedder import EmbeddingModel from vector_store import VectorStore from llm import ChatModel loader DocumentLoader() docs loader.load(internal_doc.pdf) splitter RecursiveCharacterSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split(docs) embedding EmbeddingModel(model_nameyour-embedding-model) vector_store VectorStore() vector_store.add(chunks, embedding) question 公司报销流程是什么 hits vector_store.search(question, top_k5) context \n\n.join([item.text for item in hits]) prompt f请根据以下资料回答问题。 资料 {context} 问题{question} llm ChatModel() answer llm.generate(prompt) print(answer)如果你用LangChain、LlamaIndex或Dify这类平台对应API会有差别但数据流向一致。先跑通数据流再深挖每步的底层细节。3.3 跑通后如何判断成功我一般会关注三个现象而不是只看最终答案。首先检索结果是否正确。如果检索出来的片段里没有正确答案模型答不上来是合理的这时候调生成参数没意义要改的是分块和向量化。其次模型是否还在凭空生成。把提示词里的上下文去掉再跑一次对比两次答案差异能大体判断模型是被RAG约束住了还是全凭记忆输出。第三运行时间和资源占用。一次调用几秒还是几十秒内存占用有没有持续上涨日志有没有反复报错。这些比单次回答质量更值得记录。第一次测试要严格限制在单文档、单问题上。不要一上来就批量处理几百个文件否则报了错你都不知道是哪个环节出的问题。注意这里不要一上来就开最大并发先用一条样例确认输入、输出和日志都正常。4. 建立RAG评估体系知识库指标和测试集4.1 检索质量Recall、Precision、MRR、NDCGRAG知识库质量首先看检索阶段能不能把正确文档找出来。常见指标包括Recall与某个问题相关的文档有多少被检索到了。Precision检索到的文档里多少是真正相关的。MRR第一个正确答案排在第几位越靠前越好。NDCG把排序权重算进去正确答案越靠前得分越高。不需要第一次就把所有指标都测一遍。可以先看召回率。如果召回率低说明分块、向量化或索引方式有问题后面重排序做得再好也救不回来。4.2 生成质量正确性、忠实度、完整性检索对了模型回答也可能跑偏。生成质量可以从三个维度看正确性答案是否和标准答案一致。忠实度答案是否严格基于检索片段不添加模型编造的信息。完整性是否覆盖问题的所有必要方面。很多团队会给每轮回答打0到5分。定期人工抽查再配合代码自动评估能形成一个比较稳定的质量基线。4.3 稳定性指标延迟、成功率、成本评估RAG系统能不能上线不能只看一个答案好不好还要持续观察P50和P95延迟多数请求和较慢请求分别耗时多少。成功率超时、空结果、非预期报错的占比。Token消耗每次问答平均消耗多少输入和输出Token。失败重试任务卡住时程序能不能自动重试还是直接崩溃。这些数据可以从日志里统计。等系统运行一段时间后再反推就能判断是否需要加缓存、升级检索或调整模型。4.4 如何搭建一个小型离线测试集一开始模型效果不理想先别急着调参数先建一个固定测试集。测试集不需要特别大30到50个问题足够。每个问题带上问题本身应该命中的文档编号或片段标准答案然后把这套测试集固定。每次修改分块策略、提示词或模型都在同一套测试集上跑一遍对比得分。分数下降就回滚分数上升再继续。这套方法不需要复杂框架用一份JSON文件记录都行。但它能避免“今天改一下感觉不错明天改一下又坏了”的玄学状态。5. 文档解析、分块与检索精度真实项目里的隐藏坑5.1 PDF解析表格、扫描件、双栏布局真实企业文档不会像样例文本那么干净。最常见的是PDF。PDF看起来格式固定内部却可能是文字流、图片、图表、扫描件。解析工具处理不好表格错位扫描件里的文字直接消失。我踩过比较典型的坑是双栏论文被按单栏顺序切语义完全断裂。遇到这种情况要先做版面分析或者转成结构化文本再切。如果必须处理扫描件先做OCR并且要提前知道OCR质量本身会引入新的变量。真实项目里的第一个排查点往往不是模型而是PDF解析结果。先用脚本把解析后的文本打印前几百字看看能少走很多弯路。5.2 分块大小和重叠度怎么设分块是RAG里最常调的一个变量没有绝对正确值。分块太小比如100个字符检索到的高相关片段可能缺失上下文模型看得懂却不知道上下文在讲什么。分块太大比如2000个字符向量化后主题被稀释检索相关性下降还容易超过模型上下文窗口。常用做法是设置500到800字符的基础大小同时加50到100字符的重叠度让相邻块语义尽量衔接。更进阶的做法是按结构切分先按章、节、标题、段落识别再在段内按长度微调。这样能最大程度保留原有语义尤其适合长文档和规范类资料。5.3 混合检索、重排序与元数据过滤只靠向量相似度检索速度确实快但对精确编号、专业缩略词和特定人名不一定友好。不少项目会把向量检索和传统关键词检索结合先召回更多候选再用重排序模型精排。这样能兼顾语义匹配和精确匹配。判断是否要加这一步一个简单的标准是检索结果经常漏掉含关键编号的文档或用户问题里有很多专有名词。如果日常文档本身很常规先不要急着加太多组件。5.4 Agentic RAG、Ontology RAG、GraphRAG这些变体该不该追当前很多资料会把RAG扩展成Agentic RAG、Ontology RAG、GraphRAG等概念。它们解决的是同一类问题普通向量检索对复杂关系和多跳问题理解不够。Agentic RAG更接近“让模型自己判断应该查哪个知识库、要不要追问、要不要调用工具”。Ontology RAG或GraphRAG则更强调实体和关系图谱适合有明确关系结构的领域。要不要追这些变体我的建议是先把标准RAG跑稳再评估问题是不是真的出在检索方式上。如果用户问题大多是“某合同金额是多少”这种单点查询没有复杂关系追热词只会增加维护成本。6. LLM工程中的关键参数精度、采样和模型选择6.1 FP32、FP16、BF16精度问题为什么重要训练和推理大模型时模型权重和激活值需要按某种数据类型存储。不同精度的区别在内存、速度和数值表达范围。FP32是单精度浮点精度高内存占用大。FP16是半精度内存和计算更快但表示范围窄训练时容易溢出。BF16是Brain浮点动态范围接近FP32尾数精度更低在分布式训练里很常用。精度选择不是简单的“越低越快”。模型经过低精度量化后可能变小变快但效果会随量化强度变化。落地时先在小验证集上对比再决定是否使用低精度。如果你主要用成熟API通常不需要自己处理这些。等遇到本地推理或微调再真正开始关心精度问题。6.2 温度、Top_P、Max_Tokens怎么调生成模型通常有一组采样参数需要关注。温度控制随机性。温度越低输出越保守稳定适合RAG问答温度越高输出越多样适合创意内容。Top_P控制候选词的概率累积范围调小一点会让输出更集中。Max_Tokens限制单次生成最大长度设置过短会截断答案设置过长会浪费响应时间。RAG场景里我一般把温度放在比较低的位置比如0到0.3Top_P按默认或略调小。先固定一组参数评估后再微调不建议频繁改。6.3 RAG和微调如何组合使用如果RAG已经解决了“模型不知道事实”的问题还需要微调吗要看是否还有别的卡点。比如模型总不按企业格式输出或者需要学会调用特定工具RAG帮不上忙微调更直接。反过来如果只是知识覆盖面不够微调成本高且更新麻烦先继续优化RAG更划算。生产系统里常见情况是RAG负责知识提示词负责格式约束微调负责更贴合团队风格的表达。先把前两者做好遇到瓶颈再考虑微调这是成本更低的优化顺序。7. 从Demo到生产RAG系统的工程化改造7.1 异步索引与任务队列Demo阶段用户传一个文档
