((AI篇)OpenGL渲染与几何内核那点事-(二-1-(10)：从“搜个大概”到“读懂图纸”：一个 CAD 开发者眼中的 RAG 进化简史)

@[TOC]((AI篇)OpenGL渲染与几何内核那点事-(二-1-(10)：从"搜个大概"到"读懂图纸"：一个 CAD 开发者眼中的 RAG 进化简史)

代码仓库入口：

github源码地址。
gitee源码地址。

Huhb-Viewer-AddAIHelper

系列文章规划：

OpenGL渲染与几何内核那点事-项目实践理论补充(一-1-(7)-番外篇：点击的瞬间，发生了什么？
OpenGL渲染与几何内核那点事-项目实践理论补充(一-1-(8)-番外篇：当你的 CAD 遇上"活"的零件)
OpenGL渲染与几何内核那点事-项目实践理论补充(一-2-(1)-当你的CAD想"联网"时：从单机绘图到多人实时协作)
OpenGL渲染与几何内核那点事-项目实践理论补充(一-2-(2)-当你的CAD需要处理"百万个螺栓"时：从内存爆炸到丝般顺滑)
OpenGL渲染与几何内核那点事-项目实践理论补充(一-2-(3)-当你的协同CAD服务器面临"千人同屏"时：从单机优化到分布式高并发)
OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(2):当你的CAD学会"听话"：从鼠标点击到自然语言命令)
OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(4)-当你的CAD学会"听话"：从"按钮点击"到"自然语言诊断"的演进之路
OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(4)：在你的两个AI小宠物GEMINI与TRAE的交互下，帮你实现能听懂人话并诊断模型错误的小助手)
OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(5)：在你的GEMINI和TRAE 宠物帮助下，帮你实现能听懂人话并诊断模型错误的小助手-问题总结和解决篇)【重要提示：本文依旧按照之前的风格进行表达，如果你想看看具体如何通过你的电子宠物【gemini、trae等】相互之间的交互（包括提示词、反馈结果，如果根据结果继续向AI发起追问，直至拿到你想要的结果），完成你的需求和目标，可以看看如下的两篇：】
(AI篇)OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(6)：从"硬编码"到"AI语义"，你的开源项目听懂人话了吗？------ 一个图形程序的自然语言进化史)
(AI篇)OpenGL渲染与几何内核那点事-项目实践理论补充(二-1-(8)：当你的CAD学会了"接单"：(Agent的核心机制)AI函数调用从"鸡同鸭讲"到"心想事成"的进化史)

从"搜个大概"到"读懂图纸"：一个 CAD 开发者眼中的 RAG 进化简史

老板的新点子：给 CAD 装一个"技术顾问"

你的 CAD 软件刚刚攻克了千人同屏的协同难题，AI 渲染加速也做得风生水起。

但就在你准备喝杯咖啡歇一口气的时候，老板又冲进了办公室："小 C，我们的用户都是工程师，他们画图时要不停地翻设计手册、查规范、找以前的项目案例。能不能在我们的 CAD 里做一个智能问答助手------用户随便问'这个法兰盘的螺栓孔间距该怎么算？'、'上个季度类似项目的材料清单是什么？'，它就能立刻给出准确答案？"

你脑子里蹦出的第一个念头就是："这不就是大语言模型（LLM）该干的事吗？给它喂个 GPT，让它回答就行了。"

于是你兴冲冲地接了一个 ChatGPT 到 CAD 里，但结果惨不忍睹：

用户问："根据 GB/T 9115，PN16 DN80 带颈对焊法兰的法兰厚度？"

LLM 信誓旦旦地说："18.5 mm"，但实际标准是 25.4 mm。
用户上传了一张旧图纸，问："这个项目的材料总重量？"

LLM 只看了一眼就胡编："约 500 公斤"，其实根本没有统计能力。

