企业官网建设流程全解析

一提到RAG知识库，绝大多数人的第一反应就是：先建一个向量数据库。选型阶段先纠结pgvector还是Milvus，然后准备embedding服务、设计切分策略、调HNSW参数，最后才是写问答逻辑。这套流程几乎成了RAG的“标准动作”。但我在实际跑了几个知识库项目之后，越来越怀疑这个默认动作的必要性。尤其是看到Jev这套新的RAG范式后，我直接把原本的向量库方案推倒重来，换成了一种“不必先建向量数据库”的路线。这篇文章就讲讲我这段实践里看到的本质区别、具体操作步骤，以及哪些场景下我仍然会老老实实回去用向量库。

1. 先建向量库这个“默认动作”，其实是RAG里最大的隐性成本

我先交代一下背景。最早做团队内部知识库时，我用的是一套非常标准的RAG流水线：文档解析 -> 切块 -> embedding -> 写入向量库 -> 查询时向量召回 -> 重排 -> 交给LLM生成。这是一条被无数教程验证过的路线，看起来没有任何问题。真正的问题藏在“看起来没问题”背后——每一个环节都在持续消耗你的时间和注意力。

1.1 一套标准RAG流水线究竟藏了多少环节

很多人以为向量库只是一个“存向量的地方”，实际上牵一发动全身。我把当时的完整依赖链条列一下：

• 文档加载层：PDF、Word、Markdown、网页正文，每种格式都要单独的解析方案；
• 清洗层：去页眉页脚、去模板噪音、处理表格和代码块；
• 切分层：chunk_size取多少、overlap设多少，决定召回颗粒度；
• Embedding层：选bge还是text-embedding系列，本地部署还是调API；
• 向量库层：选型、部署、索引参数调优；
• 召回层：top_k、score阈值、是否需要rerank；
• 生成层：prompt里怎么拼上下文、怎么控制幻觉。

这条链路里，向量库不是终点，而是所有环节的粘合剂。任何一个环节变动，都会引发连锁反应。我印象最深的一次：换了新的embedding模型后，原本已经跑通的检索效果突然变差，排查了半天才发现是向量维度和旧索引的相似度分布不一致，最后只能全量重新embedding一遍。这种隐性成本不会写在任何教程里，但每个做过RAG的人都会遇到。

1.2 切分粒度与召回效果之间的死循环

向量库方案里，切分粒度直接决定召回质量。我踩过一个经典坑：长文档固定512字符切块，结果一个完整的技术方案被拦腰切成好几段。用户问“权限设计的整体思路”，向量召回回来的top5块分别是“背景”“数据库设计”“接口列表”“注意事项”“目录”，没有一块包含完整上下文。生成模型只能靠这些碎片脑补，回答自然不靠谱。

后来我改成按标题层级切分，块大小差异很大，向量检索的score分布又变得不稳定——因为不同长度的块在做cosine相似度时天然不占优。再后来尝试overlap交叉切分，上下文是接上了一些，但存储量膨胀、检索噪音也变多了。这就是一个死循环：想保住上下文语义就切大块，大块向量相似度不敏感；想抓准语义就切小块，小块容易丢失上下文。向量库本身解决不了这个问题，它只负责把你的切分结果存起来再检索出来。

打个比方：这就像你为了让图书馆里的书更容易找到，先给每个句子做一张卡片，把所有卡片按“内容相似度”堆在一起。问题是语义相似的句子可能来自完全不同的话题，而同一篇文章的上下文被拆散到了几十堆卡片里。到最后你找到的不是书，而是卡片碎片。

1.3 知识更新时的重建与过期问题

知识库和搜索引擎最大的区别是：知识库的内容应该持续更新。团队Wiki每周都在变，农业问答库每个季度都要补充新病害资料。向量库方案里，每次新增一篇文档都要跑一遍embedding流程、执行向量入库、更新索引；如果修改了原有文档，旧向量还需要定位删除，否则知识库里会存在“同一内容两个版本”的冲突。

我用Dify搭过知识库流水线，印象最深的就是“排队中”这三个字——文档一多，embedding任务排队几十分钟是常事。更麻烦的是，embedding模型一旦更新，或者发现之前解析文档的模板有问题，所有历史向量都得重新生成。这个重建成本高到让人不敢轻易优化流程。向量库本身也在持续产生运维负担：pgvector的索引膨胀需要vacuum，Milvus要操心集群状态。知识库的核心价值是让知识被快速调用，但维护这套基础设施的精力，早就超过了知识本身的管理成本。

