veDB MySQL est un produit de base de données relationnelle cloud-native auto-développé par Volcano Engine, 100% compatible avec MySQL natif. veDB-Search, quant à lui, est un service complet de recherche hybride basé sur la technologie de veDB MySQL, permettant aux utilisateurs d'effectuer le stockage et la recherche hybride de données vectorielles, textuelles et scalaires en utilisant uniquement du SQL.

Cet article constitue un guide pratique. Nous commencerons par expliquer comment résoudre efficacement le problème de la récupération multi-chemins dans des scénarios réels en utilisant une seule instruction SQL avec veDB-Search, en débloquant ainsi davantage de fonctionnalités pour répondre aux besoins métier. Ensuite, nous présenterons la fonctionnalité intégrée In-DB Embedding, mettant en avant l'avantage de faire descendre logiquement l'intégration vectorielle du côté applicatif vers la base de données. Enfin, nous démontrerons avec un cas métier e-commerce comment veDB-Search prend en charge la recherche textuelle universelle.

Récupération multi-chemins : Une seule SQL pour la récupération vectorielle, textuelle et scalaire multiple

Les défis de l'architecture traditionnelle de récupération multi-chemins

• Architecture complexe : Nécessite le maintien simultané d'une base de données vectorielle, d'un moteur de recherche plein texte (comme Elasticsearch) et d'une base de données relationnelle. De plus, la base de données vectorielle doit gérer plusieurs embeddings distincts.
• Synchronisation des données : Nécessite la construction de liens ETL ou CDC complexes pour garantir la cohérence des données.
• Logique métier lourde : La couche applicative doit appeler séparément les SDK de différents systèmes pour effectuer la récupération, l'agrégation, la suppression des doublons et le classement des résultats, ce qui rend le code complexe et difficile à maintenir.

La solution innovante de veDB-Search

• Une seule instruction SQL pour réaliser la récupération multi-chemins
• Processus d'exécution de la récupération multi-chemins

1. Analyse de l'instruction SQL standard
2. Optimiseur qui sélectionne automatiquement l'index optimal et génère le plan optimal
3. Orchestrateur qui exécute le filtrage sur les index vectoriels pour chaque voie de récupération
4. Fusion des scores et classement en fonction des poids
5. Renvoi du résultat final

• Avantages fondamentaux de veDB-Search

1. Amélioration de la productivité : Simplifie le code complexe d'interaction multi-système en une seule instruction SQL.
2. Réduction de la charge opérationnelle : Il suffit de maintenir une seule instance veDB, sans se soucier de la synchronisation des données.
3. Garantie de performance : Optimiseur intégré qui sélectionne le chemin d'exécution optimal, architecture distribuée garantissant les performances.

Exemple pratique de récupération tri-voies

Prenons l'exemple d'un scénario e-commerce pour démontrer comment utiliser veDB-Search pour effectuer efficacement une récupération vectorielle tri-voies + filtrage conditionnel avec une seule instruction SQL.

• ÉTAPE 1 : Création d'un index hybride contenant plusieurs colonnes vectorielles sur la table produits

ALTER TABLE produits ADD VECTOR INDEX `index_hybride`(
    -- colonne de texte pour la recherche de contenu textuel
    `contenu`,
    
    -- emb1/emb2/emb3 sont trois colonnes vectorielles indépendantes pour une récupération approximative multi-voies
    `emb1`, `emb2`, `emb3`)
    SECONDARY_ENGINE_ATTRIBUTE = '{
        "distance": "cosine",    -- spécification de l'algorithme de distance
        "scalar_fields": "categorie, reduction, prix"    -- spécification des colonnes de filtrage scalaire
    }'
;

• ÉTAPE 2 : Une instruction SQL pour réaliser la récupération vectorielle tri-voies + recherche textuelle + filtrage scalaire

WITH 
-- Première voie : topk vectoriel textuel + recherche de contenu textuel
rappel_description AS (
    SELECT id, nom, 2.0 as score, 'description' as type_rappel
    FROM produits
    WHERE MATCH(contenu) AGAINST("équipement de randonnée en plein air")     -- prise en charge de la recherche textuelle
    ORDER BY similarite(emb1, [0.1, 0.2, 0.3, 0.4]) DESC
    LIMIT 50
),

