向量、关键词与混合检索

核心答案：向量检索偏向语义相近，关键词检索偏向词项匹配，混合检索把不同召回信号组合起来。 它们都需要元数据过滤；任何一种检索都不等同于事实验证。

教材资料的不同需求

查询	向量的机会与风险	关键词的机会与风险
“怎样礼貌地向老师打招呼”	可匹配不同措辞；也可能召回泛泛礼仪	同义表述可能漏召回
指定教材编号 HL-101	编号语义弱，可能相似但错误	精确编号很适合字段匹配
地区为 SA、等级为 A1	不应仅靠语义理解过滤	应使用结构化条件
阿语译名的特定拼写	近义不等于术语正确	适合规范化后的精确校验

PostgreSQL 全文检索涉及解析、规范化、索引与排名，官方介绍说明这些组件。中文等语言还要验证分词配置；简单 ILIKE 子串查询不能宣称等同于完整全文检索或 BM25。

最小例子：按排名融合

两组分数的量纲通常不同，直接相加可能失衡。RRF 使用名次融合；下面是可运行的最小实现：

lists = [["a", "b", "c"], ["b", "d", "a"]]
scores = {}
for ranking in lists:
    for rank, item in enumerate(ranking, start=1):
        scores[item] = scores.get(item, 0) + 1 / (60 + rank)
result = sorted(scores, key=scores.get, reverse=True)
assert result[0] == "b"
print(result)

这个人工排序样例只证明融合公式的行为。常数、召回数量和去重粒度仍需在固定评测集选择；不能据此声称混合方案效果更好。Elastic 的 RRF 文档提供实现语境。

本项目的选择

核心要求是 pgvector 真实入库与带条件的检索。先建立精确向量搜索基线，确认等级、语言、地区与资料版本过滤，再讨论混合方案。结构化规则不靠“希望被召回”执行：它们必须显式加载。

扩展混合检索时，两路都必须施加同样的数据边界，融合后保留文档 ID、片段 ID 与版本。否则关键词路径可能把向量路径已过滤的资料重新带入。重复片段若只按文本去重，还可能丢掉不同资料的来源关系。完整数据流见系统架构。

自测与排障

把同一个查询分别改写成自然语言、精确编号和带地区限制的查询，预先标注应返回的资料。验收应检查 Recall@k、地区错误率与来源完整率，而不只看相似度最高值。

出现空结果时依次检查资料是否已导入、元数据值是否一致、版本是否启用、阈值是否过高、近似索引与过滤组合是否漏召回。不能自动放宽地区条件以“保证有结果”。

官方资料与版本边界

• PostgreSQL Full Text Search：词项处理与全文检索。
• pgvector：向量运算与过滤。
• Elastic RRF：排名融合。

核验日期：2026-11-03。混合检索属于比较与扩展知识，不代表已部署 Elasticsearch。示例公式独立于某厂商 REST 字段；项目能力以实际接口和验收报告为准。