Heritage Playground

Chatbot

Sistema

Playground pronto. Scegli una modalita, insegna qualcosa al sistema e poi confronta la risposta con e senza memoria.

Messaggio

Come provarlo

`Insegna` salva una regola.
`Chat stateless` la ignora.
`Chat con memoria` prova a recuperarla.

Stack

VPS OVH + Docker.
API REST per chat e memoria vettoriale.
Laravel come backend API.
Sanctum per i token utente.
API key server-to-server per il playground.
Ollama `qwen2.5:1.5b` per la generation.
Ollama `nomic-embed-text` per gli embeddings.
Qdrant per retrieval semantico.
MySQL per record applicativi, metadata e scope.

Embeddings

Sono rappresentazioni numeriche del testo. Nel nostro stack Ollama usa `nomic-embed-text` per trasformare una frase in un vettore, cioe un array di numeri che rappresenta il significato della frase e non la forma esatta delle parole.

Retrieval semantico

E una ricerca per significato e non per parola esatta. La query dell utente viene convertita in embedding, Qdrant confronta quel vettore con i vettori salvati e restituisce le memorie piu vicine. Il backend prende quelle memorie e le aggiunge al contesto prima di chiamare il modello chat.

Metadata e scope MySQL

MySQL salva il record applicativo della memoria: titolo, tag, sorgente, stato attivo, collegamento al vettore (`vector_point_id`) e scope logico (`global`, `user`, ecc.). In pratica MySQL tiene le regole di gestione della memoria, mentre Qdrant tiene l indice vettoriale per la similarity search.

Esempio concreto

Se salvi la regola “Nel playground Heritage devi sempre rispondere in italiano”, il backend salva due cose. In MySQL salva il record memoria con scope `global`, titolo, tag, stato e id del vettore. In Qdrant salva il vettore numerico del contenuto. Quando poi chiedi “In che lingua devi rispondere?”, il backend genera l embedding della domanda, Qdrant trova la memoria semanticamente piu vicina e MySQL aiuta a capire se quella memoria esiste, e attiva e in quale scope puo essere usata.

in soldoni

Qdrant trova cosa e simile. MySQL governa quali memorie esistono, in che stato sono e in quale scope valgono.

Isolamento per Utente: Il campo user_id è presente nei $fillable. Questo significa che ogni record di memoria è legato a un utente specifico.
Gestione dello Scope: La presenza dei campi scope e scope_key permette di suddividere ulteriormente la memoria. Se lo scope non è global, il chatbot utilizzerà solo i dati legati a quell'utente e a quella specifica chiave di contesto (es. una specifica chat o un progetto).
Memoria Vettoriale: Il campo vector_point_id suggerisce che il sistema si interfacci con un database vettoriale. Anche in questo caso, l'ID dell'utente funge da filtro primario per recuperare solo i ricordi pertinenti.

Grazie a questo layer su MySQL, il sistema è in grado di creare un'esperienza di chatbot "privata" e personalizzata per ogni utente loggato. Ogni utente "popola" il proprio set di dati in AiMemory senza interferire con gli altri, a meno che non venga esplicitamente usato uno scope globale.

{ "status": "waiting" }