VoiceSessions : nombre de sessions ayant utilisé le vocal au moins une fois, lu
dans le JSON de Metadata. Volontairement hors d'AppTypeDistribution — le vocal
n'est pas une plateforme mais un mode d'interaction : un visiteur passe des
lunettes à l'écran dans une même session, or la distribution compte une entrée
par session tranchée sur l'événement le plus ancien. Le chiffre aurait dépendu de
l'ordre dans lequel le visiteur a touché ses appareils. Colonne Metadata déjà
existante : aucune migration, le gel du lot B tient.
Le test InMemory ne prouve rien ici — le provider évalue le filtre côté client,
donc une requête intraduisible passerait au vert. Un test Postgres l'accompagne.
IsAutoTriggered devient IsVisitorQuestion (défaut true). Le nom d'hier ne
couvrait qu'un des deux cas : le vrai sens n'est pas « déclenché
automatiquement » mais « ce tour n'est pas une question de visiteur », ce qui
vaut aussi pour l'aperçu de conversation, où c'est le gestionnaire qui teste sa
personnalité. Renommé pendant qu'un seul commit en dépendait. Le défaut à true
est délibéré : une app visiteur publiée qui n'envoie pas le champ continue de
journaliser, et un test le fixe.
dotnet test : 204 passés, 14 sautés, 0 échec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
