RAG不需要向量：非向量检索的工程实践与落地指南-开发者社区

1. 这个标题不是噱头，而是对RAG底层逻辑的一次重新校准

“RAG不需要向量？”——看到这个标题，很多刚接触检索增强生成（RAG）的朋友第一反应是：这怎么可能？主流教程、开源框架、企业落地案例，几乎清一色都在讲Embedding模型、向量数据库、余弦相似度检索……向量早已成了RAG的“默认身份证”。但如果你真把RAG当成一个工程问题来解，而不是照搬教科书定义，就会发现：向量只是当前最主流的实现手段，绝非RAG架构的必要条件。这句话不是在否定向量的价值，而是在划清“RAG本质”和“RAG实现路径”的边界。

RAG的核心定义非常朴素：让大语言模型在生成回答前，先从外部知识源中检索出相关片段，再将这些片段与用户问题一起喂给模型，从而提升回答的准确性、时效性和可追溯性。注意，这里的关键动词是“检索”，不是“向量化检索”。检索可以基于关键词匹配、BM25打分、语义图谱跳转、规则引擎过滤、甚至人工预标引的索引表——只要能从海量文档中快速定位到与当前问题语义或事实高度相关的片段，它就完成了RAG的第一步使命。

我去年帮一家医疗设备厂商搭建内部知识助手时，就刻意绕开了向量方案。他们有3000+份PDF格式的维修手册、故障代码表、零部件目录，更新频率低但结构极强：每份文档都有标准章节编号（如“E-04-02：电源模块电压检测流程”）、固定字段（故障码、现象描述、处理步骤、关联部件号）。我们用正则+XPath提取结构化元数据，构建轻量级倒排索引，用户问“E-04-02报错怎么修”，系统0.2秒内直接命中对应PDF页码和段落。全程没调用一次Embedding模型，也没连一次向量数据库，但效果比同期用Chroma+all-MiniLM-L6-v2的测试组更稳定——因为维修工程师提问习惯高度结构化，关键词精准匹配反而比模糊语义检索更可靠。

这背后反映的是一个被忽略的现实：RAG的瓶颈从来不在“向量好不好”，而在“检索是否真正贴合业务语义”。当你的知识库是法律条文，关键词+布尔逻辑+时间戳过滤可能比向量更准；当你的数据是带Schema的API文档，基于OpenAPI规范的路径匹配就是天然检索器；当你的内容是产品SKU库，用ES的term query查型号编码，比把“iPhone 15 Pro Max 256GB 钛金属”向量化后再搜快且准得多。所谓“RAG不需要向量”，本质是提醒我们：别让工具绑架问题，先定义清楚“我要检什么、依据什么检、检出来要怎么用”，再选技术栈。

这个认知转变，直接决定了你投入的时间、算力和维护成本。用向量方案，意味着你要持续优化chunk策略、调参Embedding模型、监控向量库漂移、处理长尾query失效；而放弃向量，可能只需写几条正则、配几个ES mapping、搭个简易图谱节点关系。这不是技术倒退，而是回归工程本质——用最简单、最可控、最贴合业务的方式，解决“让LLM不瞎编”这个核心诉求。接下来，我们就一层层拆开：哪些场景天然排斥向量、哪些替代方案真正可用、以及当你决定不用向量时，具体该怎么设计、怎么落地、怎么避坑。

2. RAG的本质解构：为什么“检索”不等于“向量化检索”

2.1 RAG的三层抽象：目标层、能力层、实现层

要彻底理解“RAG不需要向量”，必须跳出代码和框架，从抽象层级看清楚RAG到底是什么。我把RAG拆成三个不可混淆的层次：

