AI search keeps missing model numbers and IDs. Is hybrid search worth trying?

Why model-number searches still need full-text retrieval

Vector search retrieves semantically similar material and suits descriptions such as “lightweight equipment for outdoor use.” A single digit in a short model number, however, may identify a different product. Full-text search adds lexical matches, and hybrid search combines the candidates. Google’s article puts these components into one SQL call, reducing the application code needed to merge results.

Full-text retrieval is not character-for-character equality. Tokenization can change hyphenated model numbers, version strings or mixed Chinese text. For an exact SKU lookup, retain a separate identifier field and equality condition, and inspect the actual tokens. RRF does not replace exact-match rules.

Check the environment before enabling preview functions

At the time of review, the official steps still require the google_ml_integration extension and enable_preview_ai_functions. The example also needs a vector column and a full-text index. The SQL below shows the session setting and an extension check. Follow the official tutorial for tables and model permissions; these steps cannot simply be applied to ordinary PostgreSQL.

The official example uses English tokenization and Gemini embeddings. Chinese documents need separate checks of tokens and query wording. If the embedding model changes, document and query vectors must remain compatible. Do not retain the example’s column dimensions while switching to a model with a different output dimension.

SET google_ml_integration.enable_preview_ai_functions = true;

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

Use ranking details to trace each candidate

The search_inputs parameter is a JSONB array. Each element specifies a retrieval component, including its table, key and candidate limit. RRF calculates a fused score from positions in the ranked lists instead of requiring full-text scores and vector distances to share a scale. The components need keys referring to the same documents, and duplicate records require attention.

Setting include_json_output to true exposes component ranks, weights and execution times. The documentation notes a performance impact. Use it to diagnose a missed document or poor ordering, then decide whether to retain it. Component weights and limits affect candidates, and the fused score is not the probability that an answer is correct.

Keep failed queries before deciding to adopt

Run full-text, vector and hybrid queries against the same documents, recording the expected document and the leading results for each query. Check exact identifiers first, then whether semantic queries recover previously missed material. Repeat after adding versions or withdrawing records to catch obsolete results. This is an evaluation design; no HotAI improvement percentage is claimed.

Index choice depends on the workload. GIN provides a baseline; RUM supports PostgreSQL 17 or earlier, while the BM25 preview currently requires AlloyDB PostgreSQL 17 or 18. Match ranking_function to the chosen full-text approach, and record model charges and database resource use separately. A single SQL call simplifies orchestration, while retrieval quality still needs validation on your own queries.