AI 搜索总漏掉型号和编号，混合搜索值得试吗？

型号搜索为什么还需要全文检索

向量检索根据语义相近程度找资料，适合“适合户外的轻便设备”这样的描述；短型号中的一位数字，却可能区分两个完全不同的产品。全文检索能补充词面匹配，混合搜索再汇总两边的候选。Google 的官方文章把这两类检索放进一次 SQL 调用，减少应用层拼接结果的代码。

全文检索也不等同于逐字符相等。带连字符的型号、版本号或中文混写，可能经过分词后失去原来的形式。需要严格查找 SKU 时，应保留独立的型号字段和相等条件，并检查实际生成的词元；不要把 RRF 融合当作精确查找规则。

启用预览函数前先核对环境

截至本次核对，官方步骤仍要求先启用 google_ml_integration 扩展，再设置 enable_preview_ai_functions。示例还要准备可用的向量列与全文索引。以下 SQL 只展示会话设置和已安装扩展的检查方式，后续建表及模型权限应按官方教程完成，不能直接套到普通 PostgreSQL 上。

官方示例用英文分词和 Gemini embedding。处理中文资料时，需要重新验证词元与查询写法；替换 embedding 模型时，也要让文档向量和查询向量保持兼容。不要直接沿用示例的列维度，却换成输出维度不同的模型。

SET google_ml_integration.enable_preview_ai_functions = true;

SELECT extname, extversion
FROM pg_extension
WHERE extname IN ('google_ml_integration', 'vector', 'alloydb_scann');

用排名明细查清候选从哪里来

接口中的 search_inputs 是 JSONB 数组，每个元素声明一种检索及其表名、主键和候选数量。RRF 根据候选在各路结果中的名次计算融合得分，而不是要求全文分数和向量距离先变成同一尺度。两路必须使用能对应同一文档的主键，重复资料也需要先处理。

把 include_json_output 设为 true，可查看各路排名、权重和执行时间等明细；官方说明这会影响查询性能。调试时用它解释一次漏召回或错误排序，稳定后再决定是否保留。weight 与每路 limit 都会改变候选，不能把融合后的 score 当作答案正确的概率。

保留失败查询再决定是否接入

用同一批资料分别跑全文、向量和混合查询，保留每条查询的预期文档及前几位结果。先检查精确型号有没有丢失，再看语义查询是否找回原来漏掉的资料。加入新版本或撤回资料后重跑这批查询，才能发现旧版本挤占结果等问题。这里给出的是评估设计，没有本站提升比例。

索引也要按实际需求选。GIN 是基线选择；RUM 适用 PostgreSQL 17 或更早版本，BM25 当前预览要求 AlloyDB 的 PostgreSQL 17 或 18。选择全文排名方式后，应核对对应的 ranking_function，另行记录模型调用费用与数据库资源消耗。单次 SQL 省掉了应用层编排，检索质量仍要由自己的查询样本确认。