为什么用 PostgreSQL FTS + pgvector？

返回 工程项目复盘 目录

标准回答

我选择 PostgreSQL FTS 加 pgvector，是希望先把记忆内容、来源、有效状态、权限元数据和检索放在一套可管理的数据体系里。EachOf 的重点不仅是找相似文本，还包括纠错、撤销和来源校验，所以这些状态与检索的关联很重要。

检索上，关键词与向量解决的问题不同。比如错误码、接口名、精确术语更适合词法匹配；“设备无法加入网络”和“配网失败”这种表达变化，更适合语义匹配。我结合两类信息，再考虑时间和可信度，使排序不只由文本相似度决定。最终结果仍要满足权限和有效性约束。

把这些能力放在 PostgreSQL 里，可以减少当前项目需要维护的独立服务，也方便管理关联数据。但同库不等于所有操作天然处于同一个事务，更不等于检索质量天然最好。中文分词、过滤后的候选数量、向量检索延迟，都需要单独验证。

如果规模或检索需求发生变化，例如需要更复杂的搜索分析、更高吞吐，我会重新评估专用搜索服务。我的搜索产品本身就使用 Elasticsearch，所以这个选择是围绕 EachOf 当前的数据和治理需求，而不是否定其他检索系统。

关键机制

• 全文和向量分数尺度不同，需要明确融合方法；材料没有写 RRF 或具体权重，不能把通用做法当成实际实现。
• 中文、编号和代码词的分词与索引要专门验证；PostgreSQL 默认配置不代表中文检索效果已经合格。
• 规模、写入频率、过滤条件和复杂搜索需求增大后，仍要用压测评估是否拆分专用索引服务。

通俗例子

“E1703”适合精确词法匹配，“设备无法加入网络”可以通过语义找到“配网失败”。两路召回后都要检查权限与有效状态。

追问与回答

为什么不用 Elasticsearch？

我在搜索产品中用过 Elasticsearch，它适合以全文搜索为中心的场景。EachOf 则还需要频繁关联来源版本、依赖、权限和有效状态，先集中在 PostgreSQL 里可以减少跨系统同步的复杂度。代价是某些搜索能力和规模上限需要自己验证。如果之后搜索成为主要瓶颈，我会考虑拆分索引服务，同时保留 Core 的权威状态边界。

时间和可信度怎样加入排序？

它们在我这里是相关性之外的排序信号：较新的有效事实可能比过时内容更值得使用，依据更可靠的内容也不应该轻易被低质量候选压过。但时间衰减不能一刀切，长期成立的基础知识不能只因为旧就变成无用信息。具体融合需要控制不同分数的尺度，并用固定样本对比；项目中的准确公式和权重应以实现为准，我不会临时给出一个并未使用的加权公式。

易混淆点

同库不自动意味着所有操作处于同一个事务，也不自动带来最佳召回率。应说清实际查询与一致性边界。

参考资料

• 官方参考

内容来源

• Android 技术札记 · 原条目 eachof-postgres