你终于意识到：通用大模型虽然博学，但它是"闭卷考试"------训练数据截止到某个时间点，根本没有见过你们公司的内部项目档案，也不知道最新的行业规范。想让它既"懂通用知识"又"了解你家的具体数据"，必须给它一本"参考书"让它现场查找。

这本参考书，就是后来风靡整个 AI 圈的 RAG（Retrieval-Augmented Generation，检索增强生成） 。

从最笨拙的"翻书塞答案"到如今比人还会找资料的"知识图谱专家"，RAG 的进化史几乎就是一部程序员打怪升级史。下面，我就按照这个时间线，给你讲清楚它们是怎么一代代"填坑"过来的。

第一代：原始人阶段 ------ Naive RAG（基础版）

你决定照搬 GitHub 上一个热度最高的"7 天搭建自己知识库"的开源项目。

它的做法清晰得像个新兵教程：

切块（Chunking）：把你所有能找到的文档（PDF 设计手册、Word 技术报告、Excel 物料清单、图纸导出的文本）一股脑儿读进来，按固定长度切成小块。比如"每 500 个字一块，不管句子断不断"。
向量化并入库 ：把这些文本块通过一个 embedding 模型（比如 text-embedding-ada-002）转成一串数字（向量），存进向量数据库（比如 Faiss、Chroma）。
查询：用户问"法兰厚度"，你也把这句话 embed 成向量，然后去数据库里找和它最相似的几个块（top-k）。
生成：把搜到的块当作文档上下文，连问题一块儿塞给 LLM："请参考以下资料回答问题：... 资料：..."

你兴冲冲地部署上线，结果用户骂声一片：

搜不准：用户问"螺栓的疲劳寿命怎么算？"，但资料里写的是"德国标准螺栓材质"，向量相似性被大量不相关的术语干扰，找回了一堆关于"标准编号"的废话。
读不懂：切块时一刀切在"...螺栓的疲劳强度取决于------" 这里断了，下一块接的是"------表面粗糙度和热处理工艺"，LLM 看了上句没下句，直接开始胡编。
噪音多：top-5 的块里只有第一条沾点边，后四条都是类似"采购部门的联系电话"这类垃圾，LLM 被干扰后一本正经地建议用户先去买点螺栓。

这就是 Naive RAG，也叫"原始人阶段"。它只解决了"LLM 没见过这些数据"的问题，但检索质量约等于用网兜捞鱼------捞上来的可能是鱼，也可能是水草。

深度扩展：Naive RAG 的技术真相

1. 向量嵌入与相似度搜索

嵌入模型选型 ：常用的有 all-MiniLM-L6-v2（轻量）、text-embedding-3-large（OpenAI 最新）、bge-large-zh（中文专用）。嵌入维度从 384 到 3072 不等，高维度能捕捉更细微的语义，但检索速度也更慢。

相似度度量 ：通常用余弦相似度（Cosine Similarity）衡量两段文本的语义接近程度。公式为 ( \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{|\mathbf{A}| |\mathbf{B}|} )。也有用欧氏距离或内积的，但余弦相似度不受向量长度影响，更适合文本。

近似最近邻搜索（ANN） ：在海量向量中精确找 top-k 比较慢，因此常用 ANN 算法，如 HNSW （分层可导航小世界图）、IVF （倒排文件索引）、PQ（乘积量化）来加速。Faiss 库集成了这些算法。

分块策略的局限性 ：固定长度切片（如 512 tokens）会破坏段落结构。更合理的是语义分块，例如按标题、章节、自然段分割，或者用 句子分割模型（spaCy、NLTK）保持句子完整。

2. Naive RAG 的系统架构

索引流水线：文档解析 → 文本清洗 → 分块 → 向量化 → 写入向量库。这是一个离线（offline）过程。

查询流水线：用户问题 → 向量化 → ANN 搜索 → 获取原始文本块 → 拼接到 prompt → LLM 生成回答。