目标层（Why）：解决大语言模型的幻觉问题，确保输出内容有据可依、可验证、可溯源。这是RAG存在的唯一理由，也是所有技术选型的终极标尺。如果某种方案能让用户点击答案旁的“来源”链接，直接跳转到原始文档的精确位置，且95%以上回答能指向正确段落，那它就达成了RAG目标——无论用什么技术。
能力层（What）：提供一种机制，能在毫秒级时间内，从外部知识源中找出与当前用户问题最相关的1~3个文本片段（passage）。这里的关键词是“最相关”，但“相关”的定义权在业务手里：对客服系统，“相关”可能是匹配用户报修的设备型号+故障代码；对法务助手，“相关”可能是命中最新修订版条款+司法解释引用；对科研助手，“相关”可能是同一篇论文的Methodology段落+Related Work对比句。能力层只承诺“能检”，不承诺“怎么检”。
实现层（How）：具体用什么技术达成能力层的要求。这才是向量、关键词、图谱、规则等方案的竞技场。目前向量方案胜出，是因为它在通用语义匹配上表现均衡——对“苹果手机充不进电”和“iPhone无法充电”这种表述差异大的query，向量相似度比纯关键词匹配鲁棒得多。但它也有硬伤：对数字、专有名词、结构化字段极度不敏感；对长尾、冷启动query泛化能力差；需要大量标注数据调优；向量库一旦建立，schema变更成本极高。

提示：很多团队失败的根源，是把实现层的技术（比如“必须用FAISS”）当成了能力层的要求（“必须支持语义检索”），再错误地推导出目标层的结论（“RAG=向量检索”）。结果就是：花了3个月搭好向量知识库，却发现销售同事问“上季度华东区TOP3客户是谁”，系统返回一堆关于“华东”“客户”“季度”的无关段落——因为向量根本不懂“TOP3”是排序需求，“上季度”是时间范围约束。

2.2 向量方案的三大隐性成本，常被教程刻意忽略

主流RAG教程很少提，但你在真实项目里一定会撞上的三座大山：

第一，Chunking的诅咒。向量检索依赖文本分块（chunking），而chunk策略直接决定效果上限。按固定长度切（如512字符）？会把“故障代码E102：主板供电异常”硬生生切成两半，后半句“主板供电异常”单独向量化，跟“E102”完全失联。按标点切？遇到长段落的技术描述（如一段2000字的电路原理说明），单个chunk信息过载，Embedding模型无法聚焦关键实体。按语义切（如LlamaIndex的SentenceSplitter）？在中文场景下，标点缺失、长句嵌套、专业术语连写（如“PCIeGen4x16”）会让句子边界识别错误率飙升。我实测过某医疗问答项目：用固定chunk+text-embedding-ada-002，对“心梗后ST段抬高持续多久”这类问题，召回率仅61%；换成基于规则的“症状+检查指标+时间范围”三元组提取，直接拉到92%。

第二，Embedding模型的领域偏移。OpenAI的text-embedding-ada-002在通用语料上表现优秀，但面对电力调度规程里的“N-1安全准则”、半导体厂的“光刻胶涂布均匀性CPK值”，它的向量空间根本无法区分这些术语的行业权重。微调Embedding模型？需要至少5000条高质量的领域query-passage对，还要有标注团队。而关键词方案只需整理一份《电力术语缩写对照表》，把“N-1”映射到“任意单一元件故障后系统仍能正常运行”，就能覆盖80%的歧义场景。

第三，向量库的运维黑洞。向量数据库不是“建完就完事”。当知识库新增100份文档，你得重新Embedding全部内容（哪怕只增1份，为保证一致性也常全量重跑）；当业务方说“把故障代码查询优先级提到最高”，你得调整reranker权重或加规则兜底——但向量本身不支持“强制提升某类文档权重”；当用户反馈“总搜不到E205错误”，你得查是chunk切坏了、Embedding没学好、还是query改写出了问题，排查链路长达5层。相比之下，ES的function_score查询，一行DSL就能把含“E205”的文档boost 10倍，日志里直接看到boost原因。

2.3 真正替代向量的四大非向量检索范式

既然向量不是必需，那什么能替代它？根据我经手的27个RAG项目，真正落地有效的非向量方案就四类，按适用场景强度排序：