-- Deuxième voie : topk vectoriel d'images de produit + filtrage par prix + filtrage par réduction
rappel_produit_populaire AS (
    SELECT id, nom, 1.5 as score, 'produit' as type_rappel
    FROM produits
    WHERE prix BETWEEN 200 AND 400
    AND reduction > 0.10    -- prise en charge du filtrage scalaire
    ORDER BY similarite(emb2, [0.1, 0.2, 0.3, 0.4]) DESC
    LIMIT 50
),

-- Troisième voie : topk vectoriel d'images détaillées du produit
rappel_detaille AS (
    SELECT id, nom, 0.8 as score, 'produit_detaille' as type_rappel
    FROM produits
    ORDER BY similarite(emb3, [0.1, 0.2, 0.3, 0.4]) DESC
    LIMIT 50
),

-- Combinaison des résultats tri-voies
combines AS (
    SELECT * FROM rappel_description
    UNION ALL SELECT * FROM rappel_produit_populaire
    UNION ALL SELECT * FROM rappel_detaille
)

-- Classement et sortie finaux
SELECT id, nom, score, type_rappel
FROM combines
ORDER BY score DESC
LIMIT 100;

Débloquer davantage de fonctionnalités avancées

• Conditions de filtrage

veDB-Search prend en charge l'utilisation de la syntaxe WHERE standard SQL pour effectuer un filtrage précis lors de la récupération. Les utilisateurs n'ont qu'à rédiger diverses conditions de filtrage selon les besoins métier, et veDB-Search optimisera automatiquement pour choisir la stratégie par-filtrage/post-filtrage. Dans des cas extrêmes, si le filtrage scalaire est très efficace, l'optimiseur peut adopter une recherche KNN exhaustive pour obtenir un meilleur effet d'exécution. Les utilisateurs peuvent effectuer un filtrage complexe selon le standard SQL, par exemple :

 WHERE 
     MATCH(contenu) AGAINST("équipement de randonnée en plein air")
     AND (
           prix BETWEEN 200 AND 400
           OR
           reduction > 0.10
         )

• Correspondance textuelle

veDB-Search prend en charge l'utilisation de la syntaxe MATCH AGAINST améliorée, prenant en charge les requêtes booléennes, les requêtes de phrases, les requêtes floues, etc. veDB-Search construira un index inversé sur la cible colonne, mettant à jour en temps réel les nouvelles données écrites, et prenant en charge l'utilisation mixte avec d'autres conditions de filtrage. Par exemple :

SELECT * FROM articles 
WHERE 
    MATCH(titre) AGAINST('recherche base de données' IN BOOLEAN MODE)
    AND prix BETWEEN 100.00 and 200.00;

• Fusion de classement par inverse de rang (RRF)

veDB-Search prend en charge le pondération des résultats de récupération multi-voies, garantissant à la fois la précision de la récupération scalaire et textuelle, ainsi que la capacité de compréhension sémantique de la recherche vectorielle.

Formule de calcul RRF :

RRF_score = (1 / (k + rang_dans_liste1)) + (1 / (k + rang_dans_liste2)) + ...

• rank_i : Position du document dans la liste de résultats i (1er, 2ème, etc.).
• k : Une constante ajustable, généralement ≥ 60, utilisée pour contrôler le degré d'influence du classement.

Par exemple :

SELECT
     id,
     titre,
     1 / (@k + RANK() OVER (ORDER BY score DESC)) AS partiel_rrf  -- combiné avec la fonction de fenêtre

RRF joue un rôle important dans la pondération des résultats de récupération multi-voies, comme équliibrer les avantages de différentes voies de récupération, améliorer la pertinence des résultats et fournir une norme de classement unifiée.

Si les utilisateurs ne souhaitent pas utiliser RRF, ou s'ils souhaitent obtenir des valeurs de score spécifiques, ils peuvent utiliser la fonction de similarité fournie par veDB-Search, qui renvoie des valeurs de score déjà normalisées, pouvant participer directement au classement ORDER BY.

