RAG 进阶的核心不是把更多技术名词放进架构图，而是验证向量存储、入库与检索在真实约束下是否协同工作。本篇用虚构的展览设备文档库，比较已有 PostgreSQL 环境与独立向量服务的实现路径，设计可回放入库流程，再测试关键词与语义融合。示例不连接生产系统，也不声称已完成性能测试。
先把负载和验收条件写成一页
列明文档格式、数量与增长、向量维度、更新和删除频率、并发查询、权限过滤及恢复目标。查询集要有设备编号、同义描述、多语言、旧版本冲突和无答案问题。目标不是一个通用“准确率”，而是在指定范围下的检索质量、尾延迟、成本与维护能力。写清谁负责运行、备份、模型版本与故障处理。
不要等到百万级才做选型，也不要因为资料少就新增一套分布式服务。已有关系数据库、团队经验、数据驻留与访问控制可能比单次查询最快更重要。把必须条件与可取舍条件分开，来源权利和权限隔离不应仅作为加分项。任何候选先在隔离的脱敏夹具上验证，不直接迁移现有知识库。
场景一：用同一工作负载比较向量库
先建可解释的基线，在可行的小样本上用精确最近邻结果作为近似索引召回比较的参照；它与人工标注的语义相关性不是同一指标。保持数据、嵌入、距离度量、过滤条件与机器资源可比，再测索引构建时间、写入、查询和更新后的表现。不要把不同维度、不同硬件的宣传数直接排名。
已有 PostgreSQL 的团队可评估 pgvector 扩展，以复用现有数据管理与运行经验；需要独立检索服务的团队可把 Qdrant 等候选纳入同一测试。GitHub 上已有这些成熟项目，参考它们是复用既有向量检索能力，而不是另造存储引擎。实际版本、许可、备份恢复、运维成本及所需检索功能须逐项核查，没有通用于所有团队的赢家。
索引选择有不同时间、内存与召回权衡。提高某个搜索参数可能改善近似召回，也可能增加延迟；量化与磁盘存储可能减少某些资源开销，但必须在本数据上检验质量。不要将 HNSW、IVF 或特定产品的索引名称当作可跨数据库直接替换的配置。先查所用版本文档，记录参数与实际测量，避免拿另一产品的概念照搬。
过滤尤其要测。无过滤查询很快，不代表指定团队、设备版本与生效日期后仍能返回足够结果。测试高选择性过滤、空结果、多个租户和删除后查询。检索端过滤与应用端鉴权各有责任，用户不能通过修改 query 参数取得其他团队材料。产物为选型矩阵、测试配置、结果与不支持项，不是只有一句“推荐某库”。
场景二：把向量化入库做成可恢复任务
建立 document_id、revision、content_hash、chunk_id 与访问标签的关系。Word、Markdown、PDF 和 TXT 使用相应解析流程，先抽查表格、标题、单位与扫描文本，再向量化。解析失败和低质量文档进入隔离队列；文件被接收不等于内容已可检索。保留解析器与分块版本，方便解释同一文档为什么变成不同块。
嵌入记录包含模型标识、版本、维度、预处理与生成时间。查询向量必须与索引兼容；模型迁移时建立新版本索引并比较，不混入旧空间。限制批次与重试，区分服务限流、输入异常、部分成功和永久失败，避免把失败项悄悄填成零向量。只向获准的嵌入服务发送允许内容，费用与保留政策另行核对。
任务状态至少区分已发现、已解析、已分块、已向量化、已写入与可查询。用稳定标识实现重复导入的幂等结果；一次重试不应生成同一版本的多份候选。先写测试索引，核对文档数、块数、失败数和来源定位，再切换读取。索引重建期间保留回退路径，不在未验证的新索引上直接接管全部查询。
增量更新要处理新增、修改和删除。文档修改后，旧块何时失效、新块何时可见须明确，查询不能随机混合两版。删除需跟踪存储、缓存与派生输出，备份和日志的保留政策另计。权限标签更新也属于索引一致性问题，不能只在网页列表上隐藏文件就认为检索已经撤权。
实操：一份附录改版后的核对
假设设备文档 D-14 从 v1 更新到 v2，原附录三块变为四块。先对新版本解析并生成新 chunk_id，检查引用页码是否准确，再验证旧块是否从有效查询范围移除。重跑原版本问题、最新版本问题与无权用户问题，确认回答注明适用版本。示例描述的是验收设计，不是已运行结果。
接着模拟嵌入服务在第二批次失败。重试后应只补失败内容，成功块不重复；任务日志能给出每项状态与错误原因。切换失败时恢复原读取配置，并说明旧索引适用的时间范围。不要为了显示“入库完成”把失败计数清零，或把尚未可查询的向量写入当成最终成功。
给 Agent 的任务可写为：“只使用 approved-equipment-manifest 与指定脱敏文件。输出入库状态机、版本映射和增量核对脚本方案。对解析、嵌入和写入分别报告失败，不覆盖生产索引，不上传未授权内容。返回待执行步骤与验收条件，不声称任务已运行。”
场景三：先看两路候选，再设计融合
设备编号 E-410 与其同义功能描述需要不同查询测试。词项检索可匹配明确符号，向量检索可找语义接近内容，两路都需相同的版本与权限范围。先分别保留候选及排名，判断它们各自漏什么，再比较融合，不只看最终答案似乎更流畅。
RRF 按多个列表中的排名组合候选，不是把 BM25 分数与余弦值直接相加；不同检索分数尺度未必可比。Qdrant 的混合查询文档展示了多路预取再融合的实现方式，采用时仍需核对具体版本与接口。检索路径可能返回同一文档的多个块，去重或分组规则应明确，避免某一文档占满上下文。
融合后可增加重排序，但需要新的延迟与费用预算。Cross-Encoder 一类重排模型判断查询与候选配对相关性，不负责补回从未召回的资料，也不证明来源正确。上下文压缩需保留否定、单位、型号和生效条件。只改一个主要因素，在同一查询集上比较关键词、向量、融合与重排的差异，并记录每一阶段候选。
检索质量与回答支持分开评分。用人工判断的相关来源检查前 k 个候选，同时记录无答案、过期、跨租户和语言差异；标注不完整时不要宣称完整 recall。最终回答还要检查证据、引用与适用范围。多路检索提高候选数量不等于必然提升质量，要计入错误召回、资源消耗与更新复杂度。
性能结果整理与匹配 Skill
基准日志可用 run_id、query_id、config_id、latency_ms、error_type 与相关性标注组织。对明确授权的本地 CSV、TSV 或 JSON，可用 Exploratory Data Analysis 检查缺失记录、异常耗时和分布。限定数据根目录与输出目录，准备 Python 和格式依赖，只输出合适的汇总。它不部署向量库、不生成嵌入，也不自动判断检索相关性；测量口径和语义标注仍由评估流程负责。
报告并发、冷热缓存、数据规模、资源配置和错误率，给中位数与尾部表现，超时不能从结果里悄悄删除。快但漏掉权限条件的配置不能算通过。反复挑最好的单次结果会误导选型，保留重复运行和失败情况。交付配置、原始受控日志、汇总与解释，明确实际跑过和仍待执行的部分。
FAQ 与维护
小型库是不是一定用某个轻量产品？先看现有系统与必要要求，不按一个固定条数阈值决策。混合检索必然更好吗？不一定，靠查询集与成本验证。入库脚本完成就能上线吗？还要核对可查询、更新删除、权限与故障恢复。框架与 Skill 什么关系？框架提供组件，技能提供方法或工作流，都不免除版本和行为验证。
原文六个名称未取得本次可核验的 SkillPI 对应记录，因此不制作猜测链接。本篇仅把已核验 EDA 放在基准日志质量整理这一步。目录新增候选后用同一设备文档夹具测试来源、许可、依赖和输出，再关联到具体阶段。嵌入模型、存储或检索参数变化都应触发回归，保留旧配置和迁移说明，让进阶能力建立在可重现证据上。