Le RAG n'avait tourne que sur une base a une seule instance -- le cas ou le
post-filtrage HNSW ne se voit pas. 14 tests Testcontainers sur l'image de
`Deployment/Dockerfile.postgres`, donc le meme PostGIS + pgvector que la
prod. Ils se sautent proprement (SkippableFact) sans demon Docker.
Ce que ca etablit :
- pgvector 0.8.6 : `SET hnsw.iterative_scan` est accepte. Ce SET est pose a
chaque recherche par SearchAsync et n'existe qu'a partir de 0.8 -- sur une
version anterieure, toute recherche echouait en production.
- Les extensions vector et postgis sont bien creees par les migrations.
- A deux instances, l'une saturant l'axe de la question a 30 contre 1,
SearchAsync rend le bon nombre de resultats, tous de la bonne instance.
Aucune fuite d'un client vers un autre.
⚠️ DEUX RESULTATS INATTENDUS, contraires a ce que le plan supposait.
1. Ce qui protege du post-filtrage n'est PAS le parcours iteratif, c'est
l'index sur (InstanceId, ContentType). Le planificateur filtre par
instance d'abord et trie exactement : l'index HNSW n'est jamais touche,
donc il n'y a rien a post-filtrer. Verifie a 620 lignes (test) et a
22 000 hors suite, avec 2 000 lignes pour l'instance cible. Un test fige
ce plan -- si cet index disparaissait, la recherche se degraderait sans
qu'aucune erreur ne le dise.
2. Et si on retire cet index, `hnsw.iterative_scan = relaxed_order` NE
RATTRAPE RIEN : le parcours s'epuise apres ~335 lignes sans avoir atteint
l'instance minoritaire, et rend zero. Le meme jeu de donnees avec l'index
HNSW construit APRES l'insertion rend bien ses 20 lignes -- c'est donc la
connectivite du graphe qui decide, et nos migrations creent l'index sur
une table vide. Le SET de SearchAsync est donc une assurance qui ne couvre
pas ce qu'on croyait ; on le garde (il est correct et sans cout), mais
c'est l'index qui fait le travail.
Deux notes d'outillage :
- Testcontainers est epingle en 3.10.0 : la 4.x parle l'API Docker 1.44 et
l'engine local plafonne a 1.43.
- L'image est construite par le CLI docker, pas par le constructeur d'images
de Testcontainers : celui-ci relit le FROM pour pre-tirer l'image de base
et ne sait pas parser `tag@sha256:`. Ce digest protege la base d'un
changement de glibc sous ses index -- il ne se retire pas pour un test.
S'ajoutent 4 tests de GetSummary contre le vrai Postgres, qui levent le
caveat du commit precedent : le provider InMemory evalue tout cote client,
donc il ne disait rien de la traduction SQL. Les agregats du plan de base,
ceux du plan avance, le filtre appType et la fenetre vide traduisent tous.
dotnet test 200/200, aucun saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Thomas Fransolet