SELECT
    distance_cosinus(emb1, [0.1, 0.2, 0.3]) as distance,
    similarite(distance) * FACTEUR as similarite -- les utilisateurs peuvent spécifier un facteur de pondération
FROM articles
ORDER BY similarite DESC

• Filtrage par distance ou similarité

veDB-Search prend en charge la spécification d'une distance maximale pour filtrer les points de données à faible similarité (distance élevée) pendant le processus de recherche, afin d'améliorer davantage la précision.

-- Filtrage par distance maximale spécifiée
SELECT * FROM articles 
WHERE
    distance_cosinus(emb1, [0.1, 0.2, 0.3]) as distance < 2.0

**In-DB Embedding : Prise en charge de bout en bout de la recherche "texte-vers-tout"**​

Nous avons précédemment expliqué comment utiliser une seule instruction SQL pour réaliser efficacement la récupération multi-chemins. Dans cette section, nous explorerons une autre fonctionnalité avancée — In-DB Embedding, c'est-à-dire faire descendre transparentement le processus d'intégration vectorielle du côté applicatif vers l'intérieur de veDB-Search. Enfin, nous démontrerons avec un cas métier e-commerce comment veDB-Search prend en charge la capacité de "recherche textuelle universelle".

veDB-Search prend en charge deux types de fonctionnalités In-DB Embedding :

1. Fournit la fonction to_embedding(), que les utilisateurs appellent directement pour générer des embeddings à partir de texte/images entrants
2. Prend en charge la fonction embedding_pipeline(), définie dans les index hybrides, permettant de terminer transparentement la conversion des données brutes en embeddings sans que l'utilisateur ait à appeler explicitement les fonctions ci-dessus.

	fonction to_embedding()	fonction embedding_pipeline()
Méthode d'appel/déclenchement	Appel explicite (l'utilisateur doit écrire l'instruction SQL)	Déclenchement implicite (configuré lors de la définition de l'index hybride, déclenché automatiquement par la base de données après l'écriture des données brutes)
Stockage des données	Stockage explicite de la colonne embedding (type VECTOR). Les utilisateurs peuvent SELECT les valeurs d'embedding spécifiques, et peuvent également effectuer une récupération de similarité topk sur la colonne embedding.	Stockage en écriture uniquement des colonnes de données brutes (texte/URL d'image), sans stockage de la colonne embedding. Le moteur de base génère l'embedding et construit automatiquement l'index, les utilisateurs ne peuvent pas SELECT les valeurs d'embedding spécifiques, mais peuvent effectuer une récupération de similarité topk sur la colonne embedding.
Temps réel	Conversion instantanée en avant-plan, adapté aux scénarios de requête dynamique	Conversion asynchrone en arrière-plan lors de l'écriture, adapté à la synchronisation de données par lots
Optimisatino des coûts	Stockage des valeurs d'embedding nécessite un espace supplémentaire, coût plus élevé	Pas besoin de stocker les valeurs d'embedding spécifiques, économie de coûts de stockage, adapté aux données de très grande échelle
Flexibilité	Prend en charge la transmission dynamique de différents modèles et paramètres à chaque appel, plus flexible	Le modèle et les paramètres sont fixes après la création de l'index, impossibilité de modification dynamique

Fonction to_embedding()

Positionnement de la fonction : Convertit des données comme le texte, les images en embeddings pour prendre en charge la recherche vectorielle multimodale.

Mise en œuvre technique

• Vectorisation de texte : Prend en charge une intégration transparente avec les modèles fournis par Volcano Ark (comme Doubao-embedding-large), convertissant les titres de produits, les descriptions, etc. en embeddings.
• Vectorisation d'images : Prend en charge une intégration transparente avec les modèles fournis par Volcano Ark (comme Doubao-embedding-vision), convertissant les URL d'images de produits en embeddings.

Signature de la fonction

to_embedding('id_modele', 'cle_modele', 'entree_utilisateur', 'type_modele')

