最近在折腾一个新的搜索项目，名字叫 Sirchmunk，核心思路一句话就能讲清楚：完全不要向量数据库，把搜索引擎做成一个能自己根据用户反馈持续进化的系统。是的，你没看错——不依赖那些动辄几十万维度的嵌入向量，不依赖余弦相似度计算，更不需要单独维护一套庞大的向量索引集群。整个项目做下来，我对传统 RAG 方案的依赖程度有了完全不同的认识，也踩了不少坑，这里整理成一篇深度解析，分几篇发，这是第一篇，重点讲整体架构设计和为什么可以去掉向量数据库。
先说明这个项目适合谁看：如果你正在做检索增强生成（RAG）类应用、企业内部知识库搜索、或者电商/内容平台的站内搜索，并且被向量数据库的高昂维护成本和召回结果不稳定的问题困扰，这篇文章值得从头读一遍。如果你是被"自进化"三个字吸引过来的，也可以放心看，这个机制实际落地起来并不玄乎，本质上就是用点击反馈、停留时长、二次检索行为来动态调权重，属于工程上完全可控的范围。
1. 为什么放弃向量数据库？——传统 RAG 方案的三个硬伤
先聊动机。不是所有场景都需要语义向量搜索，这个判断在动手前就要想清楚。Sirchmunk 最初的原型其实也采用了常规做法：文本切块、Embedding 入库、向量检索 TopK。但测了一两个月之后，我发现有三个问题非常致命，尤其在垂直领域知识库场景下。
第一个问题是语义召回的不稳定性。向量检索本质上依赖 Embedding 模型对文本语义的压缩质量，而通用 Embedding 模型在专业术语、混合中英文、简称与全称对应这些场景下表现很不稳定。同一句话稍微换个表述，召回的 TopK 结果可能完全不同。测试集上 accuracy 调得再高，线上实际用户一提问，召回质量立刻现原形。某次我在一个模拟医疗问答项目里试过，用户问"降压药有哪些副作用"，向量检索召回来的却是一堆关于"高血压发病机制"的片段，相关度排序逻辑完全不可解释，这种黑盒特性让问题定位变得非常困难。
第二个问题是索引更新的滞后性。向量数据库要支持增量更新，通常得重算受影响切块的 Embedding 再写入向量索引，这个过程少则分钟级、多则小时级。对于需要实时吸收新文档、新知识条目的搜索系统来说，这种滞后很致命。更别提删除操作了，很多向量数据库的删除是标记删除，物理空间不会立即释放，索引体积只增不减。我有一台测试服务器，跑了一个中等规模的知识库，向量索引三个月就膨胀了快两倍，存储成本直线上升，最终只能定期重建索引来瘦身，非常折腾。
第三个问题最容易被忽视：协同信号的利用率为零。传统向量检索只分析"查询文本"和"文档文本"之间的语义距离，完全不关心用户对检索结果的实际反馈。谁知道用户点了哪条结果、停留了多久、是否发起了二次检索？恰恰是这些行为数据，才是让搜索越用越准的最宝贵信号。同一个查询，点击集中在第三条结果上，说明排序权重有问题，但向量检索无法感知这种信号，下一次召回还是同样的顺序，系统的智能程度始终停留在模型出厂时的水平，不会成长。
基于这三个硬伤，我下定决心把向量数据库从架构里整个拿掉。取而代之的是一套基于稀疏编码 + 倒排索引 + 动态反馈权重的设计。听起来好像回到了十年前的搜索引擎老路上，但实际上是换了一套全新的组织逻辑：利用传统检索的确定性优势，再把行为反馈注入排序环节实现自进化。这套架构既没有失去语义匹配能力，又获得了实时更新和持续优化的能力，最终效果远超预期。
2. Sirchmunk 整体架构设计——无需向量库如何实现语义级检索
2.1 三层层级结构：从查询文本到确定候选集
Sirchmunk 的总体架构可以划分为三层：接入与解析层、索引与召回层、排序与反馈层。
接入与解析层负责把原始查询文本标准化。这里做的不是简单的分词，而是一套多策略解析流水线：先做基础清洗和归一化（繁简体转换、英文大小写归一化、全半角统一），然后并行执行关键词抽取、命名实体识别（NER）、同义词扩展、以及术语改写。以"降压药的副作用有哪些"为例，经过解析层会得到三组信号：核心关键词（降压药、副作用）、实体识别结果（药品类实体：降压药，医学属性：副作用）、以及扩展词集合（抗高血压药物、不良反应、服药后反应等）。这三组信号以结构化 JSON 的形式传给下一层。
索引与召回层是整个架构的精髓。Sirchmunk 采用的索引结构是切词倒排索引 + 实体倒排索引 + 属性链式索引的组合体。相比传统全文检索，这里的倒排索引不是单纯的 term 到 doc 的映射，而是维护了三套独立索引，每一套索引的设计目标都不一样：
切词倒排索引应对字面匹配。使用了自研的分词器，能够识别出人名、机构名、药品名、疾病名等复杂实体，再辅以拼音索引和同义词扩展映射表，因此"fuyaoyao"也能命中"降压药"。实体倒排索引应用在垂直领域知识库中效果特别明显。如果文档集合相对垂直，比如医疗、法律、金融，那么提前抽取好文档的实体，并为主实体建索引，就能获得非常强的确定性召回能力。"降压药"这个实体一旦建好索引，所有药品相关的文档都会被拉到一个候选集合里，这个集合远远比向量召回的结果稳定可靠。
属性链式索引是一种很有意思的轻量语义关系建模。比如"药物的不良反应"、"疾病的临床表现"、"政策的适用对象"，这些在文档中反复出现的属性关系，我们可以提前用规则抽取出来，形成一个语义三元组（主体实体，属性，对象）。再把这种语义三元组以属性的形式挂在实体索引下，查询进来时先解析出实体和属性，直接通过属性链式索引命中，不需要代数运算就能完成"跨术语"匹配。这个设计直接解决了纯关键词搜索"同义不同词"的痛点，而且成本极低。
排序与反馈层承担自进化的核心职责。候选文档集被召回后，必须有一个合理的排序模型把最相关的排到最前面。这里的排序分数不依赖 Embedding 相似度，而是一个带权实时加总的多因子策略：文本覆盖面（分解后的关键词有多少比率命中文档）、实体匹配度、属性链命中权重、以及最重要的动态行为权重。动态行为权重由反馈系统持续更新，每一条新反馈都会实时影响后续查询的排序。这个设计方案的好处是，每个环节的决策都具备可解释性，不透明黑盒带来的麻烦从一开始就不存在。
2.2 自进化机制运转流程：反馈怎么变成排序权重
自进化一说出来，很多人第一反应是强化学习，觉得工程复杂度太高，小团队没法落地。实际上 Sirchmunk 走的是一条偏工程的轻量路线，核心只有三个环节：行为采集、信号聚合、权重更新。
行为采集分布在检索链路的各个环节。前端的埋点在用户点击某条搜索结果时记录 clicked_doc_id；系统统计从展示列表到点击动作之间的延迟时间，间接作为"注意度"特征；追踪用户点击之后的后续行为，是否复制文本、是否点赞、是否发起了新的检索词。相比直接设计复杂的评分模型，Sirchmunk 这种方式相当朴素，但覆盖面很全，足以构成多维度的行为画像。
信号聚合环节把这些原始行为按查询词归类。试想"降压药副作用"这个查询一共出现了 300 次，其中 200 次点击了文档 A、停留时长超过 30 秒、并且没有继续发起二次检索，而只有 30 次点击了文档 B，那么这个查询词对文档 A 的正向偏好信号就非常强。信号聚合模块把这些统计数据沉淀为一张行为反馈表，基本结构就是：查询词、文档、正向行为数、负向行为数（定义比较明确，比如点击后 5 秒内立刻返回），最后计算出一个行为置信分。
权重更新是整个系统里最有技术含量的部分。拿到聚合后的信号，不能直接把某个文档的权重拉满，否则会出现马太效应，最热的结果永远排在前面，新的优质内容完全没有出头机会。Sirchmunk 采取的是增量式修正方案：保留初始的相关性排序分数作为基准，在行为反馈置信度达到阈值后才开始附加权重修正，而且修正量有上限控制。它还引入了时间衰减因子，昨天的 100 次点击和今天的 100 次点击对权重修正的影响程度是不同的，新近的反馈被赋予更高的权重，这样系统才能持续跟上用户需求的变化。全部逻辑用纯 Python 实现，没有背靠任何机器学习框架。
自进化的完整闭环是：查询进入解析层产生结构化信号，带权召回候选文档，排序层对候选用多因子打分并返回结果，用户行为被实时埋点捕获，信号聚合模块把行为沉淀为权重调整指令，权重更新模块按指令修正后续查询的排序结果。这个闭环的迭代周期，从用户点击到影响下一次相同查询的结果排序，大约只需要几秒时间，完全做到了实时级进化，根本不需要重训练模型。
3. 公路实操：索引结构设计中的模块开发要点
3.1 倒排索引与语义三元组构建
先把索引结构落地。Sirchmunk 的索引存储没有用专门的搜索服务器，直接用轻量级 KV 存储加内存映射表搞定，因为这毕竟是一个独立项目，目标是验证架构可行性。切词倒排索引的表结构遵循标准设计：term 作为 Key，映射到一组携带位置信息的 doc_id 列表。关键设计点是把位置信息保留得非常完整，因为后续在做短语匹配和 proximity 权重计算时都会用到。
实体倒排索引的结构略有不同，Key 是标准化的实体名，Value 除了 doc_id 列表以外，还额外带了一个 entity_type 字段，比如药物、疾病、症状、操作步骤等。构建方法依赖 NER 模块对全量文档做离线批处理，把识别出来的实体统一做名称归一化，也就是把别名、简称全部映射到标准名上。比如"降压药"可能同时对应"抗高血压药物"和"antihypertensive drugs"，归一化后可绕过通用搜索对英文术语识别不友好的问题，直接挂到同一个实体 ID 上。这一步全部离线完成，支持定时全量重建，构建成本远低于向量索引的 GPU 批量推理，用普通 CPU 服务器就可以轻松承担。
语义三元组索引更值得细说。一般做法是定义一组属性规则模板，用正则和依存句法分析结合的方式，从句子里抽取出主体、属性、对象。例如"长期服用降压药可能导致肝功能异常"，通过语义规则可以抽成（降压药，可能导致，肝功能异常）。处理后的三元组写入属性链式索引，查询时如果解析出"降压药"和"副作用"两个信号，就可以直接沿着属性链找到所有挂有"副作用"属性的文档，完全不需要做向量计算。
索引构建的流水线同时具备增量能力。新文档进来后，先把原始文本写入文档存储，然后通过消息队列触发解析任务，经解析后分别写入三套索引。整个过程设计成完全可重放的，某一步出错了可以只重跑当前文档的解析任务，不会影响全局索引的稳定性。这一点在正式使用后很重要，因为文档更新频率往往比想象中高很多。
3.2 三元组的实际创建流程
这里给出一段简化版的实际创建流程。开发时用 Python 写了一个 pipeline，核心逻辑大致如下：
首先是文档解析器，统一处理 Markdown 和纯文本格式，提取标题层级、段落文本和列表结构。然后是实体识别器，加载自定义实体词表和轻量规则，输出实体列表。接着是三元组抽取器，使用依存句法分析结果做规则匹配，把满足模板的句子抽成三元组。最后是索引入库器，把切词索引、实体索引、三元组索引各自写入 KV 存储。
# 伪代码：语义三元组抽取与索引写入逻辑 def build_triples(doc_id, sent_text): # 1. 实体识别 entities = ner_tagger.extract(sent_text) # [('降压药', 'DRUG'), ('肝功能异常', 'SYMPTOM')] # 2. 关系候选识别 rels = relation_rules.match(sent_text, entities) # [('可能导致', 'CAUSE')] triples = [] for head, rel, tail in rels: triples.append({ "head": head, "relation": rel, "tail": tail, "doc_id": doc_id, "snippet": sent_text }) # 3. 写入属性链式索引 for t in triples: chain_index.add( key=(t["head"], t["relation"]), # ("降压药", "可能导致") value={"tail": t["tail"], "doc_id": t["doc_id"], "snippet": t["snippet"]} ) return triples这条流水线跑完之后，一个垂直领域文档库的三元组覆盖率能达到百分之六十以上，剩余的句子仍然可以通过切词倒排索引兜底召回。双重保障下，"不同词表达同一语义"的文档召回问题基本被解决了。
3.3 查询流水线：解析、召回、排序一手包办
Sirchmunk 的查询流水线从接收原始 query 到最终返回结果，整个过程被封装成一个统一入口，对外暴露 RESTful API。内部依次执行四道工序。
工序一：标准化与解析。对 query 做清洗，然后执行关键词切分、实体识别、同义词扩展、属性抽取。最终产出一个结构化查询对象，包含关键词表、实体表、属性条件表。
工序二：多路召回。并行执行三路召回操作：切词索引召回、实体索引召回、属性链索引召回。每路召回返回一组带基础相关性分的 doc_id，三组结果做并集处理去重，得到候选池。召回阶段追求的是高召回率，宁可多召回一些可能相关的文档，也不要在这一层把真正相关的文档滤掉。
工序三：相关性打分。对候选池逐文档计算综合相关性得分。得分由四部分加权组成：关键词覆盖得分反映命中的关键词数量和权重；实体匹配得分反映命中的实体类型数量，实体越核心，分越高；属性链得分反映匹配到的属性链精确程度；位置权重得分反映命中的关键词在文档中出现位置，标题、首段得分更高。
工序四：动态排序调整。把动态行为分数叠加到基础相关性得分上，做混合排序。行为分数的计算会在下文详细展开，这里重点提一下关卡逻辑：系统对一个候选文档的行为置信度低于某个低保真阈值时，行为分不生效，完全按基础相关性排序；一旦置信度超过阈值，动态分才开始发挥影响力。设置阈值的目的在于过滤稀疏、噪声极大的低质量信号。
4. 系统实战：一次完整检索的生命周期记录
4.1 从用户输入到结构化查询
拿"降压药吃了头晕正常吗"这个查询来演示一遍完整流程。真实用户不会按照文档规范来提问，一句话里就可能夹杂口语表达、症状描述、以及不明属性指向，整个解析过程很有挑战性。
查询先进入文本标准化阶段。繁简体转换、英文小写化、连续字符处理之后，进入分词和实体识别环节。分词器会把"降压药"识别为药品实体，把"头晕"识别为症状实体，而"吃了"会被归入口语化谓词，"正常吗"则会被识别为疑问意图标记。同义词扩展模块进一步把"头晕"扩展为"眩晕"、"头昏"，把"降压药"扩展为"抗高血压药"。属性识别模块尝试分析"头晕"与"降压药"之间的潜在关系，匹配到已有的"不良反应"、"副作用"、"服用后症状"这几个属性维度。
最终产出的结构化查询包含这些关键项：核心实体是"降压药"（类型：药品），"头晕"（类型：症状）；关键词词表包含降压药、抗高血压药、头晕、眩晕、头昏；属性条件包含副作用、不良反应、服用后；意图标记为"疑问"。这个结构化对象传到召回模块时，已经把口语化的输入转化成一盘明确的检索信号了。
4.2 三路召回并行推进
召回模块收到结构化查询后，并行触发三路召回。切词索引召回用关键词表逐一匹配倒排索引，每个关键词的 doc_id 列表求并集。这一步产出一批包含"降压药"或"头晕"的文档，数量相对较大。实体索引召回使用药品实体"降压药"直接命中实体索引，把收录了该实体的文档全部拉出来，作为更精确的主候选集合。属性链索引召回使用（降压药，副作用）这个属性组合去查属性链索引，命中"不良反应"、"副作用"等属性关联的文档，这是最精准的一路召回。
三路结果求并集后，得到一个容量适中的候选池。每一个候选文档附带所在召回路的类型信息和基础相关性分。切词召回的结果分比较低，实体召回的分较高，属性链召回的分最高。候选池可能仍然包含一些相关性不高的文档，完全靠排序层进一步过滤。
4.3 排序融合与反馈注入
排序模块对候选池逐一计算综合分。以一篇科普文章作为例子，它的标题是"服用降压药后出现头晕的原因分析"，文章正文覆盖了不良反应、药物副作用、应对方法等内容。关键词覆盖得分很高，标题和首段同时命中"降压药"和"头晕"；实体匹配得分也很高，因为文档中同时出现了高血压、降压药、头晕这三个核心实体；属性链得分拿得最满，因为（降压药，不良反应）这个三元组直接被命中。这篇文章的综合基础分在候选池里排名前列。
动态排序调整阶段会再检查一个关键因素：行为反馈表里有没有针对"降压药 头晕"这个查询的历史数据。如果过去有大量用户点击了这篇文章并且停留较长时间，正向行为信号就会累积，行为置信分叠加在基础分上，排名可能进一步提升。反之，如果历史反馈里显示很多用户点了这篇文章后短时间内就返回并换了一个查询，负向信号就会降低一点它的排序位置。这就是自进化机制完全不需要重训练就能感知用户真实偏好的直观流程。
最终接口返回的排序列表，基本能将用户最想要的那篇文档稳定推到第一位。整个生命周期从查询进入到响应返回，耗时大约在数十毫秒级，主要开销集中在分词和属性识别上，比动辄几百毫秒的向量检索链路反而更快。
5. 常见问题与排查技巧实录
5.1 冷启动阶段没有行为数据怎么办
自进化机制上线初期的尴尬在于，完全没有行为反馈可依赖，排序完全靠基础相关性分。这时的排序效果取决于前期索引构建的质量，需要做比较充分的文档解析和属性抽取。冷启动期建议先人工维护一批高质量种子文档的三元组和实体标签，宁缺毋滥，确保初始阶段检索效果在线。行为数据经过一段时间积累后，动态排序的力量才会逐渐体现出来。从我的实际经验看，大约跑一到两周，主流高频查询词的排序质量会有可感知的提升。
5.2 反馈噪声与异常点击怎么过滤
不是所有用户行为都值得被当作训练信号。误点击、乱点、无意义刷新都会污染行为权重。Sirchmunk 在信号聚合层做了三层过滤机制。第一层是停留时长过滤，点击后停留时间过短视为无效点击，不进入统计。第二层是会话内频次限制，同一个用户短期内对同一文档的多次点击只计一次有效行为。第三层是全局异常检测，某个文档的点击量出现异常陡增时，需要做权重保护处理，防止被批量刷出来的虚假信号带偏排序。三层过滤下来，反馈数据的可信度会高很多。
5.3 索引膨胀与性能退化问题
索引膨胀在任何搜索系统里都躲不掉。Sirchmunk 的应对策略分两种：一种是对索引做按周分片存储，新索引实时写当前周分片，旧分片保持只读，查询时跨分片合并结果；另一种是定时全量重建索引，把废弃实体和冗余三元组彻底清理掉。实际跑下来的经验是，每周做一次全量重建任务，耗时基本可控，且重建过程中旧索引保持服务不中断，等新索引就绪后再做原子切换，不会造成可用性问题。
5.4 归因与调试技巧
比修复问题更重要的是定位问题。Sirchmunk 的每个查询都会记录结构化的调试快照：解析阶段的全部中间产物、召回阶段各路的召回数量、排序阶段每个因子的得分明细、动态调整中行为分的生效情况。排查排序异常时，直接在日志里看各因子得分就行，到底哪一路召回了错误文档、哪个关键词加权出了问题、哪条行为反馈把结果带偏了，一眼可辨。这种全链路可解释性，是我觉得这套架构相比向量检索方案最大的隐形优势。
对于想自己上手复刻这套架构的朋友，我的建议很实在：不要一开始就铺太多功能。先实现基础的切词倒排索引加关键词召回，把在线检索通路跑通，再逐步加入实体索引和属性链索引，最后再接行为反馈闭环。每一步都要能独立验证效果，否则全部堆在一起出问题根本没法定位。Sirchmunk 后续还会继续在语义细粒度对齐、跨库索引合并、以及个性化反馈分层几个方向继续迭代，下一篇准备重点写自进化排序权重的时间衰减算法细节，如果看到这里觉得有启发，欢迎一起交流实际落地中的具体问题。
