Nish dice che i modelli già fanno quasi tutto, ma senza contesto utile restano bloccati. Per questo HydraDB prova a sostituire i vector database con un’infrastruttura che preservi relazioni, rilevanza e memoria per gli agenti AI.
Quando Nish racconta HydraDB, la tesi arriva subito: i modelli sono già abbastanza intelligenti, il collo di bottiglia è il contesto. Per lui il problema non è far parlare l’AI con più dati, ma farle riconoscere quali dati contano davvero, in quel momento e per quel compito. È da lì che nasce la sua guerra ai vector database, accusati di restituire somiglianza quando servirebbe rilevanza. E da lì nasce anche il suo pitch, ridotto a tre parole che, a suo dire, hanno cambiato la traiettoria della startup: “vector databases suck”.
Nish apre con un’idea semplice: i modelli hanno già raggiunto un livello in cui possono fare, dice, il 90% del lavoro umano, ma senza il contesto giusto restano inutili in produzione. HydraDB, in questa lettura, non è una memoria applicativa, ma l’infrastruttura che permette agli agenti di diventare stateful.
I modelli sono arrivati a un punto in cui possono fare il 90% del lavoro che fanno gli esseri umani. Il più grande collo di bottiglia in ogni forma di capacità AI è il contesto con cui stanno lavorando.
Non siamo un’applicazione di memoria. Siamo l’infrastruttura che abilita le app di memoria.
La distinzione per lui è centrale, perché sposta il valore dal prodotto visibile alla struttura sotto il cofano. Invece di vendere una nuova interfaccia, HydraDB vuole offrire il livello che fa da ponte tra dati non strutturati, come Notion, Gmail, Slack, PDF e fatture, e gli agenti che devono usarli in produzione.*
Vogliamo rendere l’AI stateful, così che l’agente possa operare davvero con il contesto non strutturato.
Il suo percorso parte a Stanford, dove lavorava a un progetto di ricerca su motori di ricerca per modalità diverse, come gli oggetti 3D, e porta poi a Finder, un’app che cercava in tutte le applicazioni dell’utente con una barra unica. Quell’esperienza gli ha mostrato sia la domanda reale sia il limite del prodotto come interfaccia.
Stavamo costruendo motori di ricerca per modalità diverse, oggetti 3D per esempio. Da quel lavoro è nata l’idea di un’unica barra di ricerca che cercasse in tutte le applicazioni.
L’idea era che un’interfaccia unica potesse cercare su Gmail, Slack e tutto il resto. Poi ci siamo resi conto che c’è un tetto naturale su come le persone vogliono consumare le applicazioni.
Finder ha funzionato, almeno in termini di trazione, ma proprio il successo ha aperto la domanda successiva. Nish dice che la parte più utile non era la barra di ricerca, bensì l’infrastruttura che rendeva accessibile il contesto dietro quella ricerca. Da lì il salto verso HydraDB, che non espone una UI ma API e SDK.*
Alla fine abbiamo capito che il valore più grande stava nell’abilità sottostante di sbloccare il contesto dalle applicazioni di lavoro.
La critica più forte di Nish è contro i vector database, che secondo lui restituiscono risultati simili ma non pertinenti. Il punto non è accademico, dice, ma pratico: in enterprise, confondere somiglianza e rilevanza significa sbagliare il documento, l’azione o la decisione giusta.
Similarity is not relevance. La somiglianza non è rilevanza.
Se dico la parola Apple, puoi pensare al frutto. Ma io stavo parlando della società Apple.
HydraDB, nella sua versione ideale, costruisce indici basati su ontologie, non su una griglia piatta di vettori. Nish sostiene che i dati aziendali non siano un archivio monodimensionale, ma un insieme di relazioni, tempi e dipendenze che un sistema deve preservare invece di appiattire.*
Un vector DB crea un indice piatto di tutti i documenti. Distrugge le relazioni e non ricorda perché un pezzo di contesto è importante.
Nish descrive anche il momento in cui la startup ha capito che il problema non era solo tecnico. Con un messaggio troppo vago, racconta, avevano centinaia di visite al sito e nessuna registrazione; con una frase brutale, “vector databases suck”, hanno iniziato a ricevere richieste di demo.
Avevamo tra le 500 e le 1.000 persone che visitavano il sito e letteralmente nessuno si iscriveva.
Abbiamo trovato questa tagline, “vector databases suck”. E la gente diceva: “Hai ragione”.
La lezione, per Nish, è che il prodotto migliore non vince se il vantaggio non è comunicato in modo comprensibile. Il sito iniziale, dice, era troppo tecnico; il nuovo messaggio era aggressivo ma leggibile, abbastanza da far capire a chi aveva già sentito il limite dei vector database che HydraDB stava parlando proprio del loro problema.*
Puoi avere il prodotto migliore del mondo, ma se non sai comunicare i benefici, nessuno lo userà.
Un’altra frattura che Nish insiste a descrivere è quella tra demo e produzione. Molti team, dice, credono di aver costruito un sistema AI quando hanno caricato un PDF in un modello e mostrato una prova brillante; poi scoprono che il vero problema è gestire milioni di documenti e recuperare il contesto giusto in modo affidabile.
Per un team, il PoC significa caricare un PDF in Claude o Gemini. Ma un sistema in produzione significa milioni di PDF.
Molte aziende hanno cercato di produrre AI per un anno e mezzo e non hanno ancora un singolo agente in funzione.
Nish cita anche una statistica di MIT, dicendo però di averla usata più come elemento retorico che come prova scientifica. Il punto che difende è più ampio: se il sistema deve gestire un corpus enorme, il collo di bottiglia diventa il retrieval, non il modello in sé.*
Non puoi digerire tutto quel contesto in una singola chiamata a un LLM.
HydraDB, nella visione di Nish, vive accanto a strumenti di integrazione come Composio, non al loro posto. Lui distingue tra il livello che collega gli agenti agli strumenti e quello che restituisce il contesto giusto da quegli strumenti, e dice che i due pezzi devono lavorare insieme.
Noi non siamo un’azienda di integrazioni. Quello è un problema diverso.
Composio gestisce il collegamento degli agenti agli strumenti. HydraDB fa in modo che il contesto giusto torni indietro da quegli strumenti.
Quando descrive la pila ideale di un’azienda AI, Nish la divide in quattro livelli: osservabilità, integrazioni, gestione del contesto e, infine, modelli più piccoli, fine-tuned per il caso d’uso specifico. Qui introduce anche una tesi pratica, secondo cui per molti casi d’uso gli SLM sono più utili di un modello enorme sparato su ogni problema.*
Per molti casi d’uso, gli SLM sono molto più potenti che lanciare il modello più forte su ogni problema.
L’ultima parte della conversazione guarda al futuro della stessa HydraDB. Nish immagina un mondo diviso in due: modelli grandi nei data center per i problemi complessi, modelli piccoli ed edge sui telefoni, ma in entrambi i casi serve contesto. Il suo obiettivo è portare quel contesto più vicino possibile al dispositivo, fino a renderlo locale.
Penso che il futuro dei modelli sia diviso in due metà, modelli grandi nei data center e modelli più piccoli e veloci sui telefoni.
Una futura versione di HydraDB potrebbe girare localmente sul telefono, così che i dati non escano mai dal dispositivo.
Qui il tema non è più solo il retrieval per agenti enterprise, ma un’infrastruttura di contesto personale, capace di leggere messaggi, foto e informazioni locali senza spostare i dati su un server. Nish la presenta come una scommessa tecnica e di prodotto insieme: un layer piccolo, rapido e sicuro, abbastanza per unire utilità e privacy.*
Se riuscissimo a portare il contesto localmente su questi dispositivi, potremmo essere vicini a risolvere un problema reale per molte aziende AI.
Che cos’è HydraDB in una frase?
HydraDB è l’infrastruttura che aiuta gli agenti AI a recuperare il contesto giusto dai dati non strutturati. Nish la descrive come un layer per rendere l’AI davvero stateful.
Perché Nish critica i vector database?
Secondo Nish, i vector database restituiscono somiglianza ma non rilevanza. Nel suo esempio, “Apple” può voler dire il frutto o la società, e il sistema deve capire quale dei due contesti serve.
Perché il messaggio “vector databases suck” ha funzionato?
Per Nish ha funzionato perché era immediato e parlava un problema già sentito da molti team. Prima il sito era troppo tecnico, dopo la nuova tagline sono arrivate più richieste di demo.
HydraDB è una memory app?
No, Nish dice che non è un’applicazione di memoria ma l’infrastruttura che permette di costruirne. Il punto è offrire il livello sottostante, non l’interfaccia finale.
Qual è il futuro che Nish immagina per il prodotto?
Nish immagina un HydraDB locale, capace di girare sul telefono e tenere i dati sul dispositivo. La sua idea è che il contesto debba essere più vicino possibile all’utente, non solo al cloud.
Sintesi assistita dall'AI del podcast di Composio, verificata sulla trascrizione originale.