🚀 DEV UPDATE — MyZubster MVP: Local AI + RAG Knowledge Pipeline
Oggi ho completato un nuovo step del mio progetto MyZubster MVP / N4K48: un sistema AI locale che può interrogare le osservazioni del progetto e una knowledge base versionata su GitHub.
🔗 Repository
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
🔗 Commit del nuovo RAG
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/commit/8da7435ddc1b9ae8b2f5c2eea5debd2df4bc5f47
Come funziona
La pipeline locale è:
Knowledge / Observations → Embeddings → Qdrant → Retrieval → Ollama → Mistral → risposta con fonti
Il progetto usa:
- Ollama per eseguire i modelli AI localmente;
- nomic-embed-text per trasformare documenti e domande in embedding;
- Qdrant come vector database;
- Mistral per generare la risposta finale;
- Flask API come livello applicativo;
- Docker Compose per orchestrare API, Qdrant, Ollama e Open WebUI.
Cosa abbiamo cambiato
Prima, ogni domanda inviata all'AI poteva causare una nuova indicizzazione delle osservazioni.
Ora abbiamo separato le due responsabilità:
WRITE
create observation → persist → embed → index in Qdrant
READ / ASK
question → embed question → search Qdrant → retrieve context → Mistral → answer
Questo evita di re-indicizzare tutto a ogni domanda e rende il RAG più vicino a una vera architettura di retrieval.
Knowledge Base
Ho aggiunto anche una knowledge base Markdown versionata direttamente nel repository:
knowledge/N4K48.md
knowledge/ROADMAP.md
knowledge/ZORGAX.md
knowledge/GALLERY.md
knowledge/PROFILE.md
knowledge/README.md
Uno script dedicato:
scripts/ingest_knowledge.py
divide i documenti in chunk, genera embedding locali e li registra in Qdrant usando ID deterministici.
Nel test attuale:
38 knowledge chunks + 4 observations = 42 vector points
Test
La suite locale è passata:
25/25 tests ✅
Abbiamo poi eseguito una vera richiesta RAG:
“Qual è lo stato del collegamento tra Nicola Comics e il Zorgax pubblico?”
Risultato:
HTTP 200 — 80.75 secondi
Il sistema ha recuperato informazioni dalla knowledge base e ha correttamente mantenuto un confine importante: il collegamento pubblico Zorgax end-to-end non è ancora verificato.
Il retrieval in questo test ha selezionato due chunk di ROADMAP.md invece di ZORGAX.md: quindi il prossimo lavoro sarà migliorare ranking, chunking e pertinenza delle fonti, oltre alle prestazioni del modello locale.
Evidence first
Una regola importante del progetto resta:
concept ≠ evidence
Un elemento viene dichiarato verificato solo quando esiste una prova tecnica concreta: test, commit, runtime, osservazione o altra evidenza controllabile.
Per esempio, Nicola Comics può avere una tavola nello stato NFT_CANDIDATE, ma questo non significa che sia stata mintata. Allo stesso modo, l'adapter Zorgax locale esiste, ma il collegamento con il Zorgax pubblico deve ancora essere provato end-to-end.
Next
I prossimi step sono:
better retrieval → smaller/faster context → Zorgax-specific retrieval → public E2E verification
L'obiettivo è costruire progressivamente un assistente MyZubster capace di lavorare sulle informazioni reali del progetto, mantenendo separate visione, storytelling e prove tecniche.
🔗 MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
🔗 N4K48 knowledge
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/knowledge
🔗 RAG ingestion script
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/scripts/ingest_knowledge.py
