文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇技术指南围绕 WaLiAPI 知识库流水线的承上启下环节展开——在完成知识库数据模型与文档解析后如何让分块后的文本真正活起来复用网关渠道调度能力完成向量化embedder、构建轻量级 HNSW 索引、编排 processor 处理流水线、打通 importer 多源导入并落地 FTS5 全文索引为下一节的混合检索与 RAG 问答铺平道路。读者读完将掌握一套零外部依赖的本地知识库索引实现思路以及向量索引 关键词全文索引混合检索的设计动机。一、本章诉求上一节第3-3节知识库数据模型与文档解析完成了知识库四张表kb_knowledge_bases、kb_documents、kb_chunks、kb_tasks的设计与文档解析文档被切成 chunk 存进了数据库。但此时 chunk 只是躺在库里的一堆文本还不能被语义检索。本节要让 chunk 具备被检索的能力核心诉求共六条实现 embedder 模块——复用 WaLiAPI 的渠道调度能力调用 Embeddings API实现轻量级 HNSW 索引——构建 / 搜索 / 持久化 / 增量更新实现 processor 流水线——文档处理的完整生命周期实现 importer 多源导入——Git / URL / 本地目录实现 FTS5 全文索引——为混合检索提供关键词搜索能力理解向量索引 FTS5 混合检索的设计动机这六条诉求共同勾勒出知识库流水线中段的完整轮廓向量化 → 索引构建 → 全文索引 → 多源导入全部服务于下一节第3-5节知识库检索与RAG问答的检索 → 生成输出端。二、向量化embedder.rs2.1 为什么复用渠道调度知识库需要调用 Embeddings API 将文本转换为向量这是向量化环节的必经之路。但 WaLiAPI 本身就是一个本地运行的 LLM API 网关已经具备完善的渠道调度Dispatcher、重试机制、多渠道 fallback 能力。为什么不直接用这些能力而要另起炉灶这是本章第一个关键设计决策。直接复用意味着不需要额外配置用户已有的渠道设置渠道、模型、密钥、负载策略可以原封不动地服务于知识库向量化。embedder 的调用流程如下┌─────────────────────────────────────────────────────┐ │ embedder 调用流程 │ │ │ │ texts → embed() → get_enabled_channels() │ │ → Dispatcher::select_channels(model) │ │ → try_embed_with_channel() → channel 1 │ │ → 失败 → try next channel → channel 2 │ │ → 成功 → VecVecf32 │ │ │ │ 不需要额外配置复用用户已有的渠道设置 │ └─────────────────────────────────────────────────────┘从流程可见embedder 的容错哲学是逐渠道重试、失败则 fallback只要用户配置的渠道中有一个可用向量化就能成功。这与 WaLiAPI 网关在处理 LLM 对话请求时多渠道 fallback的调度策略完全一致也让知识库的向量化能力天然继承了网关的渠道治理能力。在真实使用层面WaLiAPI - 端到端知识库RAG 明确指出下载后要配置 LLM 模型渠道确保渠道可用有可使用的向量模型推荐text-embedding-3-small。新建知识库时向量模型默认使用text-embedding-3-small并可在设置中绑定具体渠道——这正是 embedder 复用渠道调度能力的落地形态。2.2 embed 函数embedder 的核心入口是embed函数其签名与逻辑如下pub async fn embed( texts: [String], model: str, repo: Repository, ) - ResultVecVecf32, String { // 1. 获取启用的渠道 let channels repo.get_enabled_channels().await...; // 2. 选择支持该模型的渠道 let selected Dispatcher::select_channels(channels, model); let candidates if selected.is_empty() { channels.clone() } else { selected }; // 3. 逐个尝试 for channel in candidates { match try_embed_with_channel(texts, model, channel).await { Ok(embeddings) return Ok(embeddings), Err(e) continue, // fallback to next channel } } Err(All channels failed for embedding model.to_string()) }这段代码可以拆解为三个关键步骤步骤 1获取启用的渠道——从仓储层读取用户已启用enabled的渠道列表。这里的启用状态与 WaLiAPI 渠道管理模块中渠道的启停开关一致确保知识库只会使用用户主动放开的渠道。步骤 2按模型筛选候选渠道——Dispatcher::select_channels(channels, model)依据模型名筛选出支持该 Embeddings 模型的渠道。candidates的取值逻辑很巧妙如果筛选结果为空没有任何渠道声明支持该模型则退而求其次使用全部启用渠道避免因渠道元数据缺失导致能力空转否则使用筛选结果。步骤 3逐个渠道尝试——对每个候选渠道依次调用try_embed_with_channel成功即返回VecVecf32每个输入文本对应一个 f32 向量失败则continue跳到下一个渠道全部失败才返回错误All channels failed for embedding model。这一宁可遍历全部候选也不轻易失败的设计正是网关多渠道 fallback 思想在知识库场景的移植。从返回类型VecVecf32可以看出向量化输出的是稠密浮点向量数组这与 第3-3节 中kb_chunks表的embedding BLOB字段对应——向量在落库时通过 bincode 序列化为二进制存入 BLOB比 JSON 存储节省约 50% 空间。embedder 产出的向量正是后续 HNSW 索引构建与检索的燃料。三、轻量级 HNSW 索引3.1 什么是 HNSWHNSW全称Hierarchical Navigable Small World分层可导航小世界图是一种**近似最近邻搜索ANN**算法专门用来在海量向量中快速找到最相似的几个。通俗地说HNSW 是让向量搜索从挨个比对变成按图导航的技术——这也是 WaLiAPI 知识库索引方案选型的核心原因。在 WaLiAPI 中HNSW 的定位是轻量级不依赖外部向量数据库而是作为进程内索引与 SQLite 协同工作——向量本体以 BLOB 形式存在kb_chunks.embedding中HNSW 图结构负责提供近似最近邻的快速导航。3.2 构建 / 搜索 / 持久化 / 增量更新本章诉求要求 HNSW 索引具备四个完整能力构建build从知识库的全部 chunk 向量构建分层图结构将高维向量空间组织成可导航的小世界网络。搜索search给定查询向量在图中从高层粗粒度逐层下探到低层细粒度快速返回 top_k 个最相似向量的位置编号。持久化persist索引构建完成后序列化落盘避免每次启动都重新构建。在 WaLiAPI - 端到端知识库RAG 的使用说明中创建的知识库会通过 HNSW 构建索引前端【索引】页提供重新构建索引入口——这正是持久化与重建机制的交互体现。增量更新incremental update知识库新增文档、新增 chunk 后在已有索引基础上增量插入新向量而不是全量重建。这些能力在下一节的检索链路中会完整兑现从 第3-5节 的search函数可以看到检索时优先load_index(kb_id)加载 HNSW 索引并执行index.search(query_embedding, top_k)随后把索引返回的 position id 映射回 chunk_id 与 chunk 内容当索引不存在或维度不匹配时如换了 embedding 模型导致维度变化则自动降级为线性扫描——逐 chunk 从 BLOB 解码 embedding、计算余弦相似度、排序取 top_k。这一索引优先、扫描兜底的容错设计保证了知识库在任何情况下都能检索只是性能不同。四、processor 流水线文档处理的生命周期向量化与索引只是能力单元真正把它们串起来的是 processor 模块——文档处理的完整生命周期编排。结合第3-3节的数据库设计一条文档从进入到可检索要经历完整的状态流转pending → processing → ready / failedpending文档刚上传/导入等待处理processing正在执行解析、分块、向量化、索引构建ready向量与索引就绪可被检索failed处理过程出错error_message记录失败原因。kb_tasks表专门记录这种异步处理的进度——task_typeembed / index / import、progress、done_items / total_items共同支撑起异步任务追踪用户在前端看到的是处理中 X/Y底层就是 processor 在推进这些字段。这也解释了为什么第3-3节要在kb_documents.status上设计pending→processing→ready→failed状态机——文档处理是异步的需要状态追踪。processor 流水线的核心价值在于把解析、分块、向量化、索引更新这些步骤编排成一条可观测、可失败重试的管道为 importer 和上传两种入口提供统一的处理出口。五、importer 多源导入Git / URL / 本地目录知识库的价值不仅在于上传单个文件更在于把整个代码库喂进来。importer 模块支持三种来源Git 仓库直接拉取远程仓库或本地仓库路径将代码库转换为知识库URL抓取网页内容入库本地目录扫描本地目录下的全部文件入库。这一能力在 WaLiAPI - 端到端知识库RAG 的产品说明中对应来源上传功能——支持 Git 仓库、URL、本地目录这样可以非常方便的把代码库转换为知识库。配合第3-3节实现的 tree-sitter 符号感知代码解析code_parser.rs代码库导入后可以按函数、类、符号维度分块而不是简单按行切分——这是知识库能检索代码语义的关键前提。从kb_documents表结构可以印证导入路径的设计file_path字段专门记录本地文件路径如果是导入而content_hashSHA256用于防止重复导入同一文档——hash 相同则跳过避免多次导入同一 Git 仓库造成数据膨胀。六、FTS5 全文索引关键词检索的基石向量检索擅长语义相似但对精确关键词匹配函数名、报错码、专有名词力不从心。为此本章诉求要求实现 FTS5 全文索引——SQLite 内置的全文检索扩展为混合检索提供关键词搜索能力。FTS5 在 WaLiAPI 检索体系中的角色从 第3-5节 的检索能力层次图中可以看得非常清楚系统同时具备Vector Search语义相似度、cosine distance与FTS5 Search关键词匹配、rank scoring两条检索通道再通过Hybrid Search做加权融合最后叠加Symbol Filter基于symbol_kind、symbol_name的代码检索增强输出SearchResult[]chunk_id, content, score, meta。需要说明的是FTS5 对中文检索天然不友好按空格/标点分词这一点在后续的 第3-8节混合检索调优与检索可视化 中通过 CJK Bigram 中文分词得到补强——这是后话但说明全文索引这一层在设计之初就为混合检索预留了演进空间。七、向量索引 FTS5 混合检索的设计动机为什么要同时构建 HNSW 向量索引和 FTS5 全文索引而不是二选一核心动机是不同查询类型的最优检索方式完全不同。查询类型示例最优检索通道原因语义理解型如何处理并发安全向量语义相近的词线程安全锁机制都能召回精确匹配型tokio::spawn的返回值关键词FTS5需要精确命中函数名语义向量会漂移通用型Rust 错误处理最佳实践混合语义 关键词互补语义向量能把线程安全关联到锁机制这是 FTS5 做不到的而 FTS5 能精确命中tokio::spawn这种符号级关键词语义向量在此时反而会漂移。因此本节的索引构建是双轨制HNSW 管语义召回FTS5 管精确匹配二者在检索阶段做加权融合。从 第3-5节 与 第3-8节 可以看到融合权重默认写死为0.7 * vector 0.3 * fts5这一默认值在 3-8 节被参数化并交给用户调整——但混合检索这一设计动机正是本节构建 HNSW 与 FTS5 两份索引的根本原因没有双索引就没有混合检索没有混合检索就无法同时满足语义召回与精确匹配两类查询。八、承上启下为检索与 RAG 铺路至此本节完成了知识库流水线的中段闭环embedder复用网关渠道调度把 chunk 文本批量转为向量VecVecf32HNSW 索引提供轻量级近似最近邻搜索支持构建 / 搜索 / 持久化 / 增量更新processor 流水线编排文档处理生命周期kb_tasks追踪异步进度importer打通 Git / URL / 本地目录三种来源把代码库便捷地转换为知识库FTS5 全文索引补齐关键词检索能力双索引并存为混合检索奠定基础。下一节第3-5节知识库检索与RAG问答将把这些基础设施组合成输出端retriever模块执行 HNSW 向量搜索 FTS5 关键词搜索 加权融合 符号过滤rag模块完成多轮对话、Token 限制降级与来源引用最终通过 handlers / routes / Tauri commands 暴露给用户。如果你还想了解这套检索基础设施在前端如何被调优和可视化可继续阅读 第3-8节混合检索调优与检索可视化。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐《WaLiAPI 本地 LLM API 网关》第1-1节Tauri React Rust 初始化工程搭建实战《WaLiAPI 本地 LLM API 网关》第1 1节Tauri React Rust 初始化工程搭建实战 本教程来自 docs/md/projec文档教程后端dotnet/runtime PR Build Analysis 检查失败时如何分诊并上报 Known Issuedotnet/runtime PR Build Analysis 检查失败时如何分诊并上报 Known Issue 在 dotnet/runtime 仓库提交文档教程后端LLM Zoomcamp 向量搜索实战使用 minsearch 构建内存向量索引与语义检索LLM Zoomcamp 向量搜索实战使用 minsearch 构建内存向量索引与语义检索 在本篇技术指南中我们将围绕 LLM Zoomcamp2026示例工程教程人工智能大模型上一篇DashPlayer 长视频切分3 步把 12 小时课程存到本地断网也能学下一篇Windows 和 Office 激活教程3 步搞定创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
《WaLiAPI 本地 LLM API 网关》第3-4节实战：向量化、HNSW 索引与检索基础设施构建
文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇技术指南围绕 WaLiAPI 知识库流水线的承上启下环节展开——在完成知识库数据模型与文档解析后如何让分块后的文本真正活起来复用网关渠道调度能力完成向量化embedder、构建轻量级 HNSW 索引、编排 processor 处理流水线、打通 importer 多源导入并落地 FTS5 全文索引为下一节的混合检索与 RAG 问答铺平道路。读者读完将掌握一套零外部依赖的本地知识库索引实现思路以及向量索引 关键词全文索引混合检索的设计动机。一、本章诉求上一节第3-3节知识库数据模型与文档解析完成了知识库四张表kb_knowledge_bases、kb_documents、kb_chunks、kb_tasks的设计与文档解析文档被切成 chunk 存进了数据库。但此时 chunk 只是躺在库里的一堆文本还不能被语义检索。本节要让 chunk 具备被检索的能力核心诉求共六条实现 embedder 模块——复用 WaLiAPI 的渠道调度能力调用 Embeddings API实现轻量级 HNSW 索引——构建 / 搜索 / 持久化 / 增量更新实现 processor 流水线——文档处理的完整生命周期实现 importer 多源导入——Git / URL / 本地目录实现 FTS5 全文索引——为混合检索提供关键词搜索能力理解向量索引 FTS5 混合检索的设计动机这六条诉求共同勾勒出知识库流水线中段的完整轮廓向量化 → 索引构建 → 全文索引 → 多源导入全部服务于下一节第3-5节知识库检索与RAG问答的检索 → 生成输出端。二、向量化embedder.rs2.1 为什么复用渠道调度知识库需要调用 Embeddings API 将文本转换为向量这是向量化环节的必经之路。但 WaLiAPI 本身就是一个本地运行的 LLM API 网关已经具备完善的渠道调度Dispatcher、重试机制、多渠道 fallback 能力。为什么不直接用这些能力而要另起炉灶这是本章第一个关键设计决策。直接复用意味着不需要额外配置用户已有的渠道设置渠道、模型、密钥、负载策略可以原封不动地服务于知识库向量化。embedder 的调用流程如下┌─────────────────────────────────────────────────────┐ │ embedder 调用流程 │ │ │ │ texts → embed() → get_enabled_channels() │ │ → Dispatcher::select_channels(model) │ │ → try_embed_with_channel() → channel 1 │ │ → 失败 → try next channel → channel 2 │ │ → 成功 → VecVecf32 │ │ │ │ 不需要额外配置复用用户已有的渠道设置 │ └─────────────────────────────────────────────────────┘从流程可见embedder 的容错哲学是逐渠道重试、失败则 fallback只要用户配置的渠道中有一个可用向量化就能成功。这与 WaLiAPI 网关在处理 LLM 对话请求时多渠道 fallback的调度策略完全一致也让知识库的向量化能力天然继承了网关的渠道治理能力。在真实使用层面WaLiAPI - 端到端知识库RAG 明确指出下载后要配置 LLM 模型渠道确保渠道可用有可使用的向量模型推荐text-embedding-3-small。新建知识库时向量模型默认使用text-embedding-3-small并可在设置中绑定具体渠道——这正是 embedder 复用渠道调度能力的落地形态。2.2 embed 函数embedder 的核心入口是embed函数其签名与逻辑如下pub async fn embed( texts: [String], model: str, repo: Repository, ) - ResultVecVecf32, String { // 1. 获取启用的渠道 let channels repo.get_enabled_channels().await...; // 2. 选择支持该模型的渠道 let selected Dispatcher::select_channels(channels, model); let candidates if selected.is_empty() { channels.clone() } else { selected }; // 3. 逐个尝试 for channel in candidates { match try_embed_with_channel(texts, model, channel).await { Ok(embeddings) return Ok(embeddings), Err(e) continue, // fallback to next channel } } Err(All channels failed for embedding model.to_string()) }这段代码可以拆解为三个关键步骤步骤 1获取启用的渠道——从仓储层读取用户已启用enabled的渠道列表。这里的启用状态与 WaLiAPI 渠道管理模块中渠道的启停开关一致确保知识库只会使用用户主动放开的渠道。步骤 2按模型筛选候选渠道——Dispatcher::select_channels(channels, model)依据模型名筛选出支持该 Embeddings 模型的渠道。candidates的取值逻辑很巧妙如果筛选结果为空没有任何渠道声明支持该模型则退而求其次使用全部启用渠道避免因渠道元数据缺失导致能力空转否则使用筛选结果。步骤 3逐个渠道尝试——对每个候选渠道依次调用try_embed_with_channel成功即返回VecVecf32每个输入文本对应一个 f32 向量失败则continue跳到下一个渠道全部失败才返回错误All channels failed for embedding model。这一宁可遍历全部候选也不轻易失败的设计正是网关多渠道 fallback 思想在知识库场景的移植。从返回类型VecVecf32可以看出向量化输出的是稠密浮点向量数组这与 第3-3节 中kb_chunks表的embedding BLOB字段对应——向量在落库时通过 bincode 序列化为二进制存入 BLOB比 JSON 存储节省约 50% 空间。embedder 产出的向量正是后续 HNSW 索引构建与检索的燃料。三、轻量级 HNSW 索引3.1 什么是 HNSWHNSW全称Hierarchical Navigable Small World分层可导航小世界图是一种**近似最近邻搜索ANN**算法专门用来在海量向量中快速找到最相似的几个。通俗地说HNSW 是让向量搜索从挨个比对变成按图导航的技术——这也是 WaLiAPI 知识库索引方案选型的核心原因。在 WaLiAPI 中HNSW 的定位是轻量级不依赖外部向量数据库而是作为进程内索引与 SQLite 协同工作——向量本体以 BLOB 形式存在kb_chunks.embedding中HNSW 图结构负责提供近似最近邻的快速导航。3.2 构建 / 搜索 / 持久化 / 增量更新本章诉求要求 HNSW 索引具备四个完整能力构建build从知识库的全部 chunk 向量构建分层图结构将高维向量空间组织成可导航的小世界网络。搜索search给定查询向量在图中从高层粗粒度逐层下探到低层细粒度快速返回 top_k 个最相似向量的位置编号。持久化persist索引构建完成后序列化落盘避免每次启动都重新构建。在 WaLiAPI - 端到端知识库RAG 的使用说明中创建的知识库会通过 HNSW 构建索引前端【索引】页提供重新构建索引入口——这正是持久化与重建机制的交互体现。增量更新incremental update知识库新增文档、新增 chunk 后在已有索引基础上增量插入新向量而不是全量重建。这些能力在下一节的检索链路中会完整兑现从 第3-5节 的search函数可以看到检索时优先load_index(kb_id)加载 HNSW 索引并执行index.search(query_embedding, top_k)随后把索引返回的 position id 映射回 chunk_id 与 chunk 内容当索引不存在或维度不匹配时如换了 embedding 模型导致维度变化则自动降级为线性扫描——逐 chunk 从 BLOB 解码 embedding、计算余弦相似度、排序取 top_k。这一索引优先、扫描兜底的容错设计保证了知识库在任何情况下都能检索只是性能不同。四、processor 流水线文档处理的生命周期向量化与索引只是能力单元真正把它们串起来的是 processor 模块——文档处理的完整生命周期编排。结合第3-3节的数据库设计一条文档从进入到可检索要经历完整的状态流转pending → processing → ready / failedpending文档刚上传/导入等待处理processing正在执行解析、分块、向量化、索引构建ready向量与索引就绪可被检索failed处理过程出错error_message记录失败原因。kb_tasks表专门记录这种异步处理的进度——task_typeembed / index / import、progress、done_items / total_items共同支撑起异步任务追踪用户在前端看到的是处理中 X/Y底层就是 processor 在推进这些字段。这也解释了为什么第3-3节要在kb_documents.status上设计pending→processing→ready→failed状态机——文档处理是异步的需要状态追踪。processor 流水线的核心价值在于把解析、分块、向量化、索引更新这些步骤编排成一条可观测、可失败重试的管道为 importer 和上传两种入口提供统一的处理出口。五、importer 多源导入Git / URL / 本地目录知识库的价值不仅在于上传单个文件更在于把整个代码库喂进来。importer 模块支持三种来源Git 仓库直接拉取远程仓库或本地仓库路径将代码库转换为知识库URL抓取网页内容入库本地目录扫描本地目录下的全部文件入库。这一能力在 WaLiAPI - 端到端知识库RAG 的产品说明中对应来源上传功能——支持 Git 仓库、URL、本地目录这样可以非常方便的把代码库转换为知识库。配合第3-3节实现的 tree-sitter 符号感知代码解析code_parser.rs代码库导入后可以按函数、类、符号维度分块而不是简单按行切分——这是知识库能检索代码语义的关键前提。从kb_documents表结构可以印证导入路径的设计file_path字段专门记录本地文件路径如果是导入而content_hashSHA256用于防止重复导入同一文档——hash 相同则跳过避免多次导入同一 Git 仓库造成数据膨胀。六、FTS5 全文索引关键词检索的基石向量检索擅长语义相似但对精确关键词匹配函数名、报错码、专有名词力不从心。为此本章诉求要求实现 FTS5 全文索引——SQLite 内置的全文检索扩展为混合检索提供关键词搜索能力。FTS5 在 WaLiAPI 检索体系中的角色从 第3-5节 的检索能力层次图中可以看得非常清楚系统同时具备Vector Search语义相似度、cosine distance与FTS5 Search关键词匹配、rank scoring两条检索通道再通过Hybrid Search做加权融合最后叠加Symbol Filter基于symbol_kind、symbol_name的代码检索增强输出SearchResult[]chunk_id, content, score, meta。需要说明的是FTS5 对中文检索天然不友好按空格/标点分词这一点在后续的 第3-8节混合检索调优与检索可视化 中通过 CJK Bigram 中文分词得到补强——这是后话但说明全文索引这一层在设计之初就为混合检索预留了演进空间。七、向量索引 FTS5 混合检索的设计动机为什么要同时构建 HNSW 向量索引和 FTS5 全文索引而不是二选一核心动机是不同查询类型的最优检索方式完全不同。查询类型示例最优检索通道原因语义理解型如何处理并发安全向量语义相近的词线程安全锁机制都能召回精确匹配型tokio::spawn的返回值关键词FTS5需要精确命中函数名语义向量会漂移通用型Rust 错误处理最佳实践混合语义 关键词互补语义向量能把线程安全关联到锁机制这是 FTS5 做不到的而 FTS5 能精确命中tokio::spawn这种符号级关键词语义向量在此时反而会漂移。因此本节的索引构建是双轨制HNSW 管语义召回FTS5 管精确匹配二者在检索阶段做加权融合。从 第3-5节 与 第3-8节 可以看到融合权重默认写死为0.7 * vector 0.3 * fts5这一默认值在 3-8 节被参数化并交给用户调整——但混合检索这一设计动机正是本节构建 HNSW 与 FTS5 两份索引的根本原因没有双索引就没有混合检索没有混合检索就无法同时满足语义召回与精确匹配两类查询。八、承上启下为检索与 RAG 铺路至此本节完成了知识库流水线的中段闭环embedder复用网关渠道调度把 chunk 文本批量转为向量VecVecf32HNSW 索引提供轻量级近似最近邻搜索支持构建 / 搜索 / 持久化 / 增量更新processor 流水线编排文档处理生命周期kb_tasks追踪异步进度importer打通 Git / URL / 本地目录三种来源把代码库便捷地转换为知识库FTS5 全文索引补齐关键词检索能力双索引并存为混合检索奠定基础。下一节第3-5节知识库检索与RAG问答将把这些基础设施组合成输出端retriever模块执行 HNSW 向量搜索 FTS5 关键词搜索 加权融合 符号过滤rag模块完成多轮对话、Token 限制降级与来源引用最终通过 handlers / routes / Tauri commands 暴露给用户。如果你还想了解这套检索基础设施在前端如何被调优和可视化可继续阅读 第3-8节混合检索调优与检索可视化。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐《WaLiAPI 本地 LLM API 网关》第1-1节Tauri React Rust 初始化工程搭建实战《WaLiAPI 本地 LLM API 网关》第1 1节Tauri React Rust 初始化工程搭建实战 本教程来自 docs/md/projec文档教程后端dotnet/runtime PR Build Analysis 检查失败时如何分诊并上报 Known Issuedotnet/runtime PR Build Analysis 检查失败时如何分诊并上报 Known Issue 在 dotnet/runtime 仓库提交文档教程后端LLM Zoomcamp 向量搜索实战使用 minsearch 构建内存向量索引与语义检索LLM Zoomcamp 向量搜索实战使用 minsearch 构建内存向量索引与语义检索 在本篇技术指南中我们将围绕 LLM Zoomcamp2026示例工程教程人工智能大模型上一篇DashPlayer 长视频切分3 步把 12 小时课程存到本地断网也能学下一篇Windows 和 Office 激活教程3 步搞定创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
