这里写自定义目录标题欢迎使用Markdown编辑器一、为什么朴素 RAG 不够用了二、GraphRAG从检索片段到理解关系生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# 高级 RAG 架构演进GraphRAG、自适应检索与多模态检索实战一、为什么朴素 RAG 不够用了朴素 RAG 的流程可以用一句话概括把文档切块向量化用户提问时检索最相似的几个块拼进提示词让模型生成。这套流程在很多简单问答场景里够用但一旦业务复杂度上来它的瓶颈就会暴露得越来越明显。瓶颈主要有四类。第一召回不准——纯向量相似度无法完全捕捉语义相关性尤其在专业领域两个表述不同的句子可能语义相关也可能只是字面相近。第二上下文割裂——文档被机械切分后丢失了全局逻辑和跨段落关联模型只见树木不见森林遇到需要跨段落综合推理的问题就答不好。第三静态知识——朴素 RAG 的索引是静态的无法良好处理实时变化的数据或需要链式推理的关系型问题。第四长文档弱——面对上百页的文档朴素的 top-k 检索难以支撑全局理解和多跳推理。正是因为这些瓶颈高级 RAG 架构在过去一两年里快速演进。本文聚焦三个最有代表性的方向GraphRAG图检索增强、自适应检索Adaptive RAG、多模态检索并结合工程实践给出落地建议。二、GraphRAG从检索片段到理解关系GraphRAG 的核心思想是不再把知识库当作一堆独立的文档片段而是把它显式建模为一张知识图谱——实体是节点关系是边。这样检索不再只是找相似的文本而是沿着实体和关系找到相关的知识网络。GraphRAG 的典型构建流程是先用大模型从文档中抽取实体和关系比如从一篇公司介绍中抽取出公司A—控股—子公司B这样的三元组构建知识图谱查询时既做文本级的向量检索也沿着图谱做图遍历和关系推理把命中的实体及其关联子图一并作为上下文注入。GraphRAG 最大的价值在于多跳推理能力。比如这家公司的创始人还投资过哪些项目这类需要跨实体链式推理的问题纯向量检索很难回答——它只匹配字面相近的片段而图检索可以沿着创始人→投资→项目的路径找到答案。微软开源的 GraphRAG 框架验证了这一方向也带动了大量相关实践。不过 GraphRAG 不是银弹它有几个工程代价需要正视。一是构建成本高——用模型抽取实体关系对长文档是显著的计算开销二是维护复杂——图谱需要持续更新而图结构的演化远比文本索引复杂三是适用面有限——对以自然语言知识为主、关系结构不强的文档图建模的收益可能不明显。因此我的判断是GraphRAG 适合关系密集、需要多跳推理、知识结构化程度高的场景比如企业组织知识、供应链关系、科研文献关联分析对于以文档问答为主的通用知识库先把朴素 RAG 的检索与重排做到位性价比更高。不要因为高级就盲目引入。# GraphRAG 查询路径的简化示意defgraph_rag_query(question,vector_index,graph,llm):seedsvector_index.search(question,top_k10)# 向量召回种子实体subgraphgraph.expand_neighborhood(seeds,hops2)# 图谱邻域扩展contextgraph.serialize(subgraph)# 序列化子图为上下文returnllm.generate(question,contextcontext)## 三、自适应检索让系统自己决定怎么查自适应检索Adaptive RAG要解决的是另一个问题不同的问题需要不同的检索策略但系统不该靠人去配置每类问题的策略而应该**让系统自己判断**。 朴素 RAG 对所有问题都走同一套检索→拼接→生成流程这其实是一种浪费也是一种质量损失。简单的问题如公司放假安排是什么检索一次就能答好复杂的问题如对比 A、B 两个方案的优劣并给出建议可能需要多轮检索、多次尝试甚至需要在检索不到时尝试改写查询再查。 自适应检索的核心组件是一个**决策器**它通常由一个小模型或规则构成负责判断这个问题需不需要检索需要检索几次从哪个数据源检索检索不到时要不要改写查询要不要做重排这个决策可以在流程的多个节点触发形成检索-评估-再检索的动态循环。 自适应检索带来的收益是双重的一方面简单问题走轻量路径减少不必要的 API 调用降低成本另一方面复杂问题获得更强的检索预算提升整体回答质量。这正符合生产系统把资源花在刀刃上的诉求。 在工程落地时自适应检索的关键是**决策器的设计**。规则方案简单可控但覆盖面有限模型方案灵活但引入额外成本和不确定性。我的建议是从规则起步把最常见的几类问题形态用规则分流再逐步用模型决策替换并在决策节点上做好可观测性——要知道系统为什么选择了这条路这是后续调优的基础。## 四、多模态与半结构化检索统一检索的挑战现实中很多企业文档既包含文本也包含表格、图片、PDF 扫描件。传统 RAG 只处理纯文本遇到图表就只能视而不见或简单跳过。多模态检索要解决的正是让检索系统跨模态工作的问题。 多模态检索通常有两条实现路线。**路线一模态转换**。把图像用多模态模型转成文本描述caption把表格转成结构化文本然后统一进文本向量库。实现相对简单能复用现有检索链路但信息有损——图像细节、表格的精确结构可能在转换中丢失。**路线二统一向量空间**。用多模态嵌入模型把图像和文本映射到同一向量空间直接做跨模态检索。保真度更高但对模型和基建的要求也更高。 对于表格这类半结构化数据业界也在探索多向量检索的思路——为同一个文档块建立多个表示摘要向量、文本向量、结构化特征检索时综合多个视角。这样无论是按内容语义找还是按结构找都有对应的索引支撑。## 五、RAG 与 Agent 的融合从问答到做事最后值得专门讨论的趋势是 RAG 与 Agent 的融合。传统 RAG 是被动的——用户提问系统检索并回答。而 Agent 化的 RAG 是主动的——系统可以自主决定什么时候查、查什么、查几次甚至可以在检索之外调用工具完成更复杂的任务。 这种融合带来几个实际能力的提升。一是**复杂问题拆解**——把一个需要多次检索的问题拆成子问题逐个解决比如比较两款产品的性价比可以先分别查产品参数、再查价格、再综合对比。二是**多步推理闭环**——检索结果不理想时主动改写、重新检索直到信息足够。三是**任务执行**——检索到信息后不是说说而已而是直接驱动后续动作比如查到库存不足就触发补货流程。 当然Agent 化的 RAG 也继承了 Agent 的可控性问题——自主决策意味着更高的不可预测性需要更强的状态管理、步数限制和护栏。我的建议是渐进式引入先从查询改写多轮检索这种有限的自主性开始验证效果和成本之后再逐步放开决策范围。## 六、落地路线图不要一步到位而是分阶段演进高级 RAG 架构听起来诱人但一上来就铺开 GraphRAG、自适应检索、多模态全套往往不是好策略。更务实的路线是分阶段演进。**第一阶段夯实基础。**把朴素 RAG 的四件事做扎实——高质量分块、混合检索、重排序、忠实度约束。这一阶段就能解决80%的文档问答需求。**第二阶段引入重排与查询改写。**针对召回质量不足的问题用两段式检索提升精度。**第三阶段按需引入高级组件。**出现多跳推理需求时引入图检索出现异构数据时引入多模态出现大量简单/复杂混合问题时引入自适应路由。每一步都配套评估用数据决定是否值得继续。 这套路线图的底层逻辑是**成本与收益的平衡**高级架构都伴随更高的构建成本、维护成本和复杂度只有当收益明确超过成本时才值得引入。技术方向没有对错只有合不合适——这是高级 RAG 架构选型最重要的判断准则。## 七、选型决策框架四问法帮你判断要不要上高级架构结合前文的技术剖析这里给出一个简洁的四问决策框架帮助你在具体项目里判断该采用多高级的 RAG 架构。**第一问用户的问题需要多跳推理吗**如果业务问答以单点事实查询为主查规则、查价格、查定义朴素 RAG 配合重排通常足够GraphRAG 的图建模成本难以回本。如果大量问题是A 与 B 的关系、演变链条、跨多篇文档的综合对比则值得认真评估图检索与多文档综合能力。**第二问知识库的结构化程度高吗**关系型、实体密集、有明显图谱潜质的领域组织架构、供应链、科研文献图建模的收益最大。纯文档型、以散文文本为主的知识库先把文本检索做精更划算。**第三问问题形态的分布均匀吗**如果系统同时面对大量一句话就能答的简单问题和少数需要多轮检索的复杂问题自适应检索的价值最大——它能把简单问题的成本降下来、把复杂问题的质量提上去。如果所有问题都差不多复杂自适应路由的收益就有限。**第四问团队有持续迭代的能力吗**高级架构不是一次部署终身受益而是需要持续的数据标注、效果评估和参数调整。如果团队没有评估闭环的投入意愿高级架构很可能沦为看着高级但没人维护的摆设。 这套四问法的核心是把技术选型从追随概念拉回到业务驱动。先问业务需不需要再问架构给不给得起最后问团队养不养得起。## 八、结语高级架构服务于业务而非相反高级 RAG 架构的演进本质上反映了一个趋势RAG 正从一个检索拼接的技术套路成长为一个可以根据业务复杂度灵活组合的完整技术体系。GraphRAG 补上了关系推理的短板自适应检索补上了资源分配的效率多模态检索补上了异构数据的覆盖——每一个高级组件的出现都是对朴素 RAG 某一方面瓶颈的回应。 但技术越丰富越需要冷静的取舍。我的核心判断是**高级架构服务于业务而非相反**。不要因为 GraphRAG 很火就上 GraphRAG不要因为自适应检索听起来智能就盲目引入。正确的路径永远是先清晰定义业务需求再对照每个高级组件的能力边界评估它是否真的解决了你当前最痛的问题最后用评估数据验证投入产出。 回到本文开头的四个瓶颈——召回不准、上下文割裂、静态知识、长文档弱——它们并不是每个项目都会同时遇到。找到你真正需要解决的那一个或两个选择对应的高级组件把它做深做透远比把全套高级架构堆上去更有效。RAG 的工程化之道在于知取舍、有节奏、重评估。**Markdown编辑器**所展示的欢迎页。如果你想学习如何使用Markdown编辑器,可以仔细阅读这篇文章了解一下Markdown的基本语法知识。## 新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客1.**全新的界面设计**将会带来全新的写作体验2.在创作中心设置你喜爱的代码高亮样式Markdown**将代码片显示选择的高亮样式**进行展示3.增加了**图片拖拽**功能你可以将本地的图片直接拖拽到编辑区域直接展示4.全新的**KaTeX数学公式**语法5.增加了支持**甘特图的mermaid语法[^1]**功能6.增加了**多屏幕编辑**Markdown文章功能7.增加了**焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置**等功能功能按钮位于编辑区域与预览区域中间8.增加了**检查列表**功能。[^1]:[mermaid语法说明](https://mermaid.js.org/intro/)## 功能快捷键撤销kbdCtrl/Command/kbdkbdZ/kbd重做kbdCtrl/Command/kbdkbdY/kbd加粗kbdCtrl/Command/kbdkbdB/kbd斜体kbdCtrl/Command/kbdkbdI/kbd标题kbdCtrl/Command/kbdkbdShift/kbdkbdH/kbd无序列表kbdCtrl/Command/kbdkbdShift/kbdkbdU/kbd有序列表kbdCtrl/Command/kbdkbdShift/kbdkbdO/kbd检查列表kbdCtrl/Command/kbdkbdShift/kbdkbdC/kbd插入代码kbdCtrl/Command/kbdkbdShift/kbdkbdK/kbd插入链接kbdCtrl/Command/kbdkbdShift/kbdkbdL/kbd插入图片kbdCtrl/Command/kbdkbdShift/kbdkbdG/kbd查找kbdCtrl/Command/kbdkbdF/kbd替换kbdCtrl/Command/kbdkbdG/kbd## 合理的创建标题有助于目录的生成直接输入1次kbd#/kbd并按下kbdspace/kbd后将生成1级标题。输入2次kbd#/kbd并按下kbdspace/kbd后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。## 如何改变文本的样式*强调文本*_强调文本_**加粗文本**__加粗文本__标记文本~~删除文本~~引用文本 H~2~Ois是液体。2^10^运算结果是1024.## 插入链接与图片链接:[link](https://www.csdn.net/).图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。## 如何插入一段漂亮的代码片去[博客设置](https://mp.csdn.net/console/configBlog)页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的 代码片.javascript//An highlighted block var foobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。1注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。注脚的解释 ↩︎ 高级 RAG 架构演进：GraphRAG、自适应检索与多模态检索实战
这里写自定义目录标题欢迎使用Markdown编辑器一、为什么朴素 RAG 不够用了二、GraphRAG从检索片段到理解关系生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# 高级 RAG 架构演进GraphRAG、自适应检索与多模态检索实战一、为什么朴素 RAG 不够用了朴素 RAG 的流程可以用一句话概括把文档切块向量化用户提问时检索最相似的几个块拼进提示词让模型生成。这套流程在很多简单问答场景里够用但一旦业务复杂度上来它的瓶颈就会暴露得越来越明显。瓶颈主要有四类。第一召回不准——纯向量相似度无法完全捕捉语义相关性尤其在专业领域两个表述不同的句子可能语义相关也可能只是字面相近。第二上下文割裂——文档被机械切分后丢失了全局逻辑和跨段落关联模型只见树木不见森林遇到需要跨段落综合推理的问题就答不好。第三静态知识——朴素 RAG 的索引是静态的无法良好处理实时变化的数据或需要链式推理的关系型问题。第四长文档弱——面对上百页的文档朴素的 top-k 检索难以支撑全局理解和多跳推理。正是因为这些瓶颈高级 RAG 架构在过去一两年里快速演进。本文聚焦三个最有代表性的方向GraphRAG图检索增强、自适应检索Adaptive RAG、多模态检索并结合工程实践给出落地建议。二、GraphRAG从检索片段到理解关系GraphRAG 的核心思想是不再把知识库当作一堆独立的文档片段而是把它显式建模为一张知识图谱——实体是节点关系是边。这样检索不再只是找相似的文本而是沿着实体和关系找到相关的知识网络。GraphRAG 的典型构建流程是先用大模型从文档中抽取实体和关系比如从一篇公司介绍中抽取出公司A—控股—子公司B这样的三元组构建知识图谱查询时既做文本级的向量检索也沿着图谱做图遍历和关系推理把命中的实体及其关联子图一并作为上下文注入。GraphRAG 最大的价值在于多跳推理能力。比如这家公司的创始人还投资过哪些项目这类需要跨实体链式推理的问题纯向量检索很难回答——它只匹配字面相近的片段而图检索可以沿着创始人→投资→项目的路径找到答案。微软开源的 GraphRAG 框架验证了这一方向也带动了大量相关实践。不过 GraphRAG 不是银弹它有几个工程代价需要正视。一是构建成本高——用模型抽取实体关系对长文档是显著的计算开销二是维护复杂——图谱需要持续更新而图结构的演化远比文本索引复杂三是适用面有限——对以自然语言知识为主、关系结构不强的文档图建模的收益可能不明显。因此我的判断是GraphRAG 适合关系密集、需要多跳推理、知识结构化程度高的场景比如企业组织知识、供应链关系、科研文献关联分析对于以文档问答为主的通用知识库先把朴素 RAG 的检索与重排做到位性价比更高。不要因为高级就盲目引入。# GraphRAG 查询路径的简化示意defgraph_rag_query(question,vector_index,graph,llm):seedsvector_index.search(question,top_k10)# 向量召回种子实体subgraphgraph.expand_neighborhood(seeds,hops2)# 图谱邻域扩展contextgraph.serialize(subgraph)# 序列化子图为上下文returnllm.generate(question,contextcontext)## 三、自适应检索让系统自己决定怎么查自适应检索Adaptive RAG要解决的是另一个问题不同的问题需要不同的检索策略但系统不该靠人去配置每类问题的策略而应该**让系统自己判断**。 朴素 RAG 对所有问题都走同一套检索→拼接→生成流程这其实是一种浪费也是一种质量损失。简单的问题如公司放假安排是什么检索一次就能答好复杂的问题如对比 A、B 两个方案的优劣并给出建议可能需要多轮检索、多次尝试甚至需要在检索不到时尝试改写查询再查。 自适应检索的核心组件是一个**决策器**它通常由一个小模型或规则构成负责判断这个问题需不需要检索需要检索几次从哪个数据源检索检索不到时要不要改写查询要不要做重排这个决策可以在流程的多个节点触发形成检索-评估-再检索的动态循环。 自适应检索带来的收益是双重的一方面简单问题走轻量路径减少不必要的 API 调用降低成本另一方面复杂问题获得更强的检索预算提升整体回答质量。这正符合生产系统把资源花在刀刃上的诉求。 在工程落地时自适应检索的关键是**决策器的设计**。规则方案简单可控但覆盖面有限模型方案灵活但引入额外成本和不确定性。我的建议是从规则起步把最常见的几类问题形态用规则分流再逐步用模型决策替换并在决策节点上做好可观测性——要知道系统为什么选择了这条路这是后续调优的基础。## 四、多模态与半结构化检索统一检索的挑战现实中很多企业文档既包含文本也包含表格、图片、PDF 扫描件。传统 RAG 只处理纯文本遇到图表就只能视而不见或简单跳过。多模态检索要解决的正是让检索系统跨模态工作的问题。 多模态检索通常有两条实现路线。**路线一模态转换**。把图像用多模态模型转成文本描述caption把表格转成结构化文本然后统一进文本向量库。实现相对简单能复用现有检索链路但信息有损——图像细节、表格的精确结构可能在转换中丢失。**路线二统一向量空间**。用多模态嵌入模型把图像和文本映射到同一向量空间直接做跨模态检索。保真度更高但对模型和基建的要求也更高。 对于表格这类半结构化数据业界也在探索多向量检索的思路——为同一个文档块建立多个表示摘要向量、文本向量、结构化特征检索时综合多个视角。这样无论是按内容语义找还是按结构找都有对应的索引支撑。## 五、RAG 与 Agent 的融合从问答到做事最后值得专门讨论的趋势是 RAG 与 Agent 的融合。传统 RAG 是被动的——用户提问系统检索并回答。而 Agent 化的 RAG 是主动的——系统可以自主决定什么时候查、查什么、查几次甚至可以在检索之外调用工具完成更复杂的任务。 这种融合带来几个实际能力的提升。一是**复杂问题拆解**——把一个需要多次检索的问题拆成子问题逐个解决比如比较两款产品的性价比可以先分别查产品参数、再查价格、再综合对比。二是**多步推理闭环**——检索结果不理想时主动改写、重新检索直到信息足够。三是**任务执行**——检索到信息后不是说说而已而是直接驱动后续动作比如查到库存不足就触发补货流程。 当然Agent 化的 RAG 也继承了 Agent 的可控性问题——自主决策意味着更高的不可预测性需要更强的状态管理、步数限制和护栏。我的建议是渐进式引入先从查询改写多轮检索这种有限的自主性开始验证效果和成本之后再逐步放开决策范围。## 六、落地路线图不要一步到位而是分阶段演进高级 RAG 架构听起来诱人但一上来就铺开 GraphRAG、自适应检索、多模态全套往往不是好策略。更务实的路线是分阶段演进。**第一阶段夯实基础。**把朴素 RAG 的四件事做扎实——高质量分块、混合检索、重排序、忠实度约束。这一阶段就能解决80%的文档问答需求。**第二阶段引入重排与查询改写。**针对召回质量不足的问题用两段式检索提升精度。**第三阶段按需引入高级组件。**出现多跳推理需求时引入图检索出现异构数据时引入多模态出现大量简单/复杂混合问题时引入自适应路由。每一步都配套评估用数据决定是否值得继续。 这套路线图的底层逻辑是**成本与收益的平衡**高级架构都伴随更高的构建成本、维护成本和复杂度只有当收益明确超过成本时才值得引入。技术方向没有对错只有合不合适——这是高级 RAG 架构选型最重要的判断准则。## 七、选型决策框架四问法帮你判断要不要上高级架构结合前文的技术剖析这里给出一个简洁的四问决策框架帮助你在具体项目里判断该采用多高级的 RAG 架构。**第一问用户的问题需要多跳推理吗**如果业务问答以单点事实查询为主查规则、查价格、查定义朴素 RAG 配合重排通常足够GraphRAG 的图建模成本难以回本。如果大量问题是A 与 B 的关系、演变链条、跨多篇文档的综合对比则值得认真评估图检索与多文档综合能力。**第二问知识库的结构化程度高吗**关系型、实体密集、有明显图谱潜质的领域组织架构、供应链、科研文献图建模的收益最大。纯文档型、以散文文本为主的知识库先把文本检索做精更划算。**第三问问题形态的分布均匀吗**如果系统同时面对大量一句话就能答的简单问题和少数需要多轮检索的复杂问题自适应检索的价值最大——它能把简单问题的成本降下来、把复杂问题的质量提上去。如果所有问题都差不多复杂自适应路由的收益就有限。**第四问团队有持续迭代的能力吗**高级架构不是一次部署终身受益而是需要持续的数据标注、效果评估和参数调整。如果团队没有评估闭环的投入意愿高级架构很可能沦为看着高级但没人维护的摆设。 这套四问法的核心是把技术选型从追随概念拉回到业务驱动。先问业务需不需要再问架构给不给得起最后问团队养不养得起。## 八、结语高级架构服务于业务而非相反高级 RAG 架构的演进本质上反映了一个趋势RAG 正从一个检索拼接的技术套路成长为一个可以根据业务复杂度灵活组合的完整技术体系。GraphRAG 补上了关系推理的短板自适应检索补上了资源分配的效率多模态检索补上了异构数据的覆盖——每一个高级组件的出现都是对朴素 RAG 某一方面瓶颈的回应。 但技术越丰富越需要冷静的取舍。我的核心判断是**高级架构服务于业务而非相反**。不要因为 GraphRAG 很火就上 GraphRAG不要因为自适应检索听起来智能就盲目引入。正确的路径永远是先清晰定义业务需求再对照每个高级组件的能力边界评估它是否真的解决了你当前最痛的问题最后用评估数据验证投入产出。 回到本文开头的四个瓶颈——召回不准、上下文割裂、静态知识、长文档弱——它们并不是每个项目都会同时遇到。找到你真正需要解决的那一个或两个选择对应的高级组件把它做深做透远比把全套高级架构堆上去更有效。RAG 的工程化之道在于知取舍、有节奏、重评估。**Markdown编辑器**所展示的欢迎页。如果你想学习如何使用Markdown编辑器,可以仔细阅读这篇文章了解一下Markdown的基本语法知识。## 新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客1.**全新的界面设计**将会带来全新的写作体验2.在创作中心设置你喜爱的代码高亮样式Markdown**将代码片显示选择的高亮样式**进行展示3.增加了**图片拖拽**功能你可以将本地的图片直接拖拽到编辑区域直接展示4.全新的**KaTeX数学公式**语法5.增加了支持**甘特图的mermaid语法[^1]**功能6.增加了**多屏幕编辑**Markdown文章功能7.增加了**焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置**等功能功能按钮位于编辑区域与预览区域中间8.增加了**检查列表**功能。[^1]:[mermaid语法说明](https://mermaid.js.org/intro/)## 功能快捷键撤销kbdCtrl/Command/kbdkbdZ/kbd重做kbdCtrl/Command/kbdkbdY/kbd加粗kbdCtrl/Command/kbdkbdB/kbd斜体kbdCtrl/Command/kbdkbdI/kbd标题kbdCtrl/Command/kbdkbdShift/kbdkbdH/kbd无序列表kbdCtrl/Command/kbdkbdShift/kbdkbdU/kbd有序列表kbdCtrl/Command/kbdkbdShift/kbdkbdO/kbd检查列表kbdCtrl/Command/kbdkbdShift/kbdkbdC/kbd插入代码kbdCtrl/Command/kbdkbdShift/kbdkbdK/kbd插入链接kbdCtrl/Command/kbdkbdShift/kbdkbdL/kbd插入图片kbdCtrl/Command/kbdkbdShift/kbdkbdG/kbd查找kbdCtrl/Command/kbdkbdF/kbd替换kbdCtrl/Command/kbdkbdG/kbd## 合理的创建标题有助于目录的生成直接输入1次kbd#/kbd并按下kbdspace/kbd后将生成1级标题。输入2次kbd#/kbd并按下kbdspace/kbd后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。## 如何改变文本的样式*强调文本*_强调文本_**加粗文本**__加粗文本__标记文本~~删除文本~~引用文本 H~2~Ois是液体。2^10^运算结果是1024.## 插入链接与图片链接:[link](https://www.csdn.net/).图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。## 如何插入一段漂亮的代码片去[博客设置](https://mp.csdn.net/console/configBlog)页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的 代码片.javascript//An highlighted block var foobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。1注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。注脚的解释 ↩︎