结构化查询引擎（最强）：适用于知识库本身就有强Schema的场景，如数据库表、API文档、产品目录、维修手册。核心是把文档解析成结构化记录（JSON），用SQL/ES/Dgraph等引擎直接查询。例如，把每份维修手册解析为{doc_id: "MAN-001", section: "E-04-02", fault_code: "E102", symptom: "主板供电异常", solution: "检查PWR_LED电压..."}，用户问“E102怎么修”，直接WHERE fault_code = 'E102'，毫秒返回。优势：精度100%，可精确控制字段权重，支持聚合统计（如“统计近3个月高频故障TOP5”）。劣势：要求原始文档可结构化解析，PDF扫描件需OCR+规则提取。
关键词增强检索（最稳）：适用于文本质量高、术语标准化的场景，如政策文件、技术白皮书、学术论文。核心是用BM25等传统算法，但叠加业务规则。例如，在法律RAG中，用户问“离婚财产分割新规”，系统先用BM25找含“离婚”“财产分割”的条文，再用规则过滤：① 时间戳 > 2023-01-01；② 来源为“最高人民法院司法解释”；③ 段落含“夫妻共同财产”“协议分割”等法定术语。我做的某省政务知识库，纯BM25召回率78%，加规则后升至94%，且无幻觉——因为每条结果都来自明确条款。
知识图谱跳转（最准）：适用于实体关系密集、推理链长的场景，如生物医药、金融风控、工业设备。核心是把知识构建成图（节点=实体，边=关系），检索变成图遍历。例如，用户问“阿司匹林和华法林联用风险”，系统从“阿司匹林”节点出发，沿“药物相互作用”边找到“华法林”，再沿“增加出血风险”边获取证据段落。优势：天然支持多跳推理，结果可解释性强。劣势：图谱构建成本高，需领域专家参与本体设计。
规则引擎匹配（最快）：适用于query模式高度固定的场景，如客服FAQ、工单分类、合规检查。核心是预定义规则集，用正则、语法树或决策表匹配。例如，用户输入含“退款”“未发货”“7天内”，直接触发规则IF (refund AND not_shipped AND days < 7) THEN return "符合极速退款条件"。优势：响应<10ms，100%确定性，零训练成本。劣势：泛化能力弱，需持续维护规则库。

注意：这四类不是互斥的，真实项目往往是组合使用。比如某银行智能投顾系统：用户问“年化收益4.5%的保本理财有哪些”，先用规则引擎识别“年化收益”“保本”为关键约束；再用结构化查询从产品库中筛选yield >= 4.5 AND guarantee_type = 'principal_protected'；最后用BM25在产品说明书里定位“起息日”“赎回条款”等细节段落。向量在这里毫无用武之地——因为“4.5%”是精确数值，不是语义概念。

3. 实操指南：零向量RAG的完整落地路径与关键配置

3.1 场景诊断：三步判断你的项目是否该放弃向量

别急着写代码，先做一次冷静的自我诊断。我设计了一个5分钟速判表，基于你手头的知识库和业务需求：

诊断维度	向量友好型特征（建议用向量）	非向量友好型特征（果断弃向量）	你的现状
知识库结构	大量非结构化文本（如会议纪要、客服对话、研发日志），无统一模板	文档有强Schema（如PDF含标准章节、Excel有固定列、数据库有明确表结构）	□□□□□
用户Query模式	提问自由发散（如“帮我总结上周项目风险”“这个技术方案有什么坑”）	提问高度结构化（如“查E102故障代码”“找2023版合同第5.2条”“显示SKU A123的库存”）	□□□□□
精度要求	接受一定模糊性，更看重覆盖广度（如“相关技术方案”）	要求100%精确匹配，错一条就导致业务事故（如“故障代码必须完全一致”“法律条款引用不能偏差”）	□□□□□