• id_modele : ID du modèle Volcano Ark
• cle_modele : Clé du modèle Volcano Ark
• entree_utilisateur : Données brutes dont l'utilisateur a besoin pour générer l'embedding (texte/URL d'image)
• type_modele : Trois valeurs possibles
• content : Modèle de texte, adapté aux scénarios où les données brutes sont du texte
• image : Modèle multimodal, adapté aux scénarios où les données brutes sont des URL d'images
• text : Modèle multimodal, adapté aux scénarios où les données brutes sont du texte

Exemple d'utilisation

Créons une table document_asset dans veDB-Search, en appelant la fonction to_embedding() pour convertir les données textuelles brutes en embeddings de 4096 dimensions, stockés dans une colonne VECTOR. Ensuite, en fonction des questions posées par les utilisateurs, nous effectuons une récupération de similarité topk sur cette colonne vectorielle pour rappeler finalement aux utilisateurs des documents d'aide pertinents.

/* Génération de l'embedding correspondant à "veste trois-en-un" */
SELECT to_embedding('doubao-embedding-large', '$cle_modele','veste trois-en-un', 'content') AS vec_titre;

/* Génération de l'embedding correspondant à l'image de la veste */
SELECT to_embedding('doubao-embedding-vision', '$cle_modele', 'https://exemple.com/produit.jpg', 'image') AS vec_image;

/* Création d'une table de documents avec colonne VECTOR et création d'un Index ANN pour accélérer les requêtes */
CREATE TABLE `document_asset` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 'ID de clé primaire, auto-incrémentation et identifiant unique',
  `contenu_vec` VECTOR (4096) NOT NULL COMMENT 'Contenu textuel, pour vectorisation',
  ANN KEY `idx` (`contenu_vec`))
ENGINE=InnoDB COMMENT='Table de documents';

/* Insertion de quelques exemples de données */
INSERT INTO document_asset VALUES
    (1, (select to_embedding('$id_modele', '$cle_modele', 'Guide utilisateur MySQL', 'content'))),
    (2, (select to_embedding('$id_modele', '$cle_modele', 'Introduction à veDB-Search', 'content'))),
    (3, (select to_embedding('$id_modele', '$cle_modele', 'Application réelle de RAG', 'content'))),
    (4, (select to_embedding('$id_modele', '$cle_modele', 'Agent IA personnalisé', 'content'))),
    (5, (select to_embedding('$id_modele', '$cle_modele', 'Introduction aux bases de données vectorielles', 'content')));

/* Pour l'entrée utilisateur "Comment essayer MySQL", compléter la récupération de similarité top 2 */
SELECT id FROM document_asset
ORDER BY
distance_l2(to_embedding('$id_modele', '$cle_modele', 'Comment essayer MySQL', 'content'), contenu_vec)
LIMIT 2;

Fonction embedding_pipeline

Positionnement de la fonction

• Transparence et facilité d'utilisation : Lors de la création d'index sur une table, définissez embedding_pipeline pour l'index, et les données des colonnes texte/URL d'image seront automatiquement générées en embeddings dans le moteur de base et écrites dans la structure d'index.
• Économie de coûts : Pas de stockage des données d'embedding spécifiques dans la table veDB, uniquement le stockage des données brutes (texte/URL d'image), ce qui réduit considérablement les coûts de stockage.

Signature de la fonction

embedding_pipeline('entree_utilisateur', 'type_modele')

• entree_utilisateur : Données brutes dont l'utilisateur a besoin pour générer l'embedding (texte/URL d'image)
• type_modele : Trois valeurs possibles
• content : Modèle de texte, adapté aux scénarios où les données brutes sont du texte
• image : Modèle multimodal, adapté aux scénarios où les données brutes sont des URL d'images
• text : Modèle multimodal, adapté aux scénarios où les données brutes sont du texte

Exemple d'utilisation

/* Création d'une table de produits e-commerce avec index hybride. L'index hybride définit embedding_pipeline */
CREATE TABLE `produits` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 'ID de clé primaire, auto-incrémentation et identifiant unique',
  `url_image` MEDIUMTEXT NOT NULL COMMENT 'URL de l''image',
  `type` INT NOT NULL DEFAULT 0 COMMENT 'Type de produit, pour filtrage scalaire',
  ANN KEY `idx` (`url_image`) SECONDARY_ENGINE_ATTRIBUTE = '{
    "scalar_fields": "type",
    "distance": "cosine",
    "emb_pipeline": [
      {
        "col_name": "url_image",
        "model_id": "$id_modele",
        "auth_key": "$cle_modele",
        "type": "image"
      }
    ]
  }'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='Table de sélection vectorielle de produits';