典型技术栈：LangChain（或 LlamaIndex）+ 向量库（ChromaDB / Milvus）+ LLM（GPT-4 / Llama 3）。

3. 为什么它必定失败？

语义漂移：用户问题和文档块的语义可能并不直接对应，尤其是专业术语多义（"法兰"既可以是零件也可以是法国标准）。

上下文窗口浪费：500 字的块里真正有用的可能只有一两句，但全塞给了 LLM，浪费了宝贵的 context window。

幻觉传染：如果检索到的文本本身有错误，LLM 会把它们当成事实复读。

第二代：精装修阶段 ------ Advanced RAG（进阶版）

你加班一周，把第一代的烂摊子收拾成了第二代。

这一次，你不再是一个简单的"搬运工"，而是变成了一个"精挑细选的编辑"。

改善一：搜之前先"润色"一下（Pre-Retrieval）

用户经常问得很随意，比如："这个管子多厚？" 文档里写的是"管壁厚度"，直接搜矢量肯定不搭。

你让一个小 LLM（或直接用同一 LLM）先把用户问题重写成更专业的查询语句："请问 XX 型号管道的公称壁厚是多少？" 同时，你不再用死板的固定切片，而是用了滑动窗口分块 ------每块 500 字，但相邻块有 100 字重叠，至少不会把关键词切散。你还为每个块自动生成一个摘要，检索时优先检索"摘要"而不是原文，精度一下子高了不少。

改善二：搜之后再过一道"专家审核"（Post-Retrieval）

搜出来的 top-10 块里，大部分还是垃圾。你引入了一个重排序模型（Reranker）。它比向量搜索贵，但更精准------它能深入阅读问题和每个候选块的内容，算出真正的语义相关性分数，然后你只取前 3 块喂给 LLM。

这样一来，噪声大幅减少，生成的答案准确多了。

改善三：告诉 LLM 上下文（Context Enrichment）

你还学会了"买一送一"策略：当重排模型选出那个最相关的块时，你会从原始文档里把它的前后相邻段落 也拉过来，保证信息完整。

这就像查字典时不仅看那句解释，还把前后例句也读了。

这一代被称为 Advanced RAG。它确实提升了准确率，但新的烦恼又来了：

效率瓶颈：多了一步重排序，查询响应时间从 2 秒变成 5 秒，用户嫌慢。
固定套路：不管问什么，都得走"重写→检索→重排→生成"的流程。用户如果问"1+1=？"这种不需要查资料的简单问题，它还傻乎乎地去翻文档，浪费算力。

深度扩展：Advanced RAG 的技术细节

1. 查询优化（Query Transformation）

查询重写：利用 LLM 把口语化或简略问题改写为更具检索价值的声明式查询。例如"上个月的延误报告" → "2026年3月项目延误事故分析报告"。

假设文档嵌入（HyDE）：先让 LLM 凭空生成一个可能的答案（假设文档），把这个假答案向量化后去检索，往往比直接用问题检索更准。因为假答案和真实文档的嵌入空间更接近。

多查询生成：对一个问题生成多个不同侧面的查询，分别检索再合并结果，提升召回率。

2. 分块策略进阶

滑动窗口（Sliding Window）：块大小 512 tokens，步长 128 tokens，保证连续性。

语义分块（Semantic Chunking）：根据 embedding 的相似性自动切分，相似的地方合并，差异大的地方切开。

文档结构分块：利用 Markdown 标题、PDF 大纲、字体变化等结构信息，尽量以逻辑单元（如一个设计规范条目、一个表格）为单位切分。

3. 重排序模型（Reranker）

Bi-Encoder vs Cross-Encoder：向量搜索使用的是 Bi-Encoder，分别将查询和文档编码，然后计算相似度，速度很快但交互不充分。Reranker 通常用 Cross-Encoder，将查询和文档拼接后整个输入模型，进行一次深度交互打分，准确性高但慢。

