Spaces:
Runtime error
Runtime error
Commit History
28 days ago
-
feat(embeddings): voyage-4-large remplace EmbeddingGemma (API Voyage, halfvec 1024)
Mesure sur tout le corpus (32 303 morceaux) et le jeu relu de 102 questions : en recherche dense, MRR@20 0,758 contre 0,537 pour EmbeddingGemma en francais, 0,680 contre 0,537 en anglais. Par le chemin du chat lui-meme (mots-cles en plein texte, question entiere vectorisee, 8 extraits envoyes au modele), l'article attendu figure parmi les extraits 92 % du temps en francais contre 61 % avec Gemma (MRR@8 0,504 contre 0,336), et 87 % en anglais contre 56 % (0,538 contre 0,282). Vectoriser la question entiere plutot que ses mots-cles gagne a lui seul +0,087 de MRR@8 en francais [IC 95 % +0,035 ; +0,143] et +0,127 en anglais [+0,067 ; +0,191]. - embedding_service.py : VoyageProvider (httpx, connexion gardee : 0,42 s par question contre 1,14 s avec une connexion neuve). Son corps de requete reproduit les vecteurs deja calcules du corpus : un test voyage_live le prouve, cosinus >= 0,999 sur deux questions et deux documents. Lots de 900 textes et 90 000 jetons estimes, refus definit…57c8117
-
fix(journal): les journaux de l'application sortent, sans le jeton du WebSocket
- Aucun gestionnaire n'etait pose sur les loggers de l'application : uvicorn ne configure que les siens, et Python ne garde que WARNING. Le journal de chaque appel Mistral ou Groq (fin, jetons, duree) n'apparaissait nulle part, ni en developpement ni dans docker compose logs. - uvicorn journalise chaque WebSocket avec son URL entiere, par son journal d'erreurs que --no-access-log ne coupe pas : le jeton d'administration (?token=...) y passait en clair. Il est masque. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>b229001
-
fix(deploiement): corrections de la revue avant le premier deploiement
Issus d'une revue adversariale des fichiers de deploiement : - deployer.sh passait la fin du deploiement a `ssh ... bash -s` sur l'entree standard : le premier `docker compose exec` (qui garde l'entree ouverte) avalait la suite du script. Rien apres l'attente de la base ne s'executait — ni restauration, ni build, ni demarrage — et le script finissait sans erreur. La fin vit dans demarrer.sh, un fichier lance sur la VM ; chaque exec sans entree recoit </dev/null. - La restauration initiale ne regardait que l'existence de la table laws : un seul demarrage de l'API (qui cree le schema) la faisait sauter pour toujours, sans un mot. Elle se fait si la base n'a AUCUNE loi, dans une base recreee, avec --exit-on-error. - Le dump embarquait les comptes de developpement (et leurs mots de passe d'essai), conversations, jetons et caches : joignables depuis internet. Il n'en garde que le schema ; demarrer.sh cree l'administrateur de production (ADMIN_EMAIL, ADMIN_PASSWORD). -…2afa5a5 -
feat(intention): classement par Groq court et en cache, plus de classement local
Le classement local par embeddings est retire (intent_local.py, intent_examples.py, leurs tests et le prechauffage au demarrage). INTENT_CLASSIFIER accepte « groq » (defaut) ou « llm » (le modele du chat) ; l'ancienne valeur « gemini » est ramenee a « llm », et « local » est refuse avec la raison plutot qu'avec l'erreur generique de pydantic. Le mode groq menage le quota du jour (200 000 jetons, 1 000 requetes) : - consignes courtes (~300 jetons au lieu de ~870 : le chat plafonnait vers 215 questions par jour), schema strict, sortie de 40 jetons ; - deux derniers echanges seulement, 200 caracteres chacun ; - cache des verdicts (2 000 entrees, 24 h) : un message identique ne coute plus de requete ; un repli n'y entre jamais. Quand Groq ne peut pas repondre dans les temps — quota epuise (aucune requete n'est alors envoyee), attente du limiteur au-dela de 0,5 s, delai GROQ_INTENTION_TIMEOUT_S (3 s) depasse, panne — la question part aussitot en « juridique », avec une regle `defaut-g…21d412f
-
feat(chat): classement de l'intention en local, sans appel a Gemini
Chaque question coutait deux appels a Gemini : le classement (juridique, bavardage, question sur l'assistant, hors sujet) puis la reponse. Le classement prenait 3,6 s en reflexion minimale et une requete sur deux du quota gratuit. Il se fait desormais par EmbeddingGemma, deja en memoire pour la recherche : le message est rapproche d'une banque d'exemples etiquetes (intent_examples.py, questions de droit surtout en mots de tous les jours, noms de personnes et nominations compris). Chaque categorie recoit la moyenne de ses 3 exemples les plus proches ; une categorie non juridique ne l'emporte qu'avec 0,04 d'avance — dans le doute, c'est une question de droit. Un message court qui n'est pas clairement juridique est reclasse avec la question precedente (« et pour un mineur ? ») ; un verdict non juridique est encore contredit si un article du corpus est a 0,42 de similarite ou plus. Mesure sur 122 messages etiquetes (tests/fixtures/intent_eval.json, distincts de la banque), banque seule :…52efadf
-
feat(embeddings): EmbeddingGemma par defaut, et une panne qui se voit
EMBEDDING_PROVIDER vaut desormais gemma : les embeddings sont calcules en local, gratuitement, et Gemini ne sert plus qu'au chat. `gemini` reste disponible, a 768 dimensions lui aussi. LA PANNE LA PLUS PROBABLE DU SEMANTIQUE ETAIT LA SEULE INVISIBLE. Modele absent, fichier tronque, vecteurs d'un autre modele : dans chacun de ces cas, la recherche hybride avalait l'erreur et repondait en plein texte seul, pendant que GET /search/health disait « healthy ». Trois filets : - le modele est charge AU DEMARRAGE, et une question est reellement encodee. Un echec n'empeche pas l'API de demarrer — plein texte, chat et comptes s'en passent — mais il est journalise, et le service est ECARTE : garde, il retenterait de charger 300 Mo a chaque question ; - la sante passe en « degraded » si le service manque, si des vecteurs d'un AUTRE fournisseur sont en base (leurs cosinus ne veulent rien dire), ou si aucun vecteur n'est exploitable alors qu'il y a des articles a vectoriser. Ce dernier …7a1d560
-
feat: deployment on free tiers, object-storage documents, and email
Enables the project to run on a free hosting tier — ephemeral disk, managed Postgres behind a connection pooler, no outbound SMTP — and adds the password reset flow that was previously a dead end. Two blocking deployment bugs, both reproduced rather than deduced: DATABASE_URL with ?sslmode=require TypeError: connect() got an unexpected keyword argument 'sslmode' SQLAlchemy's asyncpg dialect forwards unknown query parameters straight to asyncpg.connect(), whose signature accepts neither sslmode nor channel_binding and has no **kwargs. The failure surfaces only on the first database access, long after an apparently successful start — and that is exactly the URL the "copy" buttons of managed Postgres providers hand out, and what .env.example recommended. Settings now refuse such a URL at load time, naming PGSSLMODE as the remedy. alembic/env.py, swapping asyncpg for psycopg2 but keeping the query string ProgrammingError: invalid dsn: invalid URI query parameter prepared_s…6429ad3
-
feat(ia): expliquer un article et comparer deux regimes, sur la page, sources a l'appui
Deux usages du modele qui ne passent pas par le chat, parce qu'il n'y a rien a converser. POST /laws/{id}/explain-article explique un article en langage courant a partir de son texte, de ses deux voisins et des metadonnees du document. La page envoie aussi l'extrait affiche : il sert de repli quand la base n'a pas de ligne pour ce numero (193 articles reconnus par la page contre 230 en base), mais seulement apres verification qu'il provient bien du document — sans ce controle, une route publique et non limitee serait un proxy de prompt gratuit sur un quota partage avec le chat. POST /compare compare deux regimes sur des criteres imposes. UNE recherche par sujet, l'une apres l'autre : mesure sur le corpus, la requete unique du chat rendait six articles d'un regime contre trois de l'autre et ratait le bloc 49-54 qui definit le second. Un schema JSON force chaque cellule a citer ses articles ; un numero sans article correspondant part dans unmatched_citations plutot que d'etre avale ; l…88e3dbc
-
fix(qualite): ruff devient une vraie barriere, et trouve un schema mort et casse
Ruff tournait sans jeu de regles declare : 1332 signalements, dont 98 faux positifs sur le motif `Depends()` de FastAPI et 615 modernisations de style. Un controle que personne ne peut passer n'est pas un controle. Le jeu retenu ne garde que ce qui signale un defaut reel (F, E4, E7, E9, I, RUF100), avec des exceptions nommees la ou l'ordre des imports EST la protection : env.py doit poser sys.path avant d'importer les modeles, conftest doit surcharger DATABASE_URL avant d'importer l'application. Ce que le controle a alors trouve : - UN SCHEMA MORT ET CASSE. `LawDetailResponse` existait deja, exposant `List[ArticleResponse]`. Il n'etait branche sur aucune route, et il etait doublement inutilisable : ArticleResponse porte le CONTENU integral de chaque article — pour le Code Minier, 166 Ko servis deux fois — et son `number` etait plafonne a 20 caracteres alors que la colonne en fait 64 depuis qu'elle accueille « QUATRE-VINGT-DIX-SEPTIEME ». Le plafond du schema est corrige, et…7435134 -
fix: colmater les fuites et les silences
Cinq defauts qui laissaient une panne passer pour un fonctionnement normal. 1. `cleanup_expired_cache` existait, etait importee par search_service, et n'etait APPELEE NULLE PART. `query_cache` et `embedding_cache` portent une colonne `expires_at` que rien n'appliquait : les deux tables grossissaient sans fin. Une colonne d'expiration non appliquee est pire que pas de colonne du tout — elle laisse croire que le menage est fait. Une tache de fond la purge toutes les quinze minutes. 2. `close_db()` etait appele APRES le `yield` du lifespan, donc jamais si l'arret venait d'une exception. Il passe dans le `finally`. 3. `GET /laws/{id}` chargeait deja les articles par `selectinload` et les jetait ensuite : `LawResponse` n'expose que `article_count`. La page de lecture les reconstruisait donc par expression reguliere sur le contenu — 193 articles la ou la base en compte 230 pour le Code Minier, et aucune page de PDF. Un nouveau `LawDetailResponse`, servi par c…5ca34ed
-
Etape 11 : authentification reelle branchee (demande n°2)
app/core/auth.py (188 lignes, JWT + bcrypt + roles) etait complet et importe par PERSONNE. Les 9 endpoints d'administration passaient par deux stubs renvoyant {"id": 1, "role": "admin"} : ils etaient ouverts a tous. BUG BLOQUANT decouvert en chemin : passlib 1.7.4 (derniere version, 2020) est incompatible avec bcrypt >= 4.1 — il lit bcrypt.__about__.__version__, supprime depuis. Avec bcrypt 5.x installe, hash_password echouait avec "password cannot be longer than 72 bytes" MEME pour 13 caracteres : l'authentification aurait ete inutilisable telle que declaree. -> bcrypt utilise directement, passlib retire des manifestes. Pre-hachage SHA-256 + base64 avant bcrypt : entree de longueur fixe, donc support des phrases de passe longues sans la troncature silencieuse a 72 octets de bcrypt (deux mots de passe partageant leurs 72 premiers octets etaient equivalents). Ajouts : - app/api/routes/auth.py : POST /login (formulaire OAuth2, l'URL exacte attendue par oauth2_scheme, donc le…da2ad52
-
Etape 2 : bugs independants du reste (auth et schema non touches)
Corriges avant l'auth pour que le commit d'authentification ne porte que sur l'authentification. Toujours casses, desormais reparés : - database.py : health_check_db executait la chaine brute "SELECT 1", refusee par SQLAlchemy 2. L'exception etait avalee -> GET /admin/system declarait la base en panne EN PERMANENCE. - rag_service.py : SYSTEM_PROMPTS est indexe par langue, pas par persona. SYSTEM_PROMPTS["citoyen"] levait KeyError a chaque appel -> /rag/ask/stream n'a jamais rien renvoye d'autre qu'une erreur. Remplace par get_system_prompt(persona, language), deja utilise en non-streaming. - rag_service.py + rag.py : joinedload sur une collection sans .unique() -> InvalidRequestError. Toute requete portant un session_id existant echouait, et GET /rag/conversations/{id} renvoyait toujours 500. - 4 endpoints inatteignables, masques par une route parametree declaree avant (FastAPI resout dans l'ordre) : /upload/health (404), /categories/health (422), /personas/health (4…016376a
-
feat(migration): Replace Redis/Meilisearch/Celery with 100% native PostgreSQL FTS and FastAPI BackgroundTasks
c77abb9
-
chore: initial standalone backend for JuriX API (Render)
9cf9a2a