Stratégie de recherche vectorielle filtrée : appliquer des filtres aux requêtes vectorielles dans Azure AI Search
La recherche vectorielle filtrée dans Azure AI Search associe similarité vectorielle et filtrage des métadonnées. Le pré-filtre réduit le jeu de candidats avant le calcul de similarité, ce qui peut abaisser la latence mais fait courir un risque de perte de rappel. Le post-filtre préserve le rappel mais peut renvoyer moins de résultats. Tester les deux modes est essentiel pour trouver le bon compromis selon vos données.
Dans ce guide
La réponse courte
La recherche vectorielle filtrée dans Azure AI Search permet d'attacher une expression de filtre à une requête vectorielle. Le filtre vise des champs de métadonnées non vectoriels, jamais le champ vectoriel lui-même. Le moteur peut appliquer le filtre avant ou après le calcul de similarité vectorielle. Le pré-filtre réduit l'ensemble des candidats avant la recherche des plus proches voisins, ce qui peut faire tomber silencieusement des documents pertinents qui ne satisfont pas la condition de métadonnées, mais peut réduire la latence pour des filtres sélectifs. Le post-filtre calcule la similarité sur l'ensemble de l'index puis supprime les résultats non conformes, pouvant renvoyer moins de k documents. Le choix relève d'une décision de stratégie : le post-filtre est souvent recommandé avec le semantic ranker, qui a besoin d'un plus grand pool de candidats, mais la documentation conseille de tester les deux modes sur vos données. Pour l'implémenter, vous devez concevoir des champs texte ou numériques filtrables à côté de vos champs vectoriels, puis définir le paramètre vectorFilterMode dans la requête.
Ce que signifie la recherche vectorielle filtrée dans Azure AI Search
La recherche vectorielle filtrée dans Azure AI Search consiste à attacher une expression de filtre à une requête qui contient également une requête vectorielle. Le filtre s'applique aux champs texte ou numériques du schéma d'index, jamais au champ vectoriel lui-même. Cela vous permet d'inclure ou d'exclure des documents selon des critères de métadonnées tout en effectuant une recherche de similarité par plus proches voisins sur les embeddings. Le moteur peut traiter le filtre soit avant, soit après l'exécution de la requête vectorielle, ce qui change les documents qui entrent dans le pipeline de calcul de similarité.
Conseil pratique
Le pré-filtre réduit le jeu de candidats avant le calcul kNN, ce qui peut abaisser la latence lorsque le filtre est très sélectif. Toutefois, comme il peut abandonner silencieusement des documents conceptuellement pertinents, la documentation conseille de mesurer les performances des modes pré-filtre et post-filtre avec des requêtes représentatives afin de confirmer le compromis pour votre distribution de données spécifique.
Pré-filtre contre post-filtre : la décision centrale
Le moteur de recherche peut appliquer le filtre avant ou après l'exécution de la requête vectorielle. Il s'agit d'une décision de stratégie, et non d'un choix de syntaxe, et elle affecte directement la taille du pool de candidats. Avec le pré-filtre, le filtre s'exécute en premier et réduit l'ensemble des documents que la recherche vectorielle devra noter. Avec le post-filtre, la recherche vectorielle s'exécute sur l'intégralité de l'index, puis le filtre supprime ensuite les résultats non conformes. Ce choix influence le rappel, la précision et le nombre de résultats renvoyés. La documentation ne prescrit pas un mode universellement optimal ; elle conseille de tester les deux afin de déterminer celui qui convient à votre scénario.
Concevoir des champs de métadonnées filtrables
Les champs vectoriels n'étant pas filtrables, tout attribut que vous souhaitez contraindre au moment de la requête doit être stocké dans un champ non vectoriel distinct, marqué comme filtrable dans le schéma d'index. Par exemple, si vous voulez filtrer par catégorie, localisation ou date, vous devez créer des champs texte ou numériques pour ces propriétés et définir leur attribut filterable à true. L'expression de filtre dans la requête référence ces champs, pas le champ vectoriel. Sans eux, la recherche vectorielle filtrée est impossible. Cette étape de conception du schéma est un prérequis qui doit être réalisé avant que toute requête ne puisse utiliser un filtre conjointement à une recherche vectorielle.
Le paramètre vectorFilterMode et une requête concrète
La documentation de la recherche hybride fournit une requête concrète qui illustre la recherche vectorielle filtrée en pratique. La requête inclut une expression de filtre utilisant geo.distance pour trouver les hôtels situés à moins de 300 kilomètres d'un point, et définit vectorFilterMode à postFilter. La requête contient aussi une recherche plein texte, deux requêtes vectorielles visant des champs vectoriels différents, des facettes et un classement sémantique. Le filtre est geo.distance(Location, geography'POINT(-77.03241 38.90166)') le 300, et vectorFilterMode vaut postFilter. Cela signifie que le moteur trouve d'abord les 50 plus proches voisins par similarité d'embedding sur l'ensemble des hôtels, puis élimine ceux qui se trouvent hors du rayon. Le jeu de résultats peut contenir moins de 50 documents. Les requêtes vectorielles spécifient k=50 et un oversampling destiné à améliorer le rappel. L'exemple montre comment le filtre, les requêtes vectorielles et les autres fonctionnalités coexistent dans une seule requête.
POST https://{{searchServiceName}}.search.windows.net/indexes/hotels-vector-quickstart/docs/search?api-version=2026-04-01
content-type: application/JSON
{
"count": true,
"search": "historic hotel walk to restaurants and shopping",
"select": "HotelId, HotelName, Category, Description, Address/City, Address/StateProvince",
"filter": "geo.distance(Location, geography'POINT(-77.03241 38.90166)') le 300",
"vectorFilterMode": "postFilter",
"facets": ["Address/StateProvince"],
"vectorQueries": [
{
"kind": "vector",
"vector": [<array of embeddings>],
"k": 50,
"fields": "DescriptionVector",
"exhaustive": true,
"oversampling": 20
},
{
"kind": "vector",
"vector": [<array of embeddings>],
"k": 50,
"fields": "Description_frVector",
"exhaustive": false,
"oversampling": 10
}
],
"skip": 0,
"top": 10,
"queryType": "semantic",
"queryLanguage": "en-us",
"semanticConfiguration": "my-semantic-config"
}Interaction avec le semantic ranker
Lorsque vous utilisez le semantic ranker, la documentation suggère de partir par le post-filtre. La raison est que le semantic ranker a besoin d'un pool de candidats plus large pour lire et réordonner. Le pré-filtre pourrait réduire ce pool trop fortement, limitant l'efficacité du ranker. Il ne s'agit toutefois pas d'une règle stricte ; la source recommande explicitement de tester afin de confirmer quel comportement convient le mieux à vos requêtes. Le semantic ranker opère sur les résultats fusionnés de la recherche plein texte et de la recherche vectorielle, et le filtre peut être appliqué avant ou après cette fusion, ce qui modifie l'entrée fournie au ranker. Si vous définissez k à 50 pour les requêtes vectorielles lors de l'utilisation du semantic ranker, vous maximisez les entrées disponibles pour le re-classement.
Compromis : perte de rappel avec le pré-filtre
Le pré-filtre réduit l'ensemble des candidats avant que la similarité vectorielle ne soit calculée. Cela peut abandonner silencieusement des documents conceptuellement pertinents qui ne satisfont pas la condition de métadonnées, même s'ils sont très similaires au vecteur de la requête. Par exemple, un hôtel qui constitue une correspondance sémantique parfaite mais qui se trouve juste en dehors du rayon géographique serait exclu avant le calcul de notation. Le post-filtre calcule la similarité sur l'intégralité de l'index puis supprime les résultats non conformes, ce qui peut renvoyer moins de k éléments mais garantit que le classement de similarité a pris en compte tous les documents. L'implication est que le choix entre pré-filtre et post-filtre oppose le rappel au nombre de résultats et à la latence. Le pré-filtre conserve k et peut réduire la latence pour des filtres sélectifs, mais risque de manquer des documents pertinents ; le post-filtre préserve le rappel mais peut renvoyer moins de résultats et demander davantage de calcul.
Combiner les filtres avec les facettes et les profils de notation
Les filtres et les facettes ciblent des structures de données de l'index qui sont distinctes des index inversés utilisés pour la recherche plein texte et des index vectoriels utilisés pour la recherche vectorielle. Lorsque les filtres et les opérations de facettage s'exécutent, le moteur de recherche peut appliquer le résultat opérationnel aux résultats de recherche hybride dans la réponse. Cela signifie qu'un filtre peut coexister avec une navigation facettée et des profils de notation sans entrer en conflit avec le classement vectoriel. Les facettes sont calculées sur le jeu de résultats final, après le filtrage et la fusion. Les profils de notation peuvent être appliqués aux champs texte, mais des ordres de tri explicites priment sur les résultats classés par pertinence : évitez donc orderby si vous voulez que la similarité et la pertinence BM25 pilotent le classement.
Limites d'application et quand reconsidérer l'approche
Les contraintes principales sont que les champs vectoriels eux-mêmes ne sont pas filtrables, si bien que chaque critère de filtre doit résider dans un champ distinct. Le post-filtre peut renvoyer moins de résultats que le k demandé, ce qui peut nécessiter une gestion dans votre application. Le pré-filtre peut réduire le rappel mais améliorer la latence pour des filtres très sélectifs. La documentation recommande de tester afin de confirmer quel mode est préférable plutôt que de supposer une réponse unique et correcte. Si vos critères de filtre sont très sélectifs et que vous avez besoin d'un résultat exact de k documents, vous pourriez devoir ajuster l'oversampling ou revoir la conception du filtre. Les tests doivent inclure la mesure du rappel, de la précision et de la latence dans des charges de travail réalistes. Si aucune combinaison de mode de filtre et d'oversampling ne donne des résultats acceptables, envisagez de redessiner le filtre pour qu'il soit moins restrictif ou de déplacer certaines contraintes dans l'embedding vectoriel lui-même au moyen de stratégies d'embedding tenant compte des métadonnées.
Points à vérifier
- Vérifier que chaque critère de filtre de la requête correspond à un champ non vectoriel marqué comme filtrable dans le schéma d'index.
- Confirmer que le paramètre vectorFilterMode est défini sur preFilter ou postFilter dans la requête de recherche hybride.
- Mesurer les performances des modes pré-filtre et post-filtre avec des requêtes représentatives pour déterminer l'équilibre optimal entre rappel, latence et nombre de résultats pour votre jeu de données spécifique.
- Vérifier que les résultats du post-filtre peuvent contenir moins de documents que le k demandé ; gérer ce cas dans la logique de votre application.
- S'assurer que les facettes et les profils de notation sont appliqués à l'ensemble de résultats hybride et n'interfèrent pas avec le classement vectoriel.
Champ d’application
Les champs vectoriels eux-mêmes ne peuvent pas être utilisés dans les expressions de filtre ; chaque critère de filtre exige un champ non vectoriel dédié. Le post-filtre peut renvoyer moins de documents que le k demandé, car la similarité est calculée sur l'intégralité de l'index puis les résultats sont supprimés. Le pré-filtre peut réduire silencieusement le rappel en réduisant le pool de candidats avant l'exécution de la recherche des plus proches voisins, même s'il peut abaisser la latence pour des filtres sélectifs. La documentation recommande de tester les deux modes plutôt que d'en prescrire un comme universellement correct ; le meilleur choix dépend de la distribution de vos données et de vos schémas de requêtes.