2. Jev路线的核心机制：把检索问题从“存进去”改成“算出来”

被这些隐性成本折磨了两三个月之后，我开始尝试Jev这套新范式。它不是又一个向量数据库选型，而是直接把整个问答管线的结构改掉了——不在查询之前建立庞大的向量索引，而是把检索当成一个即时计算的过程。

2.1 Jev运行时到底改了什么

Jev路线的基本流程可以概括成几步：

1. 文档进入知识库时，只做两件事：解析成结构化的Markdown原始块，建立轻量级倒排索引；
2. 倒排索引不存向量，只存词项到文档位置的映射，基于BM25这类经典算法做初筛；
3. 用户提问时，先用倒排索引快速粗筛出一批候选块，这一步毫秒级完成；
4. 再调用一个小型语义重排模型，对候选块做精细排序；
5. 把排序靠前的块连同其父级上下文一起交给生成模型，生成回答。

整个流程里没有“先embedding全库”的环节。我在自己机器上跑的时候，索引构建就是对SQLite的FTS5表做插入操作，文档进来即可查，不需要等待任何向量化任务。这套结构最直接的好处就是：新增文档即时生效，修改文档只需重建当前文档的倒排项，全量重建一个几百篇文档的知识库只需要几十秒。

2.2 为什么小模型也能做知识库

热词里有个问题特别典型：“卡帕西的知识库可以用小模型做吗”。我把Jev跑通之后，答案是肯定的，而且不是你硬把知识塞给模型记住，而是把“记忆”交给检索系统。知识库问答的本质是定位证据、组织上下文、生成表达，而不是让模型全文背诵。

传统RAG把大量精力花在“让向量检索找到语义相似的内容”上，但语义相似和“信息正确”是两回事。两条表述语义相近，可能一条讲的是历史方案、一条讲的是当前推荐方案；向量会把它们都召回，却无法区分时效性。而Jev路线里，倒排索引保证的是词面级精确命中，重排模型再按语义相关性精修，最后生成模型拿到的是一个“完整话题块”，而不是碎片。

这也回应了“用小模型做知识库”的核心思路：模型本身不需要很大，因为绝大多数知识来自检索到的上下文。我在Jev路线里用的主干模型，量化后也就几个GB，完全本地跑，回答质量问知识类问题时并不比我在线调大模型差多少——差别主要是表达流畅度，而不是事实准确度。

2.3 我删掉的组件清单

切换到Jev路线后，我从架构里删掉了这些东西：

• 向量表（原先的embeddings存储表）；
• ANN索引及其调参工作（HNSW的M参数、efConstruction这些不再需要）；
• 独立的embedding服务（少了一个需要监控的中间件）；
• 向量库的备份和运维任务。

一开始我很不习惯，总感觉“没有向量库的RAG不像RAG”。但跑了一周后我发现，删除组件并不是功能降级，而是在这个知识库场景里，这些组件本来就是多余的。就好比你本来只需要一个准确的目录和几本完整的书，却在图书馆里建了几千万张语义卡片，最终查起来反而更慢。

3. 用Jev重新搭一个知识库：端到端实操步骤

光讲原理不过瘾，我把实际操作过程完整写一遍。输入场景是：有一个本地文件夹，里面的内容是团队几年来积累的Markdown文档、PDF报告、网页存档，还包括一批截图和扫描件。

3.1 文档准备与格式归一化

Jev路线对输入格式有一个明确要求：必须是结构化的纯文本。所以第一步是统一格式。我的做法是写一个解析脚本，把PDF用文本抽取工具转成Markdown，Word转成Markdown，网页正文用可读性提取再转Markdown。图片知识库怎么处理？这是许多人问的问题，我的答案很直接：不要试图把图片存进知识库，而是把图片翻译成结构化文本。

截图和扫描件用OCR工具提取文字，识别结果连同一个“图片说明”文件一起入库。架构图、流程图这些OCR不友好的图片，我会人工补一行说明文字，比如“图：订单系统架构，从上到下分为接入层、服务层、数据层”，然后把这个说明作为该图片的索引元数据。这样用户问“订单系统架构图”时，倒排索引能通过“订单系统”“架构图”这些词精准命中，生成模型则根据说明文字组织回答。如果你非要做成以图搜图，那是另一套多模态向量检索的问题，不在知识库问答这个场景里。

