LatticeDB samler grafsøk, vektorsøk og fulltekst i én fil

Den som bygger agent-minne lokalt ender ofte med tre systemer ved siden av hverandre: en vektordatabase for likhetssøk, en grafstruktur for relasjoner og en egen indeks for tekst. LatticeDB, et open source-prosjekt skrevet i Zig, legger alle tre i samme motor og samme spørrespråk. Hele databasen er én portabel fil, uten server og uten konfigurasjon. Prosjektet ble lagt ut som Show HN 25. august og har fått 156 poeng og 41 kommentarer.

Poenget er at du skriver én MATCH-spørring som traverserer relasjoner, filtrerer på vektoravstand og gjør tekstmatch i samme kall, i stedet for å sy sammen tre resultatsett i applikasjonskoden. Dokumentasjonen oppgir 0,13 mikrosekunder for nodeoppslag og 0,83 millisekunder for vektorsøk mot én million vektorer med 100 prosent recall. HNSW dekker vektorsiden, BM25 dekker teksten.

Utvikleren er tydelig på hva prosjektet er ment for.

«En av motivasjonene for meg var å eksperimentere med agent-minne. Jeg bruker latticedb som datalager, og å finne relaterte minner er å traversere grafen.» — utvikleren bak LatticeDB, i Show HN-tråden

Tråden ga også prosjektet en test det ikke hadde bedt om. Vedlikeholderen av LadybugDB kjørte en sammenligning mot SQLite på en M4 Mac mini med 100 000 noder, der ett hopp tok 5,7 mikrosekunder mot SQLites 16,1, mens en variabel sti på ett til fem hopp tok 82,2 mikrosekunder mot 5,8 millisekunder. Samme utvikler understreket at systemene er ulike nok til at metodikken ikke uten videre er sammenlignbar.

Den viktigste begrensningen kom fram i samme tråd. På spørsmål om samtidige skrivere svarte utvikleren at låsing håndheves inne i prosessen, men at det ikke fantes noen mekanisme for sikkerhet på tvers av prosesser, og at en fillås ville komme samme kveld. Designmålet er én skriver og flere lesere. Det er en rimelig avgrensning for agent-minne som lever i én prosess, men det utelukker at flere tjenester deler filen direkte.

En felle til er verdt å kjenne før du måler treffkvalitet: eksemplene bruker en innebygd hash_embed-hjelper som er en deterministisk plassholder, ikke en semantisk embedding. Lignende tekst gir ikke nærliggende vektorer, så en avstandsterskel blir vilkårlig og et likhetssøk kan matche ingenting.

Bindingene dekker CLI, Python, TypeScript og Go, med pip install latticedb og npm-pakken @hajewski/latticedb. Lisensen er MIT.

Hva bør du gjøre?

1. Bytt ut hash_embed med en ekte embedding-modell før du vurderer om treffene er gode. Plassholderen produserer tall som ser ut som semantikk uten å være det.
2. Sjekk skrivemodellen mot arkitekturen din. Én skrivende prosess betyr at to tjenester ikke kan dele samme fil, og fillåsing på tvers av prosesser er helt fersk.
3. Mål på ditt eget datasett. Tallene i dokumentasjonen er prosjektets egne, og den eneste uavhengige målingen i tråden kom fra en konkurrerende vedlikeholder.