填表说明：每个维度选最贴近你现状的一项。如果三行都勾选了“非向量友好型”，恭喜你，向量方案对你就是奢侈品——不仅贵，还容易出错。下一步直接进入3.2节；如果两行是“非向量”，一行是“向量”，建议用混合方案（如结构化查询为主，BM25为辅）；如果两行以上是“向量”，再考虑向量方案，但务必先做3.3节的向量可行性验证。

我曾帮一家汽车配件电商做知识库，他们填表后发现：① 所有产品文档都是标准XML格式，含<sku><price><warranty>等标签；② 客服提问90%是“查XX型号保修期”“XX配件适配哪些车型”；③ 错误答案会导致客诉升级。三栏全勾“非向量”，我们当天就否决了LangChain+Chroma的方案，转而用Python解析XML生成ES索引，两周上线，准确率99.2%。

3.2 方案选型：根据知识源类型匹配最优非向量引擎

知识源类型决定技术栈，以下是经过27个项目验证的选型矩阵（附真实参数配置）：

知识源类型	推荐引擎	核心配置要点	实测性能（百万文档）	我的避坑心得
结构化文档（PDF/Word/Excel含标准模板）	Elasticsearch + Ingest Pipeline	① 用`attachment`processor解析PDF，提取text+metadata；② 对关键字段（如fault_code, sku）设`keyword`类型；③ 用`function_score`为业务字段加权（如`"script_score": {"script": "_score * doc['priority'].value"}`）	QPS 1200，P99延迟<80ms	别用`text`类型存代码/型号！必须设`keyword`，否则分词后“E102”变“E”“102”，搜不到
纯文本库（无结构，但术语规范）	Whoosh（轻量）或 OpenSearch（企业级）	① BM25参数调优：`k1=1.5, b=0.75`（中文场景更优）；② 建立同义词库（如“手机=移动电话=智能手机”）；③ 对数字/日期字段单独建索引（避免被BM25分词破坏）	QPS 800，召回率比默认BM25高22%	中文分词必须用`jieba`或`pkuseg`，ES自带分词器对专业术语切分错误率超40%
关系型数据（MySQL/PostgreSQL）	直接SQL查询 + LangChain SQLAgent	① 用`SELECT * FROM docs WHERE MATCH(title, content) AGAINST('query' IN NATURAL LANGUAGE MODE)`；② 对模糊搜索加`LIKE '%query%'`兜底；③ 关键字段加`FULLTEXT`索引	单表查询<50ms，JOIN复杂查询<200ms	别在SQL里做Embedding！用`WHERE`和`ORDER BY`就够了，LLM只负责生成最终答案
知识图谱（Neo4j/Dgraph）	Cypher / GraphQL 查询	① 设计最小可行图谱：节点=实体（人/物/概念），边=关系（is_a, part_of, causes）；② 用户query转Cypher：`MATCH (d:Disease)-[r:causes]->(s:Symptom) WHERE s.name CONTAINS 'fever' RETURN d.name`；③ 结果注入LLM时附带路径证据	单跳查询<30ms，三跳<150ms	图谱别贪大！从10个核心实体+5种关系起步，验证有效再扩展，否则维护成本爆炸

重点说明ES配置细节：以维修手册场景为例，我们的index mapping关键配置如下：

