Analizza la seguente descrizione tecnica, determina gli erro...

Prompt

Analizza la seguente descrizione tecnica, determina gli errori che sono stati fatti nelle scelte progettuali, i limiti della attuale soluzione, cosa potrebbe impedire il successo della attuale applicazione con particolare focus sull'utente finale. il punto di forza della applicazione deve essere reattività, memoria rispetto a quello che l'utente ha raccontato nelle sedute precedenti e ai materiali forniti e capacità di creazione di un percorso psicoterapeutico efficace identificando nel tempo le caratteristiche psicologiche dell'utente, e facilità di uso. Lo scenario frustrante da evitare assolutamente è l'utente che parla di un evento che ha già condiviso e la AI non ha memoria di tale evento. # Descrizione Tecnica V2 — "Il tuo terapeuta" (your-ai-therapist) > Analisi prodotto per un modello di IA valutatore: logica di business senza > riferimenti al codice, con focus su **usabilità e lentezza**. Stato: > ristrutturazione completata e deploy in produzione. --- ## 1. Sintesi esecutiva App mobile/web (PWA installabile) di supporto psicologico basata su un agente LLM con **memoria terapeutica personale, persistente e controllabile**, interamente sul dispositivo: - conversazione in italiano secondo una scuola terapeutica (CBT, DBT, Psicodinamico, Umanistico, Sistemico, Integrativo) con protocollo di sicurezza clinica (crisi, numeri di emergenza, giurisdizione Italia); - **memoria a due velocità**: *estrazione immediata* post-risposta (persone, fatti, preferenze, impegni, temi, richieste esplicite) con feedback "Ho ricordato N elementi" e azioni Vedi/Correggi/Non ricordare/Importante; *consolidamento periodico* con belief revision (CREATE/EXTEND/STRENGTHEN/ WEAKEN/CONTRADICT/RETIRE) e quadro "Dove sono ora"; - l'utente corregge/elimina/importante/esclude ogni elemento, vede la **fonte** (messaggio originale), filtra la timeline ed **esporta un riepilogo Markdown** per un terapeuta umano; - file (chat WhatsApp, testi) allegati **nei messaggi**, indicizzati in locale e interrogati dall'agente senza lettura integrale. Vincoli: **nessun backend dati** (solo Firebase Hosting + Cloud Function proxy); **bring-your-own-key** (chiave API OpenCode Go dell'utente); **modello unico** `deepseek-v4-flash` per tutti i task; **solo-locale dichiarato** (nessun sync, elaborazione solo ad app aperta). --- ## 2. Piattaforme, stack, infrastruttura React 19 + TypeScript + Vite 8 + CSS custom (tema chiaro caldo); Capacitor 8 (Android/iOS); SQLite via `@capacitor-community/sqlite` (nativo / wa-sqlite WASM su web); AI SDK v7 (`ToolLoopAgent`); Firebase Hosting + Cloud Functions 2nd gen; lingua solo italiana. **Flusso LLM (CORS)**: web dev = proxy Vite (streaming reale); web prod e mobile = **Cloud Function 2nd gen** che inoltra a `opencode.ai/zen/go/*` con la chiave del chiamante e **rilascia i chunk progressivamente** (verificato: 79 eventi SSE sulla funzione deployata); mobile senza CapacitorHttp (fetch nativo della WebView — verifica su device fisico pendente, rischio bufferizzazione iOS). La versione web prod dipende dal piano Blaze (billing) del progetto. --- ## 3. Architettura dati (SQLite) Un database versionato (migrazioni idempotenti) con: **conversations** (sedute, riassunto progressivo versionato), **messages** (solo testi, mai tracce tool), **memories** (tipo, confidenza alta/media/bassa, stato attiva/storica/corretta, importante/escluso, provenienza), **people** (ruolo, importanza 0–3), **attachments + attachment_blocks** (testo diviso in blocchi da 40K caratteri), **timeline**, **settings** (quadro, stato consolidamento), **jobs**, **audit**. Markdown solo come formato di esportazione. Ricerca **LIKE** su web (la build sql.js 1.12 non ha FTS5); FTS5 nativo disponibile ma inutilizzato. Operazioni DB **serializzate** (il layer web del plugin non è concorrenza-safe) e snapshot web **persistito esplicitamente** dopo ogni transazione. --- ## 4. Flusso d'uso **Onboarding (2 passi)**: (1) nome · "cosa cerchi" (chip: ansia/stress, relazioni, autostima, lavoro, sonno, umore, solo ascolto) · stile (*esercizi concreti*→CBT, *esplorare emozioni*→psicodinamico, *misto*→integrativo) · consenso; (2) API key + test connessione (chiamata minima; la lista modelli è solo informativa) + endpoint "avanzato". Senza chiave: gate amichevole verso Impostazioni. La scuola resta modificabile nelle Impostazioni. **Seduta (chat)**: composer con allegati (graffetta .txt, incolla testo, drag&drop web) e scelta **intenzione** (*Usalo per questa domanda / Ricordalo anche in futuro / Fammi prima un riepilogo*). File elaborato in background: parsing in Web Worker, indicizzazione a blocchi con stati onesti ("Ricevuto: puoi già farmi domande sul file" → "Sto preparando la ricerca completa…" → "Ricerca pronta"); l'analisi vera avviene dopo i turni, non al caricamento. Turno con **contesto ridotto**: riassunto progressivo + finestra 12 scambi + ricordi pertinenti + passaggi da sedute concluse (14 giorni) + contesto compatto degli allegati, tutto fuso nelle **istruzioni** (il provider rifiuta system nei messages). **14 strumenti** (memoria, persone, allegati, timeline); tool-loop: stop a 2 passi se l'ultimo ha testo, tetto 6. Feedback streaming "sto pensando…" → "sto riflettendo…" (reasoning) → testo; attività per strumento; **stato del turno fuori dal componente** (cambiando tab il feedback e i segmenti in corso sopravvivono); retry max 2 solo transitori e senza output; errori chiari con coda grezza per diagnosi. Feedback memoria post-turno: "Ho ricordato N elementi" con Vedi/Correggi/Non ricordare/Importante (la correzione modifica contenuto e confidenza). **Concludi seduta**: evento timeline + nuova seduta + consolidamento in background; auto-separazione dopo 12h di inattività. **Il mio percorso**: Dove sono ora (quadro + "Aggiorna il quadro"), Persone importanti, Cose che voglio ricordare, Temi ricorrenti, Ricordi, Timeline filtrabile; azioni Correggi/Importante/Non ricordare/Elimina/Fonte; "Riepilogo per il terapeuta" (export Markdown). **Impostazioni**: utilizzo abbonamento (rolling/settimanale/mensile con reset), Avanzate collassate (endpoint/chiave/test), Privacy (solo-locale dichiarato), Allegati e dati (stati, elimina), Backup v2 (dump JSON di tutte le tabelle, restore integrale), Stato dati (conteggi memoria/persone/eventi), Azzera tutto (drop database + reset impostazioni). --- ## 5. Logiche del terapeuta **Agente**: system prompt stratificato a prefisso stabile + contesto dinamico per-turno nelle istruzioni; brevità ≤150 parole; consultazione mirata; distinzione fatto/ipotesi; consenso prima di registrare; **registrazione automatica vietata in chat** (la fa il background); allegati mai letti per intero (ricerca a livelli). **Memoria a due velocità**: estrazione immediata (una chiamata strutturata leggera sugli **ultimi 5 scambi**, con provenienza; correzioni utente immediate); consolidamento periodico (una chiamata strutturata con belief revision + persone + eventi + quadro; trigger: 25 messaggi, inattività ≥4h, apertura percorso, manuale, conclusione seduta; fallimento → ritentato al trigger successivo, senza blocco). Il feedback memoria è visibile in chat e sopravvive al cambio tab; i contenuti della memoria sono consultabili e controllabili in "Il mio percorso". **Continuità tra sedute**: retrieval anche sui **messaggi delle sedute concluse** (14 giorni, attiva esclusa) — "di chi parlavo ieri?" trova i passaggi reali prima che le memorie siano estratte. --- ## 6. Sicurezza e privacy Dati solo sul device; chiave utente normalizzata, mai loggata; audit; protocollo di crisi (Italia); anti prompt-injection (memoria = dati, non istruzioni); disclaimer clinico. Limiti dichiarati: elaborazione solo ad app aperta, nessun sync; la privacy dipende dal provider scelto. --- ## 7. Parametri operativi | Parametro | Valore | |---|---| | Modello (tutti i task) | deepseek-v4-flash (OpenCode Go, BYO key) | | Temperatura / output max chat | 0.6 / 2048 token | | Tool-loop | 2 passi se c'è testo; tetto 6 | | Contesto | 12 scambi + riassunto (ogni 8 msg) + retrieval (6 ricordi + 4 passaggi, 14 gg) | | Blocco allegato | 40.000 caratteri | | Separazione sedute | 12h inattività | | Consolidamento | 25 msg / 4h / apertura percorso / manuale / conclusione | | Retry chat | max 2, transitori, senza output | | Retrieval messaggi | 300 msg utente, 14 giorni | --- ## 8. Performance misurate (reali) - Streaming proxy web prod: 79 eventi SSE incrementali, 200 OK; `text/event-stream`, chunk progressivi verificati. - **TTFT**: ~5,6s (web prod, saluto), 6–8s dev, **33,5s con allegato**; casi estremi ~46s. Dominato dal **reasoning** del modello (~95% dei byte ricevuti è reasoning, non testo; fino a 37–50KB per turno). - Turno tipico: **1–3 round-trip LLM** (consultazione → risposta → estrazione); ogni passo del loop è una generazione completa con reasoning. Estrazione = 1 chiamata post-turno; consolidamento = 1 chiamata a trigger; il riassunto progressivo è aggiornato ogni 8 messaggi (chiamata leggera non bloccante). --- ## 9. Limiti attuali — usabilità e tecnologia ### 9.1 Lentezza percepita (priorità) 1. **TTFT dominato dal reasoning** (6–46s): il gateway ignora `reasoning_effort`; "sto riflettendo…" rende visibile la fase ma senza progresso né stima del tempo; il budget target <2s **non è rispettato** ed è irraggiungibile col modello attuale. 2. **Turni multi-step amplificano la latenza**: ogni tool-call è una generazione con reasoning; con allegati più passi (33s+ misurati); il tetto di 6 passi può interrompere analisi articolate senza testo. 3. **~95% dei token è reasoning "sprecato"**: nessun tetto configurabile; consumi imprevedibili (l'indicatore di utilizzo mitiga ma non previene). 4. **Background aggiunge chiamate**: estrazione post-turno (non blocca), ma consolidamento su conclusione/apertura percorso con UI solo "Aggiorno…". 5. **Streaming mobile non verificato su device**: se la WebView iOS bufferizza, si torna a latenza totale senza feedback incrementale. ### 9.2 Usabilità 1. **BYO key**: barriera per l'utente medio; errori comuni (chiave rifiutata, crediti esauriti, abbonamento senza entitlement) gestiti con messaggi chiari ma presenti. 2. **Solo-locale**: memoria aggiornata solo ad app aperta; nessuna continuità tra dispositivi (il backup manuale è l'unico ponte). 3. **Stati opachi**: consolidamento fallito si ritenta in silenzio senza avviso; allegato "sospeso"/"errore" con riprova non implementata nell'UI (solo elimina). 4. **Correzione memoria**: senza "annulla"/storico versioni; ruolo della persona modificabile solo tramite l'agente; la "fonte" è consultabile ma non navigabile fino al messaggio nel contesto. 5. **Allegati**: solo .txt (niente PDF/immagini, niente share-intent mobile); file grandi caricati interamente per il parsing (il worker evita il blocco UI, ma il costo esiste); nessun avviso dimensionale nel nuovo flusso. 6. **Check-in statico** (frasi dal percorso, senza LLM): non adattivo al contesto reale della giornata. 7. **Errori "tecnici" visibili all'utente**: la coda grezza della risposta nel messaggio d'errore è utile alla diagnosi ma poco comprensibile. ### 9.3 Tecnologia 1. **Ricerca LIKE senza FTS5 su web** (corrispondenze letterali); FTS5 nativo inutilizzato (tabelle FTS presenti nello schema). 2. **Retrieval a soglie fisse**: 14 giorni, 300 messaggi, nessuna semantica/embedding; le memorie più vecchie sono raggiungibili solo dagli strumenti dell'agente (search_memory), non dal retrieval automatico. 3. **Layer web del plugin SQLite non concorrenza-safe** (mitigato da serializzazione); persistenza esplicita dello store dopo ogni transazione (requisito fragile: senza, un reload perde i dati recenti). 4. **Dipendenza dalla Cloud Function** (piano Blaze): se scade il billing, il default non funziona sul web; endpoint custom richiedono CORS proprio. 5. **Tetto tool-loop 6**: analisi articolate possono interrompersi senza testo → "Nessuna risposta generata" (mitigato dal prompt, rischio residuo). 6. **Errori di estrazione/consolidamento silenziosi** (nessun retry immediato, nessuna visibilità all'utente). 7. **Scalabilità locale**: liste senza paginazione UI; backup con blocchi testuali può crescere molto; i blocchi duplicano il testo dell'allegato (nessuna deduplicazione/compressione). ### 9.4 Budget non rispettati - primo contenuto <2s: **non rispettato** (6–46s); - ≥90% turni con ≤1 chiamata: **parziale** (saluti 1; allegato/continuità 2–3); - nessun blocco UI >100ms: rispettato (worker + indicizzazione a blocchi). --- ## 10. Cosa valutare (sintesi) 1. **Latenza del reasoning**: riportare il TTFT sotto i 2–4s senza cambiare modello (reasoning disattivabile nei turni semplici, modello "flash senza reasoning" in chat e deepseek nel background, prima bozza in parallelo, cache del prompt già parzialmente sfruttata dal prefisso stabile). 2. **Costo del reasoning** (~95% dei token): prompt più secchi, finestre più piccole, tetti di completamento, contatore di consumo per turno. 3. **Trasparenza del background**: stato/retry/visibilità di estrazione e consolidamento falliti; notifiche quando tecnicamente possibile. 4. **Retrieval**: FTS5 nativo, soglie di recenza, semantica leggera; impatto sulla continuità tra sedute e sulla qualità delle risposte. 5. **Onboarding/chiave**: ridurre l'attrito BYO (demo/ospite, istruzioni guidate, diagnosi degli errori comuni). 6. **Streaming mobile**: verifica su device e fallback (plugin nativo URLSession/OkHttp) se la WebView bufferizza. 7. **Scalabilità locale**: paginazione, dimensione backup, archiviazione e compressione dei blocchi. Distinguere limiti **architetturali** (modello con reasoning, assenza backend, solo-locale), **implementativi** (LIKE, soglie fisse, stati silenziosi, paginazione) e **di prodotto** (BYO key, .txt only, nessun sync), con priorità di intervento e impatto stimato su usabilità e costi.