常见模型 ：BGE-reranker-large、Cohere Rerank、ColBERT。部署常用 sentence-transformers 库。在 CPU 上也能跑，但 GPU 下更快。

流水线 ：粗筛（Bi-Encoder 召回 top-100）→ 精排（Cross-Encoder 对前 100 打分取 top-5）。称为 Multi-Stage Retrieval。

4. 上下文扩充

句子窗口检索：检索命中一个句子后，返回那个句子所在的整个段落。

自动片段抽取：利用 LLM 直接从文档中提取与问题最相关的连续片段，而不是依赖事先分好的块。

第三代：有脑子的特工 ------ Modular / Agentic RAG（智能体版）

你发现第二代像个固定的流水线，处理复杂问题时还是力不从心。

用户开始问更变态的问题："隔壁项目组用的那个能承受 500℃ 高温的密封圈，它的供货商是谁？上次采购单价是多少？"

这种问题靠单次检索根本答不了------它需要多步推理。

你一拍脑袋，决定给 RAG 加个"脑子"，让它变成能够自己判断、反复搜索的智能体（Agent）。

能力一：自我反省与重试（Self-RAG）

现在的流程变成这样：

初步检索，获得一批资料。
在给 LLM 看资料之前，先让它自己检查："这些资料能回答用户的问题吗？"
如果不能，LLM 就重新生成一个新的查询，再去向量库里搜一遍，最多尝试 3 次。
检索到的块还会被加上标签：[relevant]、[irrelevant]，最后只把贴了 [relevant] 的喂给生成模型。

这样一来，如果第一次搜歪了，系统能自动"纠正方向盘"。

能力二：多步推理与工具使用

遇到"A 公司的 CEO 的家乡特产"这种问题，你的 Agent 会自动拆解：

第 1 步：搜索"A 公司 CEO 是谁" → 得到结果"张三"
第 2 步：搜索"张三家乡" → 得到"成都"
第 3 步：搜索"成都特产" → 得到"蜀锦"

每一步的答案都缓存下来，最终组装成完整回答。这种 ReAct（Reason + Act）模式让 RAG 能应对需要聚合、对比多份资料的复杂查询。

能力三：路由（Routing）

你甚至还做了一个路由层：

如果用户问"创建新图层快捷键是什么？"，系统识别为操作指导，直接路由到内置的静态 FAQ 库，甚至不启动检索。
如果问"这次设计的轴径应该按什么公式校核？"，路由到设计公式数据库。
如果问"昨天下午小王画的 3D 模型在哪个文件夹？"，路由到元数据索引库。

不同的数据源对应不同的检索器，按需调用，从而大幅降低了无意义的检索开销。

这一代被称为 Agentic RAG。然而，你很快就被财务部请去喝茶------因为单次查询的 Token 消耗量是以前的 20 倍，成本爆炸。另外，用户开始追问全局性问题："我们这个产品系列一共提交过多少份测试报告？总体通过率趋势如何？" Agentic RAG 还是只会碎片化地找，无法得出宏观结论。

深度扩展：Agentic RAG 的内核

1. Self-RAG 与反射机制

Self-RAG 训练 ：模型经过微调，能够在生成过程中输出特殊 token，如 <RETRIEVE>（需要检索）、<ISREL>（相关）、<ISSUP>（支持答案）、<ISUSE>（有用）。这些 token 控制后续行为。

反射步骤（Reflection） ：Agent 先进行一次回答，然后自我批评，如果能改进则触发新的搜索。LangChain 中通过 ReflectionExecutor 实现。

纠正性检索（CRAG）：检索后，用轻量级评估模型判断每个文档的相关性，对无关文档进行"改写查询"重新检索，把相关文档和改写检索的结果合并。

2. 多步推理实现

ReAct 框架：交替出现"思考→行动→观察"步骤，调用搜索、计算器、数据库查询等工具。

OpenAI Function Calling：模型输出结构化 JSON 决定调用哪个函数，背后可以接各类检索 API。

