La première question posée lors d'un projet RAG porte souvent sur la base vectorielle. Pour la plupart des organisations, la réponse est plus ennuyeuse qu'attendu.
01. pgvector suffit probablement
Si vous utilisez déjà PostgreSQL, pgvector couvre confortablement la plupart des scénarios d'entreprise et encaisse des dizaines de millions de vecteurs. Vous conservez vos sauvegardes et vos droits et n'exploitez aucun système supplémentaire.
02. L'option gérée
Si vous ne voulez pas de charge d'exploitation, des services gérés existent ; installation et mise à l'échelle ne vous incombent pas. En contrepartie, les données sont à l'extérieur et le coût croît avec le volume.
03. Très grande échelle
S'il vous faut des milliards de vecteurs sur votre propre infrastructure, on passe à des systèmes conçus pour cette échelle. Bien moins d'organisations entrent dans cette catégorie qu'elles ne le croient.
04. L'alternative du moteur de recherche
Si vous disposez déjà d'une recherche d'entreprise, la plupart prennent désormais en charge la recherche vectorielle. Bâtir sur l'existant sans ajouter de composant peut être la voie la moins coûteuse en frictions.
05. Ce qui détermine vraiment la qualité
Le choix de la base ne figure pas parmi les trois facteurs déterminant la qualité d'un RAG. Le découpage, le modèle d'embedding et la conception de la recherche pèsent bien davantage. Y consacrer des semaines revient à investir au mauvais endroit.
06. Gardez-la remplaçable
Isolez la couche de recherche de votre application. Changer de socle lorsque le volume grandit ne signifiera alors pas réécrire l'application.