chore: auto-commit from dashboard

This commit is contained in:
2026-08-22 08:40:56 +00:00
parent 4d2dbfb8a7
commit fe500a7227
35 changed files with 1372 additions and 144 deletions

View File

@@ -1,6 +1,6 @@
# Index — projects/
> 237 note. Citește acest index întâi; deschide doar fișierele relevante.
> 238 note. Citește acest index întâi; deschide doar fișierele relevante.
- **[Feature: PDF Download Button in Files Dashboard](FEATURE-files-pdf-download.md)**
- User is comfortable with multi-session handoff (can track progress across sub-agents)
@@ -52,6 +52,8 @@
1. "Verifică dacă a apărut newsletter nou cercetași (>13)"
- **[Rușinea - Notițe pentru Grup Sprijin](grup-sprijin/rusine.md)** `@sprijin #grup-sprijin`
- Ce s-ar întâmpla dacă ai renunța la standard?
- **[LFM2.5-230M — evaluare ca preprocesor de rezumat / fallback conversațional (2026-08-21)](lfm2.5-230m-summarization-eval.md)**
**Concluzie provizorie:** `qwen3.5:2b` via Ollama pe `10.0.20.161` e candidatul recomandat pentru fallback conversațional RO — precizie fact
- **[Progress Tracking - Articole Monica Ion Blog](monica-ion/articole/PROGRESS.md)**
[Rezumat 2-3 rânduri]
- **[Lista URL-uri Articole Monica Ion Blog](monica-ion/articole/URL-LIST.md)**

View File