Plan-and-Execute：先制定一个宏观计划，再逐步执行，适合需要多数据源聚合的复杂任务。

3. 路由与工具编排

路由分类器：可以是基于嵌入向量的小模型分类器（把问题嵌入到几个类别中心），也可以直接让 LLM 分类。

工具选择 ：工具可以是向量检索器、关键词搜索器（BM25）、SQL 数据库查询、API 调用等。通过 LangChain 的 Tool 抽象封装。

记忆管理 ：Agent 需要记住之前检索到的结果和推理步骤，防止重复搜索，这通过 ConversationBufferMemory 或 SummaryMemory 实现。

4. 成本控制

缓存策略：对重复或相似的查询，直接返回已缓存的答案。向量检索本身的查询也可以缓存。

小模型优先：在路由、重写查询等环节使用轻量模型（如 GPT-4o-mini，或本地 7B 模型），只在最终生成时用大模型。

约束步数：设定最大推理步数或超时时间，避免无限循环。

第四代：上帝视角 ------ GraphRAG & 长文本融合（最新版）

你又去深入研究了最新的论文，终于找到了解决全局问题的两把钥匙：知识图谱（GraphRAG） 和 超长上下文模型。

GraphRAG：让知识"联网"

你不再把文档只看作一堆碎纸片，而是把它解析成一个关系网 。

具体做法：

实体识别与关系抽取：利用 LLM 从所有文档中提取出"实体"（人、项目、零件号、标准号）以及它们之间的关系（"包括"、"规定"、"采购自"）。
构建知识图谱：把实体变成节点，关系变成边，存进图数据库（比如 Neo4j 或 Apache Age）。
社区检测：在图里使用 Leiden 算法把相互关联紧密的节点划分成"社区"，为每个社区自动生成一个摘要------这相当于归纳了一个子主题的核心思想。
全局查询 ：当用户问"我们产品线有哪些主要设计变更趋势？"时，系统不再去翻碎块，而是直接检索这些社区摘要，快速把握大局，再根据需要钻取具体原文。

你终于做到了：一个螺栓不只作为一个文本块存在，而是作为一个节点，被连到了"法兰"、"扭矩规范"、"供应商 X"等多个节点。当问及任何相关问题时，图谱都能提供上下文丰富的结构化知识。

长文本融合：把整本手册塞进去

与此同时，你关注到 LLM 的上下文窗口正在疯狂扩张：GPT-4o 可处理 128K tokens，Gemini 1.5 Pro 高达 1M tokens，Claude 3 是 200K。这意味着，对于某些专题，你可以直接把整本设计手册 或者某个项目全部关联文档一次性放入 prompt，让模型自己慢慢看，而不用再猜它可能需要哪一块。

你更新策略为：

先用轻量级关键词检索（如 BM25）粗筛出可能相关的文档集合。
如果集合大小在模型窗口以内，就直接整个输入。
如果超出，则用 GraphRAG 先做聚合，或者用摘要链压缩。

这一代同时解决了"碎片回答"和"全局总结"的矛盾。

然而，即便是第四代，也仍有槽点：

构建成本高：用 LLM 抽取知识图谱，处理大型资料库需要数千美元的 API 费用。
技术门槛陡峭：需要维护图数据库、社区检测算法，调试难度很大。
多模态挑战：除了文字，图纸中的表格、标注、3D 视图中的尺寸都是信息。虽然多模态 embeddings 和检索已出现（如 GPT-4o 能理解图片），但要完全无缝集成还需时日。

深度扩展：GraphRAG 与长文本技术的深度解析

1. GraphRAG 详细实现

实体与关系抽取：可以用 LLM 结合 few-shot prompting，输入文本，输出实体、类型、关系列表。也可使用专用 NER 模型（如 GLiNER）和关系抽取模型（如 ReBEL）。