工具选择上我用的是开源方案，解析PDF用pandoc加文本抽取，OCR用PaddleOCR。对于历史网页存档，先做HTML净化再统一转Markdown。整个过程跑完，输入目录是一堆干净的Markdown文件，每篇文档的标题层级（H1/H2/H3）都保留完整，这是后面一切检索的基础。

3.2 记忆块组织与轻量索引

Jev路线里，我把“切分”改成了“话题块切分”。不按固定长度硬切，而是按标题层级切：一个二级标题及其下面的内容算一个话题块。如果某个二级标题下的内容过长，再按三级标题继续细分。每个块会记录自己在原始文档中的路径，比如“docs/农业知识库/玉米病害/大斑病防治.md#防治方法”，这样生成模型在回答时能引用出处。

索引层我用的是SQLite的FTS5，启用中文分词。中文场景下FTS5默认分词器对中文支持一般，需要追加ngram分词器设置。对几百篇文档的规模来说，这个索引的构建时间基本可以忽略，我自己测试的大概是200篇文档全部入库不到30秒。核心代码逻辑大概是这样的：

import sqlite3 def build_index(doc_blocks): conn = sqlite3.connect("kb_index.db") conn.execute("CREATE VIRTUAL TABLE IF NOT EXISTS fts USING fts5(text, content='')") for block in doc_blocks: conn.execute( "INSERT INTO fts(rowid, text) VALUES (?, ?)", (block.id, block.text) ) conn.commit()

查询时先做BM25粗筛拿候选集，再交给重排模型精排。重排模型我单独加载了一个小型的cross-encoder模型，CPU上单条查询大概几十毫秒，完全可接受。值得注意的是，这个重排环节是整个Jev路线的关键，它补偿了倒排索引在语义匹配上的短板，让“用户问的是概念、文档写的是具体名词”这类情况也能被覆盖到。

3.3 问答流程与本地部署

问答阶段的核心函数逻辑如下：

def ask(query, top_k=5): # 第一步：BM25倒排粗筛，取前30个候选块 candidates = fts_matches(query, limit=30) # 第二步：cross-encoder重排，取前5个 ranked = reranker.rerank(query, candidates, top_k=top_k) # 第三步：找回每个块的父级上下文，按原始文档顺序拼接 context = join_parent_context(ranked) # 第四步：交给生成模型 return llm_generate(context=context, question=query)

部署上，全程本地。主模型我用的Ollama加载，Windows系统也能直接跑，不需要GPU就能完成整个问答流程——当然，没有GPU时生成速度会慢一些，但重排和检索部分不吃显卡。启动顺序也很简单：先把文档解析跑一遍，生成规范化的Markdown目录；再跑索引构建脚本生成FTS5库；最后启动一个本地问答服务。整个过程没有vector database，没有embedding接口，没有等待队列，看到的效果是文档一进去就能立刻提问。

4. 我拿它跑过的两类真实场景：农业知识库与团队Wiki

理论说得再多，不如实际场景来得可信。这里贴两个我实际跑通的案例，都是热词里大家关心的方向。

4.1 农业知识库场景

第一个场景是帮人搭一套农业知识库，输入包括植保专家问答记录、病害图片库、农药使用说明、当地农技站的推广文档。用户最典型的问法就是“玉米大斑病和锈病怎么区分”“这个药打完多久能下雨不影响效果”这类非常具体的问题。

传统向量库在这个场景下有个尴尬点：农业术语很固定，但表达很灵活。用户不会说“玉米大斑病病原菌”，他会说“玉米叶子上长了长条形的斑是啥病”。“长条形”“斑”这些词在倒排索引里能直接命中病害图谱文档里的形态描述部分，配合重排模型，效果反而比向量召回更稳。我在旧向量库方案里遇到过同类问题：因为embedding把“锈病”和“叶锈病”的语义靠得很近，结果用户问叶锈病时，向量召回把两种病害的防治文档混在一起，回答时互相打架。改成Jev路线后，每个病害文档在标题和首段就写清了全名和别名，词面冲突被自然消除。

另一个热点问题是“农业知识库构建”时如何处理大量图片。我的做法在上一节已经讲了：病害图片通过OCR和人工补充说明文字后，变成“症状描述文字块”。比如一张玉米叶斑病图片的说明是“叶片出现梭形病斑，边缘有黄色晕圈，湿度大时背面有灰黑色霉层”，这段文字和植保手册里的形态描述互相印证，检索时两条证据链共同命中，回答质量非常高。