@@ -0,0 +1,71 @@
# LFM2.5-230M — evaluare ca preprocesor de rezumat / fallback conversațional (2026-08-21)
Spike de testare: se poate folosi [`LiquidAI/LFM2.5-230M`](https://huggingface.co/LiquidAI/LFM2.5-230M) (230M params, edge-optimized, Liquid AI) ca preprocesor local — rezumă conținut lung (email-uri, transcripturi) înainte să ajungă la Claude, ca să reducem consumul de rate limit ([[user_anthropic_subscription]]). Continuare a liniei de spike-uri din [[cactus-needle-function-calling-eval]] (acolo: pre-router pentru function calling; aici: sumarizare), aceeași motivație de fond.
## Setup
Testat direct în `.venv` de producție echo-core — `transformers` 5.12.1 și `torch` 2.11.0 erau deja instalate (satisfac cerința oficială `transformers>=5.0.0`), deci fără pip install nou. Script de test și textele de input în `/tmp/lfm-test` (nu în repo, se pierd la reboot). Checkpoint descărcat în `~/.cache/huggingface/hub/models--LiquidAI--LFM2.5-230M` (438MB, rămâne după reboot).
Input real din KB: email RO dens (validare amendament rezoluție scout.ro, ~3000 caractere, cu TL;DR existent de Claude ca reper) + fragment transcript YouTube EN (~3000 caractere, video despre AI trading).
## Rezultate
- **Engleză: surprinzător de bună.** Rezumat coerent, factual, parafrazat (nu copy-paste), fără halucinații evidente pe fragmentul testat. Latență ~6.7s/query pe CPU (6 core-uri), fără GPU disponibil pe această mașină.
- **Română: nefolosibil.** Output amestecat cu spaniolă/portugheză și cuvinte inventate ("o spesia se presentă", "respektiv", "Resumen:... el documento solicita...") — chiar și cu prompt integral în română. Nu produce propoziții gramaticale corecte în RO.
- **Confirmă cardul modelului**: limbile suportate oficial sunt EN, AR, ZH, FR, DE, IT, JA, KO, PT, ES — **română nu e în listă**, spre deosebire de Needle (26M, netestat oficial pe RO dar funcțional empiric — vezi [[cactus-needle-function-calling-eval]]). Aici, spre deosebire de Needle, absența suportului oficial s-a confirmat empiric ca blocaj real, nu doar teoretic.
- Load model: 1.8-12.6s (variază, prima rulare vs. cache warm). Foarte ușor per dimensiune (438MB pe disc).
### Q4_K_M (GGUF, llama.cpp) — testat local (2026-08-21)
La cererea lui Marius: cât de rapid merge quantizat, ca preprocesor CPU-only (fără să crească dimensiunea modelului). Descărcat `LiquidAI/LFM2.5-230M-GGUF` (fișier `LFM2.5-230M-Q4_K_M.gguf`, 144MB — 3x mai mic decât BF16). Rulat cu binarul `llama-completion` deja prezent local (`/home/moltbot/prism-llama/llama-prism-b8846-d104cf1/`), 6 threads CPU, același fragment EN de test (~3000 caractere, 711 tokeni prompt).
- **Load: ~1.1s.**
- **Prompt eval: 711 tokeni în 1.06s (670 tok/s).**
- **Generare: 69 tokeni în 0.57s (120 tok/s).**
- **Total end-to-end (load+prompt+generare): ~3s**, față de ~8.5s la BF16 prin `transformers` (load 1.8s + generare 6.7s) — **~2.8x mai rapid**. Diferența vine atât din Q4 cât și din backend-ul llama.cpp (mult mai optimizat pe CPU decât `transformers` eager mode).
- Calitate pe engleză neschimbată vizibil față de BF16 — rezumat coerent, fără degradare perceptibilă din quantizare.
- **Nu s-a retestat pe română** — quantizarea nu schimbă cauza blocajului (model neantrenat pe RO), doar viteza; ar reproduce identic amestecul spaniolă/portugheză de la testul BF16.
### Test suplimentar — fallback conversațional când Claude atinge rate limit (2026-08-21)
Marius a clarificat cazul real de utilizare: nu preprocesor de sumarizare, ci **model de fallback pentru conversație directă cu el, când Claude e blocat pe rate limit**. Întrebare: înțelege măcar input în română, chiar dacă generarea e stricată? Testat cu Q4_K_M (`llama-completion`, 3 prompturi scurte, independente de sumarizare):
1. **Factual simplu** ("Care este capitala Franței?") → răspuns halucinat: cuvânt inventat "Căspătrășești", prezentat ca fiind capitala **României** (nici măcar țara întrebată).
2. **Comprehension extractiv** (propoziție scurtă RO + întrebare "ce a uitat X acasă?", răspuns așteptat 1 cuvânt) → nu a răspuns, a ecoat înapoi linia de instrucțiune.
3. **Conversație casual** ("Ce mai faci?") → răspuns aproape integral **în franceză**.
**Verdict: nu doar generarea e stricată — modelul nu procesează corect input în română la niciun nivel** (factual, extractiv, conversațional), indiferent de tip de task. Mai grav decât la testul de sumarizare: aici halucinează fapte complet greșite (țară greșită), nu doar gramatică stricată.
## Concluzie
**Nu e viabil ca preprocesor general și nici ca fallback conversațional pe română** — a se vedea și testul suplimentar de mai sus, care exclude complet acest caz de utilizare (fallback la rate limit Claude). — traficul Echo e majoritar în română (conversații Discord/Telegram/WhatsApp cu Marius), iar modelul degradează în text amestecat spaniolă/portugheză pe input RO, indiferent de limba promptului. L-ar face utilizabil doar pe un subset îngust (conținut deja în engleză — unele transcripturi YouTube, email-uri EN), care nu acoperă cazul principal de reducere a rate limit-ului.
**Decizie:** nicio integrare în echo-core. Nu s-a modificat cod de producție.
**Dacă se reia pe viitor:** varianta de rezolvat ar fi un model LFM2 mai mare (700M/1.2B) din aceeași familie, dacă lista de limbi suportate se extinde la română — de verificat pe cardul modelului înainte de a relua testul, ca să nu se repete același blocaj.
## Continuare — căutare model RO pentru fallback la rate-limit Claude (2026-08-21)
Marius a cerut integrare reală (nu doar spike): un model local RO-capabil ca fallback conversațional când Claude CLI dă `Error: Claude CLI error (exit 1): You've hit your session limit · resets HH:MMam (UTC)` (posibil și limită totală de abonament, nu doar sesiune — de confirmat pe teren). Vezi și [[project_lfm2_230m_ro_fallback_eval]].
Prima variantă propusă (EuroLLM-1.7B) s-a dovedit **insuficientă pe context**: native doar **4096 tokeni** (nu 8192 cum arăta default-ul llama.cpp la load, nici 32K cum sugera raportul tehnic — aia e doar la 9B/22B, extins prin RoPE scaling). Testate două alternative Qwen3.5 (context nativ 262144 pe toată familia, GGUF oficial `unsloth/Qwen3.5-*-GGUF`, aceeași baterie de 3 prompturi RO):
### Qwen3.5-0.8B (Q4_K_M, 508MB)
- Comprehension: corect ("portofelul").
- Conversațional: fluent gramatical, dar greșește calculul zilei ("Luni → Duminică" — greșit, corect ar fi marți).
- **Factual: eșec grav** — "Care este capitala Franței?" → "Capoala Franței este București." (halucinație completă, confundă țara).
- Viteză: ~32 tok/s generare, cel mai rapid dintre cele testate.
### Qwen3.5-2B (Q4_K_M, 1.2GB) — **cel mai bun rezultat până acum**
- Factual: "Capitala Franței este Paris." — corect.
- Comprehension: "portofel" — corect semantic (fără articol hotărât).
- Conversațional: fluent, dar aceeași greșeală de calcul zi ("Luni → Duminică") — pattern comun tuturor modelelor mici testate (LFM2.5 nu a ajuns până aici, EuroLLM a zis "miercuri", Qwen3.5-0.8B și 2B au zis "duminică"), pare limitare generică de raționament la scară mică, nu problemă specifică românei.
- Context nativ: 262144 tokeni.
- Viteză: load 3-11s (cold/warm), generare ~17 tok/s, sub 4s pentru răspunsuri normale.
- **Disponibil direct în biblioteca oficială Ollama**: `ollama pull qwen3.5:2b` (2.7GB, tag oficial, 256K context) — zero setup manual de GGUF/Modelfile, spre deosebire de EuroLLM care ar necesita import manual.
### Corecție infrastructură — Ollama nu e pe LXC 104
Marius a presupus Ollama pe LXC 104 (`10.0.20.104`), dar `config.json → ollama.url` arată **`http://10.0.20.161:11434`** — deja folosit pentru embeddings (`nomic-embed-text`) și are câteva modele mici instalate (`llama3.2:3b`, `llava:7b`, `smollm:135m`). Ținta reală de deploy pentru fallback e `.161`, nu `.104`.
**Concluzie provizorie:** `qwen3.5:2b` via Ollama pe `10.0.20.161` e candidatul recomandat pentru fallback conversațional RO — precizie factuală comparabilă cu EuroLLM-1.7B, context 64x mai mare, deja disponibil fără import manual. Integrarea în `router.py`/`claude_session.py` (detectare rate-limit + apel către Ollama) e pas separat, nefăcut încă.