/* Insertion de données d'URL d'image brutes, sans génération explicite d'embedding par l'application */
INSERT INTO produits(id, url_image, type) values
  (1, 'https://exemple.com/iphone17.jpg', 1),
  (2, 'https://exemple.com/macbook.jpg', 1),
  (3, 'https://exemple.com/ipad.jpg', 1),
  (4, 'https://exemple.com/brush_dentaire.jpg', 2);

/* Récupération des 2 images les plus similaires */
SELECT id FROM produits
ORDER BY
distance_l2(embedding_pipeline('https://exemple.com/iphone15.jpg', 'image'), url_image) 
LIMIT 2;

Cas pratique de sélection de produits e-commerce

[Cas 1] Recherche d'images par texte : Description textuelle correspondant aux images de produits

Besoin du scénario : L'utilisateur saisit le texte "veste trois-en-un" et doit récupérer des produits similaires à la description textuelle.

Étapes de mise en œuvre

1. Création d'une table de produits et d'un index hybride : L'index spécifie emb_pipeline, définit un modèle d'embedding multimodal
2. Écriture des données : Écriture des URL d'images de produits et d'autres métadonnées de produit dans la table de produits de veDB-Search
3. Filtrage des résultats : Combinaison des ventes, prix et autres conditions scalaires pour filtrer les produits de qualité selon les informations saisies par l'utilisateur

Exemple SQL

SELECT id_produit, titre, url_img
FROM produits
WHERE ventes > 100 AND prix < 500
ORDER BY
distance_l2(embedding_pipeline('veste trois-en-un', 'text'), url_image)
LIMIT 10;

[Cas 2] Recherche d'images par images : Recommandation de produits similaires en fonction du contenu du panier d'achat de l'utilisateur

Besoin du scénario : L'utilisateur télécharge une image de produit, combine d'autres métadonnées de produit, et renvoie des produits identiques ou similaires sur la plateforme.

Étapes de mise en œuvre :

1. Création d'une table de produits et d'un index hybride : L'index spécifie emb_pipeline, définit un modèle d'embedding multimodal
2. Écriture des données : Écriture des URL d'images de produits et d'autres métadonnées de produit dans la table de produits de veDB-Search
3. Classement des résultats : Classement combiné par similarité d'images, ventes et prix.

Exemple SQL :

SELECT id_produit, titre, url_img
FROM produits
WHERE ventes > 100 AND prix < 500
ORDER BY
distance_l2(embedding_pipeline('https://exemple.com/produit.jpg', 'image'), url_image)
LIMIT 10;

Meilleures pratiques et astuces

veDB-Search, grâce aux deux capacités majeures d'une seule instruction SQL pour la récupération multi-chemins et In-DB Embedding, prend directement en charge le besoin métier de "recherche textuelle universelle", tout en réduisant considérablement la complexité de développement et les coûts opérationnels.

**Plus d'astuces :**​

1. Conception des voies : Concevoir des voies de récupération en fonction des dimensions principales du métier (comme les images de produits, les descriptions, les étiquettes).
2. Optimisation des poids : Ajuster continuellement les poids de score de chaque voie dans les instructions SQL de récupération multi-chemins par des tests A/B pour optimiser l'efficacité de récupération.
3. Optimisation des index : Créer des index hybrides, en incluant les colonnes d'embedding et les colonnes scalaires courantes dans l'index. Et à grande échelle, utiliser les capacités cloud-native de veDB pour réaliser une mise à l'échelle élastique.

veDB-Search transforme la base de données d'un simple "conteneur de données" passif à un "moteur cognitif" actif, constituant l'infrastructure clé pour la construction des applications IA de la prochaine génération.

Basé sur la base technique puissante de veDB MySQL, la fonction de recherche hybride de veDB-Search est actuellement prise en charge pour l'ouverture de tests en liste blanche sur Volcano Engine, n'hésitez pas à cliquer sur ["Lire l'original"] pour soumettre un ticket et participer à l'essai.