图构建流程：提取的实体要去重（实体对齐），通过实体链接归一化。然后构建同构图或异构图，节点可附带文本嵌入作为属性。

社区检测：使用 Leiden 算法（比 Louvain 更快，且保证社区连通性）在图谱上寻找模块度最大的分区。每个社区会生成一个总结性的自然语言摘要。这个摘要在全局查询时被检索。

全局搜索：查询时，先根据问题检索相关社区摘要（或直接用"map-reduce"模式生成最终答案），再将相关社区的全部原文块提供 LLM 生成。这被称为"全球-局部"混合检索。

微软开源的 GraphRAG 项目：提供了自动化流水线，包括文本切分、实体提取、社区生成、查询引擎。

2. 长上下文模型的利用策略

Prompt 压缩 ：使用 LLMLingua 等工具，在不丢失关键信息的前提下，将长文档压缩到窗口大小以内，再交给 LLM。

分块与摘要链：对超长文档采用"摘要+检索"双层结构，先从多个块提取关键点，汇总后输入。

位置偏差：研究表明 LLM 对 prompt 的首尾内容注意更多，所以要把最重要的信息放在开头和结尾。长上下文尤其要注意信息重排。

KV 缓存管理：长上下文会增加显存占用和推理延迟，一些推理框架（vLLM）支持 PagedAttention 来优化。

3. 多模态 RAG

多模态嵌入：使用 CLIP、ImageBind 等模型将图像、音频等也映射到向量空间，以便统一检索。例如，用户上传一张零件照片，系统可以检索到包含类似零件的文档。

多模态大模型：GPT-4V、Gemini 1.5 Pro、LLaVA 可以直接理解图文，因此 RAG 检索出的图片可直接作为 base64 传入，无需单独转换为文本描述。

表格理解 ：对于 PDF 的表格，可以使用 unstructured 库提取并转换为 HTML 格式，LLM 更容易理解。

4. RAG 系统的评估

检索质量指标：Recall@K、MRR（平均倒数排名）、NDCG。

答案质量指标：忠實度（Faithfulness，答案是否源自检索文档）、答案相关性（Answer Relevance）、上下文相关性（Context Relevance）。常用评估框架有 RAGAS、TruLens。

端到端评估：使用人工标注的标准答案进行 BLEU/ROUGE 计算，或使用 GPT-4 作为裁判进行评分。

总结：进化逻辑一览表

版本	核心逻辑	解决的问题	现在的槽点
V1 (Naive)	简单搬运	解决了 LLM 没见过专有数据的问题	搜得不准，噪音大
V2 (Advanced)	精挑细选	通过重排、查询优化和上下文扩充，提高了准确度	流程固定，效率低
V3 (Agentic)	循环思考	引入判断与多步推理，能处理复杂任务	成本太高，无法处理全局总结
V4 (Latest)	全局视野	利用知识图谱和长上下文，解决总结性、宏观性问题	构建技术门槛高，图谱构建费钱

现在的 RAG 已不再是"搜索+生成"那么简单，它是一套具备自我迭代、图结构化理解、多模态融合的认知系统。而这个认知系统，已经逐渐内嵌到每一个工业设计软件的灵魂中，让 CAD 不仅仅是画图的工具，更是一个随时待命的、比老工程师更熟悉全公司资料的智能顾问。

下一个可能就是把它和你的三维视图结合起来------当用户旋转一个装配体时，AI 助手能自动解释每个零件的功能、供应商数据和过去的事故报告。这，可能就是未来 CAD 该有的样子。

如果想像唠嗑一样，去了解一些小知识，快去看看视频吧：
认准一个头像，保你不迷路：
抖音：搜索"GodWarrior"
快手：搜索"AIYWminmin"
B站：搜索"宇宙第一AIYWM"
您要是也想站在文章开头的巨人的肩膀啦，可以动动您发财的小指头，然后把您的想要展现的名称和公开信息发我，这些信息会跟随每篇文章，屹立在文章的顶部哦