Vos utilisateurs cherchent, mais trouvent-ils vraiment ?
Dans une application métier, la barre de recherche est souvent le point d'entrée le plus critique. Pourtant, combien d'équipes se retrouvent avec des utilisateurs frustrés qui "savent que l'information existe" mais ne la trouvent pas ? La recherche hybride — combinant sémantique et mots-clés — est la réponse technique à ce problème. Et désormais, elle s'intègre directement dans PostgreSQL.
Le problème : deux types de recherche, deux angles morts
Pour comprendre l'enjeu, il faut saisir la complémentarité de deux approches.
La recherche dense (vectorielle / sémantique)
Lorsqu'un utilisateur tape "comment récupérer mon accès", une recherche sémantique retrouvera l'article "Réinitialisation de mot de passe" — même sans aucun mot en commun. Les embeddings (vecteurs denses) capturent le sens, pas les mots. C'est puissant pour les requêtes conceptuelles, les reformulations, le langage naturel.
Mais cette approche a un angle mort : les termes techniques précis. Chercher wal_level ou pgvector dans une base de documentation ? Le moteur sémantique peut passer à côté, car ces chaînes n'ont pas de "sens" dans l'espace vectoriel.
La recherche BM25 (sparse vectors / mots-clés)
BM25 est l'algorithme qui propulse les moteurs de recherche classiques depuis des décennies. Il pondère les termes rares, tient compte de la fréquence, et excelle sur les requêtes exactes : noms de fonctions, identifiants, acronymes métier. C'est précisément là où la recherche dense échoue.
Mais BM25 seul rate les synonymes, les paraphrases, et toute recherche en langage naturel.
La solution : combiner les deux. C'est ce qu'on appelle la recherche hybride.
Ce que change l'extension pgedge-vectorizer
Jusqu'ici, dans une architecture RAG classique sur PostgreSQL, le BM25 était souvent géré côté applicatif — dans votre code PHP/Symfony, via une bibliothèque externe ou un service tiers (Elasticsearch, Typesense, etc.). Cela signifiait de la complexité d'infrastructure, de la synchronisation de données, et une surface de maintenance supplémentaire.
L'article source d'Ahsan Hadi (pgEdge, juillet 2026) annonce un changement significatif : l'extension pgedge-vectorizer intègre désormais la génération de vecteurs sparse BM25 directement dans PostgreSQL, aux côtés des embeddings denses. La fusion des résultats se fait via le Reciprocal Rank Fusion (RRF), également dans le moteur.
Reciprocal Rank Fusion : la clé de voûte
RRF est l'algorithme qui réconcilie les deux classements. Pour chaque document, il calcule un score combiné à partir de sa position dans le classement dense et dans le classement BM25 :
score_RRF = 1/(k + rang_dense) + 1/(k + rang_BM25)
Avec k typiquement fixé à 60. Ce score favorise les documents qui apparaissent en bonne position dans les deux classements — ce sont les résultats les plus fiables. Un document excellent en sémantique mais absent du top BM25 est relativisé, et vice versa.
Résultat : une liste de résultats hybride, robuste, sans avoir à orchestrer deux systèmes distincts depuis votre application.
Concrètement, qu'est-ce que ça change pour vos applications Symfony/PHP ?
Si vous développez des outils métiers avec PostgreSQL — ERP, GED, CRM, bases de connaissances internes, portails documentaires — voici les implications pratiques :
1. Moins d'infrastructure, plus de cohérence
Pas besoin d'un service Elasticsearch ou Typesense dédié pour gérer le BM25. PostgreSQL devient votre source unique de vérité pour la recherche, dense et sparse. Votre stack Symfony se simplifie : une seule connexion, un seul modèle de données, un seul point de requête.
2. Des requêtes Doctrine plus simples
La logique de fusion étant gérée dans l'extension PostgreSQL, votre couche Repository n'a pas à orchestrer deux appels distincts et à fusionner les résultats en PHP. Une requête SQL (ou une fonction stockée) retourne directement les résultats hybrides classés.
3. Une pertinence accrue pour vos utilisateurs métier
Un commercial qui cherche "contrat Dupont 2024" dans votre CRM bénéficiera à la fois de la correspondance exacte sur le nom (Dupont) et du sens contextuel (contrat ≈ accord, convention, engagement). Les deux angles sont couverts dans une seule requête.
4. Cas d'usage particulièrement adaptés
- Documentation technique interne : l'utilisateur cherche un nom de fonction exact ou décrit son problème en français
- Base de connaissances support : tickets, procédures, FAQs — mélange de jargon technique et de langage naturel
- Catalogue produit ou référentiel métier : codes SKU précis et descriptions sémantiques
- Moteur RAG d'entreprise : enrichir votre LLM avec le contexte le plus pertinent possible
Points d'attention pour une intégration réussie
Cette approche reste jeune et quelques points méritent attention avant de la mettre en production :
- Dépendance à l'extension :
pgedge-vectorizer est spécifique à l'écosystème pgEdge. Si vous êtes sur un PostgreSQL managé (RDS, Supabase, Neon), vérifiez la disponibilité de l'extension.
- Modèle d'embedding : l'article utilise Ollama avec
nomic-embed-text. La qualité de vos embeddings denses conditionne directement la pertinence sémantique.
- Tuning du paramètre
k dans RRF : la valeur par défaut (60) convient dans la plupart des cas, mais peut nécessiter un ajustement selon votre corpus et vos usages.
- Indexation et performance : combiner index vectoriels (HNSW/IVFFlat via pgvector) et index full-text sur des volumes importants demande une analyse de votre stratégie d'indexation.
Conclusion
La recherche hybride dans PostgreSQL représente une avancée concrète pour les développeurs qui construisent des outils métiers avec un stack PHP/Symfony/PostgreSQL. En intégrant BM25 et RRF directement dans le moteur, pgedge-vectorizer supprime une couche de complexité souvent sous-estimée.
Le principe reste valable quelle que soit votre implémentation : si votre application expose une barre de recherche, la combiner sémantique et mots-clés n'est plus un luxe, c'est une exigence de pertinence. Vos utilisateurs ne font pas la distinction entre "chercher par sens" et "chercher par mot" — ils veulent juste trouver.
Source originale : Hybrid Search in PostgreSQL: BM25, Sparse Vectors, and Reciprocal Rank Fusion par Ahsan Hadi (pgEdge, juillet 2026)