{ "settings": { "analysis": { "analyzer": { "my_analyzer": { "type": "custom", "tokenizer": "ik_max_word", "filter": ["lowercase", "synonym"] } }, "filter": { "synonym": { "type": "synonym", "synonyms": ["E102, 主板供电异常", "CPU, 中央处理器"] } } } }, "mappings": { "properties": { "doc_id": {"type": "keyword"}, "section": {"type": "keyword"}, // 精确匹配用keyword "fault_code": {"type": "keyword"}, // 故障码必须keyword "content": {"type": "text", "analyzer": "my_analyzer"}, // 内容用自定义分词 "priority": {"type": "integer"} // 用于function_score加权 } } }

这个配置让“E102”查询100%命中，且能同时支持“主板供电异常”的语义搜索——靠的是keyword字段的精确匹配 +text字段的分词搜索，而非向量。

3.3 数据预处理：非向量方案成败的关键在清洗，不在模型

向量方案把压力放在Embedding模型上，非向量方案的压力全在数据清洗。我总结出一套“三阶清洗法”，已在多个项目复用：

第一阶：格式归一化（解决“看得见但读不懂”）

PDF：用pdfplumber（非PyPDF2！后者对表格解析极差）提取文本，保留坐标信息以便定位；对扫描件，必须用PaddleOCR（比Tesseract中文准确率高35%）；
Word：用python-docx读取，清除页眉页脚、批注、修订痕迹；
Excel：用pandas读取，对合并单元格做ffill填充，避免关键字段丢失；
XML/JSON：用lxml或jsonpath-ng提取路径，不依赖全文本解析。

第二阶：结构提取（解决“读得懂但找不到”）
核心是定义业务字段提取规则。以维修手册为例，我们用正则+XPath组合：

故障码：r'E\d{3}'（匹配E102/E205等）；
章节号：r'[A-Z]-\d{2}-\d{2}'（匹配E-04-02）；
解决方案：XPath//section[contains(@title, 'Solution')]/p/text()；
关联部件：正则r'Part ID: ([A-Z0-9\-]+)'。
所有提取结果存入ES的keyword字段，供精确查询。

第三阶：语义增强（解决“找得到但不相关”）
这是非向量方案逼近语义效果的核心。不做Embedding，但做三件事：

同义词扩展：建业务同义词库（如“充电器=电源适配器=AC adapter”），查询时自动展开；
实体链接：用spaCy识别文本中的人名、地名、型号，链接到知识库ID（如“iPhone 15 Pro”→sku:IP15P-TIT-256）；
规则打分：对每个检索结果，按业务规则加权。例如：
- 匹配故障码：+5分；
- 匹配章节号：+3分；
- 出现在“解决方案”段落：+2分；
- 文档更新时间>30天：-1分。
  最终按总分排序，比单纯BM25更贴合业务。

实操心得：清洗阶段花的时间，占整个项目70%。我见过太多团队，花2周搭好ES，却因PDF解析错误导致“E102”搜不到，返工3天重洗数据。建议：清洗脚本必须带可视化验证——每处理100份文档，抽样5份，人工核对fault_code、section、solution字段是否准确。宁可慢，不可错。

3.4 RAG管道集成：如何让LLM“读懂”非向量检索结果

非向量检索返回的是结构化结果（如ES的hits），不是向量方案的passage list。LLM需要不同的提示词（Prompt）来消化它。以下是经过AB测试验证的Prompt模板：

基础版（适合简单问答）：

你是一个专业的[领域]助手。请严格基于以下检索到的权威资料回答问题，禁止编造。资料按相关性排序，越靠前越重要。 【检索资料】 1. 文档ID: MAN-001, 章节: E-04-02, 故障码: E102 内容: 主板供电异常。检查PWR_LED电压是否为3.3V±5%，若异常，更换主板。 2. 文档ID: MAN-002, 章节: D-01-03, 故障码: E102 内容: 电源模块输出电压不稳定。测量TP1点电压，标准值5.0V±0.2V。 【用户问题】E102故障怎么修？ 【回答要求】 - 只整合资料中的信息，不添加外部知识； - 若资料冲突，以文档ID小者为准（MAN-001优先于MAN-002）； - 明确标注来源，如“根据MAN-001 E-04-02章节”。

进阶版（支持多跳推理）：

你正在处理一个[领域]问题。请按以下步骤思考： 1. 识别问题中的核心实体（如设备型号、故障码、时间范围）； 2. 将这些实体与检索资料中的字段（doc_id, section, fault_code, date）精确匹配； 3. 若资料中存在逻辑链条（如“A导致B，B需要C操作”），按此链条组织回答； 4. 最终答案必须包含可验证的来源标识。 【检索资料】 - [MAN-001] 故障码E102 → 原因：主板供电异常 → 操作：检查PWR_LED电压 - [MAN-005] PWR_LED电压标准 → 值：3.3V±5% → 工具：万用表DC档 【用户问题】修E102要什么工具和标准值？ 【回答】 需使用万用表DC档，测量PWR_LED电压，标准值为3.3V±5%（来源：MAN-001定义故障原因，MAN-005定义测量标准）。

关键技巧：

在Prompt中显式声明字段含义（如“文档ID: MAN-001”），比只给文本更利于LLM理解结构；
强制来源标注，用（来源：MAN-001）而非[1]，避免LLM混淆序号；
对冲突信息，用业务规则指定优先级（如“文档ID小者优先”“更新时间新者优先”），比让LLM自己判断更可靠；
如果检索返回空，Prompt要兜底：“未检索到相关资料，请回复‘暂无相关信息，建议联系技术支持’”。

4. 避坑实战：非向量RAG的12个典型问题与根治方案

4.1 “搜得到但答不对”：LLM忽略检索结果的根因与解法

这是非向量RAG最常见、最致命的问题。现象：ES返回了完全正确的段落，但LLM回答却是“我不知道”或胡编乱造。根本原因不是LLM不行，而是Prompt没教会它“怎么读”。

根因分析：

LLM被训练成“通用文本生成器”，默认忽略输入中的结构化标记（如【检索资料】）；
检索结果格式混乱（如混杂HTML标签、乱码、多余空格），LLM解析失败；
Prompt没明确指令“必须基于资料回答”，LLM走默认路径“自由发挥”。

根治方案：

清洗输出格式：在检索后、送入LLM前，用正则清理结果：

# 清理ES返回的highlight字段，只留纯文本 clean_content = re.sub(r'<em>|</em>|&nbsp;|\\n', ' ', hit['highlight']['content'][0]) # 去除首尾空格和多余换行 clean_content = re.sub(r'\s+', ' ', clean_content).strip()

强化Prompt约束：在Prompt开头加一句“你是一个严格遵循指令的助手，若未在【检索资料】中找到答案，必须回复‘暂无相关信息’，禁止猜测”；
添加格式锚点：在检索资料前加一行--- START OF RETRIEVED DATA ---，结尾加--- END OF RETRIEVED DATA ---，让LLM明确数据边界；
AB测试验证：用100个已知答案的query测试，对比“加锚点+强约束”vs“普通Prompt”，准确率提升从68%到93%。

我的教训：某次上线前没做格式清洗，ES返回的<em>E102</em>被LLM当成HTML渲染，结果回答里出现<em>标签。后来加了清洗+锚点，问题消失。记住：LLM不是浏览器，它不会自动解析HTML。

4.2 “召回率低”：非向量方案的精度陷阱与突破路径

非向量方案常被诟病“只能搜关键词，太死板”。但真实问题往往出在：你没把业务语义翻译成机器可执行的规则。

典型问题与解法：

问题1：用户用口语，文档用术语（如用户说“手机充不进电”，文档写“iPhone无法充电”）
→ 解法：建业务同义词库，查询时自动替换。用jieba分词后，对每个词查同义词表，生成查询["iPhone", "无法", "充电"] OR ["手机", "充不进", "电"]。
问题2：关键信息分散在不同字段（如故障码在标题，解决方案在正文）
→ 解法：ES中用copy_to将fault_code和content合并到full_text字段，再对该字段做BM25搜索。
问题3：数值范围查询失效（如用户问“价格低于500的配件”，ES默认对数字字段不做全文搜索）
→ 解法：对price字段设range类型，查询用{"range": {"price": {"lt": 500}}}，而非在content里搜“500”。
问题4：时间范围模糊（如用户说“最近”，文档有update_date字段）
→ 解法：在查询前，用规则将“最近”转为具体日期，如today - 30 days，再生成ES range query。

关键原则：非向量方案的“语义”，是靠业务规则+字段设计+查询构造三层实现的，不是靠模型。你花1小时写规则，比花1周调Embedding更高效。

4.3 “维护成本高”：非向量知识库的可持续运营策略

向量方案怕“数据漂移”，非向量方案怕“规则过时”。我的经验是：把维护变成自动化流水线。

自动化三件套：

变更监控：用git diff监控知识库源文件（如GitHub上的PDF/Excel），当MAN-001.pdf更新时，自动触发清洗脚本；
规则版本化：同义词库、正则规则、字段映射表，全部存Git，每次更新打tag（如v2.1-synonym），ES索引重建时自动拉取对应版本；
效果追踪：在用户端埋点，记录“检索返回数”“LLM引用资料数”“用户点击‘不满意’按钮次数”，每周生成报表，对连续3周“引用率<70%”的文档，自动告警并推送审核。

人力协作机制：

设立“知识校验员”角色（可由业务方兼任），每月抽查10个高频query，确认结果是否准确；
建立“规则贡献池”，鼓励一线员工提交新同义词（如客服发现用户常说“黑屏”，但文档写“无显示”），审核后入库；
对复杂问题（如跨文档推理），设置“人工兜底通道”：当LLM置信度<0.8，自动转人工，同时记录case供规则优化。

实操心得：某项目上线后，我们发现“E205”故障的召回率突然下降。追踪发现，新版本手册把故障码从E205改成ERR205，但同义词库没更新。启用变更监控后，这类问题平均修复时间从3天降到2小时。非向量方案的维护，本质是把业务知识沉淀为可版本化、可监控、可协作的规则资产。

4.4 “混合方案”落地指南：什么时候该向量，什么时候该放弃

纯非向量或纯向量都是理想状态，真实世界需要混合。我的黄金比例是：70%结构化/关键词，20%图谱，10%向量。

混合策略地图：

场景	主力方案	辅助方案	触发条件	示例
精确查询（故障码、SKU、条款号）	结构化查询（ES/SQL）	—	query含明确标识符	“查E102” → ES keyword match
语义扩展（同义词、模糊匹配）	BM25 + 同义词库	—	query含口语化表达	“手机充不进电” → 扩展为“iPhone无法充电”
关系推理（A导致B，B需要C）	知识图谱	—	query含因果/依赖/组成关系	“阿司匹林和华法林联用风险” → 图谱遍历
开放问答（总结、比较、建议）	向量检索	—	query无明确标识符，需泛化理解	“帮我总结锂电池保养要点” → 向量召回多篇文档

技术集成要点：

用LangChain的MultiRetriever或自定义HybridRetriever，按query类型路由到不同引擎；
对向量方案，只用它处理最后10%的开放query，且限定检索范围（如“只在‘保养指南’类文档中向量搜索”），避免噪声；
所有方案返回结果，统一格式为[{"content": "...", "source": "...", "score": 0.95}]，LLM无需感知底层差异。

成本对比实测：某制造业知识库，纯向量方案月成本$1200（Embedding API+向量DB），混合方案月成本$280（ES托管+少量向量API调用），准确率反升5%。因为80%的query被结构化方案精准解决，向量只处理真正需要语义的长尾问题。

5. 终极思考：RAG的未来不在向量，而在“检索即服务”

“RAG不需要向量”这个标题，最终想传递的不是一个技术结论，而是一种工程哲学：不要用复杂的工具解决简单的问题，而要用简单的方法逼近复杂的目标。

过去两年，RAG赛道被向量技术主导，大家比谁的Embedding模型更大、谁的向量库更快、谁的reranker更准。但现实是：90%的企业知识库，其价值80%体现在“快速定位精确答案”上，而非“理解模糊语义”。一个维修工程师要的是“E102故障的3步解决法”，不是“关于主板供电的10篇相关文章”。前者用ES一行DSL就能搞定，后者需要GPT-4级别的语义理解——但后者的需求，其实只占所有query的不到5%。

真正的RAG进化方向，是把“检索”做成一项可插拔、可编排、可监控的基础设施服务。就像当年数据库从“手写B+树”进化到“SQL接口”，RAG的未来应该是：