4.2 团队Wiki场景

第二个场景是给一个软件团队搭Wiki知识库。输入是几十个Obsidian仓库的Markdown文档、会议纪要、API变更记录、线上事故复盘。团队内部最常用的查询是“用户服务报错1002该怎么排查”“支付回调超时的排查流程”“上一个版本数据库迁移改了什么”。

这类问题有一个共同特点：关键词特别“硬”。报错码1002、回调超时、数据库迁移，都是代码世界里出现过的确切字面。倒排索引在这种场景下有天然优势——内部词表一致性极高，文档写的就是用户问的，用户问的就是代码报的。传统向量库反而容易出现“语义打架”：报错1002和报错10020在向量空间里可能有相似度，但实际是两回事，词面检索直接把1002精确命中到对应文档，完全不会串。

我还做了一组对比实验，把同一批500篇文档分别用传统向量管线和我自己的Jev路线搭建知识库，人工标注了20个真实查询问题，统计结果如下：

这组数据不能说明Jev全面优于向量库，因为我们测试的问题集合偏向“事实型问答”，本身就更适合词面检索。但至少说明，在知识库这个具体场景里，跳过向量数据库并不会带来质量损失，反而在维护成本和时效性上优势明显。

4.3 什么原因让这两个场景特别适配

回头总结，这两个场景都有一个共同特征：知识是“稀疏而精确”的。农业病害、团队Wiki里的操作手册和报错排查，都是低频变化、高确定性知识。它们不像大规模网页检索那样需要海量语义兜底，而是需要一份可靠的目录和一本能随时翻到的参考书。Jev路线正好提供了这两样东西。如果你的知识库内容也属于这种类型，大可不必一上来就背向量库的包袱。

5. Jev的边界：什么时候我仍然会用向量数据库

写这篇文章不是为了把向量数据库批倒。事实上，我在尝试Jev路线的过程中，也清晰感知到了它的边界。有几个场景，我明确定了一个原则：老老实实用向量库，不要硬上Jev。

5.1 海量弱关键词的语义检索

当文档规模到几十万篇，且内容高度依赖“语义相似”时，倒排索引的瓶颈会非常明显。典型如企业内部所有历史工单、客户来电转写的客服记录、会议录音的转写文稿。这些内容里几乎没有稳定的关键词：用户说“我登录的时候卡住了”，文档里写的是“认证超时导致登录缓慢”，两边没有共同词面。倒排索引再怎么优化也救不了这种场景，必须靠向量召回把语义拉近。我在做这类搜索场景时，毫不犹豫会选择向量库，这个没有悬念。

5.2 多模态检索需求

Jev路线本质上是文本检索。如果你需要“用一张图片找相似图片”“用一段音频片段找到对应的视频段落”，那所有文本化处理都失效了。多模态Embedding模型加上向量库是目前唯一实用路线。我之前提过的“图片翻译成文本”只是知识库问答的取巧解法，它不是通用多模态检索。真要做以图搜图、以音搜视频，请直接上向量数据库。

5.3 高并发生产环境与成熟生态

Jev路线在单机、中小规模场景下很顺手，但当你需要支撑在线业务的高并发查询，需要分片部署、权限隔离、审计日志、多副本容灾时，它就显得过于轻量了。成熟的向量数据库提供了完整的运维生态，这些能力不是几十行脚本能补上的。我的经验是：知识库规模在几千篇以内、团队或单机使用、更新频繁，Jev路线舒服得很；一旦知识库成为核心业务系统，需要稳定SLA和高并发，向量库是更稳妥的底座。

在项目选型时，我的决策逻辑很简单：先想清楚知识的形态，再谈技术架构。如果你的知识库是“确定知识+固定词面”，Jev这条路能省掉一整套基础设施；如果你的知识库是“模糊语义+海量规模”，向量库依然是绕不开的选项。最后分享一个小技巧：在Jev路线里，把高频问题和它们对应的文档标题摘出来，生成一个“路由白名单”放在检索层前面——用户问法稍有偏差时，白名单直接做一次别名映射，能把很多语义不匹配问题挡在源头之外。这个是我实测下来性价比最高的优化动作，成本几乎为零，但对回答质量的提升非常明显。