MemPalace sai 96,6 % tuloksen LongMemEval-testissä. Ajoimme saman vertailun. Strukturoitu ekstraktio sai korkeamman tuloksen.

Viraali väite: raaka sanatarkka tallennus voittaa kaiken tekoälyn muistissa. Toistimme vertailun ja löysimme toisenlaisen vastauksen. Pullonkaula on upotuksen katkaisu, ei ekstraktion aiheuttama tietohäviö. Tässä on data.

---

Miksi ajoimme tämän vertailun

MemPalace (github.com/milla-jovovich/mempalace) julkaistiin 5. huhtikuuta 2026 ja saavutti 14 500 GitHub-tähteä 48 tunnissa. Perusväite: tallenna jokainen keskustelu sanatarkasti ChromaDB:hen, jätä LLM-ekstraktio kokonaan pois, ja saat 96,6 % palautuvuuden tekoälyn muistin vakiovertailussa (LongMemEval).

Väitteen seuraus alalle: jokainen järjestelmä, joka käyttää LLM:ää muistojen ekstraktointiin tai tiivistämiseen, ratkaisee ongelmaa liian monimutkaisesti. Raaka teksti hyvillä upotuksilla voittaa.

Rakennamme tiedonhallintajärjestelmiä SECI-mallin pohjalta (Nonaka & Takeuchi, 1995), jossa strukturoitu ekstraktio on ydintoiminto. Jos raaka tallennus todella voittaa ekstraktion, arkkitehtuurimme on väärä. Siksi testasimme sen.

---

Mitä testasimme

Vertailu: LongMemEval_S (Wu ym., ICLR 2025). 500 kysymystä, jotka mittaavat viittä pitkäaikaisen muistin kykyä: tiedon ekstraktiota, monen istunnon päättelyä, tiedon päivityksiä, ajallista päättelyä ja pidättäytymistä. Jokaiseen kysymykseen liittyy noin 48 "heinäsuova"-keskusteluistuntoa, joista 1-3 sisältää vastauksen.

Neljä hakumenetelmää, sama upotusmalli (all-MiniLM-L6-v2), sama data:

#	Menetelmä	Kuvaus
1	Raaka kaikki vuorot	Tallenna koko istunnon teksti (käyttäjä + assistentti), upota sellaisenaan
2	Raaka vain käyttäjä	MemPalacen menetelmä: tallenna vain käyttäjän vuorot, upota sellaisenaan
3	SECI-ekstraktio	Tiivistä jokainen istunto noin 500 merkkiin strukturoituja faktoja
4	SECI-hybridi + avainsana	Yhdistä raa'at ja ekstraktoidut pisteet käänteisellä sijalukusummauksella (RRF), lisää avainsanapäällekkäisyyden korotus

Kaikki menetelmät käyttävät ChromaDB:tä kosinisamankaltaisuushaulla. Haussa ei käytetä LLM:ää. Ainoa ero on se, mitä indeksoidaan.

---

Tulokset

LongMemEval_S: istuntotason haku (500 kysymystä, kaikki 6 tyyppiä)

Menetelmä	R@5	R@10	NDCG@5	NDCG@10
Raaka kaikki vuorot	85,9 %	92,8 %	80,3 %	83,0 %
Raaka vain käyttäjä (MemPalacen menetelmä)	92,1 %	96,3 %	86,8 %	88,5 %
SECI-ekstraktio	93,7 %	96,7 %	89,1 %	90,3 %
SECI-hybridi + avainsana	93,9 %	96,6 %	89,7 %	90,8 %

SECI-hybridi voitti MemPalace-tyylisen raa'an tallennuksen 1,8 prosenttiyksiköllä R@5-mittarilla.

Erittely kysymystyypeittäin

Menetelmä	Tiedon päivitys (n=72)	Monen istunnon (n=121)	SS-käyttäjä (n=64)	Ajallinen (n=127)
Raaka vain käyttäjä (MemPalace)	98,6 %	90,6 %	92,2 %	86,9 %
SECI-ekstraktio	95,8 %	93,2 %	96,9 %	88,8 %
SECI-hybridi+avainsana	96,5 %	93,7 %	96,9 %	88,4 %

SECI-ekstraktio johtaa neljässä kuudesta kysymystyypistä. MemPalacen menetelmä voittaa tiedon päivityksessä (+2,1 pp), jossa muuttuneiden faktojen alkuperäisellä sanamuodolla on merkitystä. SECI:n etu on suurin yhden istunnon käyttäjäkysymyksissä (+4,7 pp), joissa vastaus on haudattu syvälle pitkään keskusteluun.

---

Miksi ekstraktio voittaa: 256 tokenin katkaisuongelma

Tulos yllätti meidät. MemPalacen teesi on intuitiivinen: ekstraktio menettää tietoa, raaka säilyttää kaiken. Teoriassa raa'an pitäisi voittaa.

Ero on pienempi kuin ensimmäinen 100 kysymyksen otoksemme antoi ymmärtää (+4,9 pp kaventui +1,8 prosenttiyksikköön koko 500 kysymyksen mittakaavassa). Ajallisen päättelyn ja tiedon päivityksen kysymykset kavensivat kuilua. Juuri siksi kannattaa ajaa koko vertailu.

Todellisuus: upotusmalli ei pysty lukemaan koko dokumenttia.

all-MiniLM-L6-v2 (ChromaDB:n oletusmalli, jota käyttävät sekä MemPalace että vertailumme) sallii enintään 256 tokenin sekvenssin. Se on suunnilleen 1 000 merkkiä.

LongMemEval-istunnot ovat keskimäärin 10 000 merkkiä pitkiä. Jotkin ylittävät 30 000 merkkiä.

Kun tallennat raa'an istunnon ja upotat sen, malli lukee ensimmäiset noin 1 000 merkkiä ja jättää loput huomiotta. 90 % sisällöstä on näkymätöntä haulle.

SECI-ekstraktiomme tiivistää koko istunnon noin 500 merkkiin strukturoituja avainfaktoja. Jokainen ekstraktoitu fakta mahtuu 256 tokenin ikkunaan. Mitään ei katkaista.

"Raaka voittaa aina" -teesi pätee vain silloin, kun upotusmallisi pystyy oikeasti lukemaan koko dokumentin. 256 tokenilla se ei pysty.

Raaka istunto (10 000 merkkiä):
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
 ↑ upotettu (1 000 merkkiä)   ↑ katkaistu (9 000 merkkiä) ← näkymätön haulle

SECI-ekstraktio (500 merkkiä):
[████████████████████]
 ↑ koko sisältö upotettu ← mitään ei menetetä

Muuttaisiko pidemmän kontekstin upotusmalli tuloksen?

Todennäköisesti kyllä. Mallit kuten bge-large-en-v1.5 (512 tokenia) tai nomic-embed-text-v1.5 (8192 tokenia) antaisivat raa'an tallennuksen upottaa enemmän jokaisesta istunnosta. MemPalacen julkaisema 96,6 % saattaa hyödyntää oletusmallin ohittavia optimointeja. Testaamme seuraavaksi pidemmän kontekstin upotuksia.

Pointti pysyy: hakusi laatua rajoittaa upotusikkunasi, eikä useimmat kehittäjät tarkista tätä.

---

Missä MemPalace oli oikeassa

Ansio sinne, minne se kuuluu:

1. Vain käyttäjän indeksointi. Assistentin vuorojen poistaminen paransi raakahakua 85,9 %:sta 92,1 %:iin, 6,2 pisteen loikka. Assistentin vastaukset lisäävät kohinaa (yleisluontoista, monisanaista), joka laimentaa upotusta. Fiksu suunnitteluvalinta.

2. Tiedon päivityksen suorituskyky. Raaka vain käyttäjä saa 98,6 % tiedon päivityksen kysymyksissä, kun meidän tuloksemme oli 96,5 %. Kun faktat muuttuvat ajan myötä, alkuperäisen sanamuodon säilyttäminen auttaa. Ekstraktio voi tasoittaa päivityssignaalin pois.

3. Vertailukulttuuri. Toistettavien LongMemEval-tulosten julkaiseminen skripteineen, läpinäkyvyys siitä, mikä tila (raaka vs. AAAK vs. huoneet) tuottaa minkäkin tuloksen, ja rehellisten korjausten tekeminen 48 tunnin sisällä julkaisusta. Näin avoimen lähdekoodin kuuluu toimia.

4. Ydinhavainto on osittain oikea. Mittakaavassa oikealla upotusmallilla raaka tallennus on vahva lähtötaso. Ala on ratkaissut ekstraktion liian monimutkaisesti kalliilla LLM-kutsuilla, kun yksinkertaisemmat menetelmät toimivat. Vivahde: "yksinkertaisemman" on huomioitava upotusikkuna.

---

SECI-malli tekoälyn muistille

Ekstraktiomenetelmämme perustuu SECI-tiedonhallintamalliin (Nonaka & Takeuchi, 1995), joka on sovitettu tekoälyagenttien muistiin:

Vaihe	Tiedon virtaus	Toteutus
Sosialisaatio	Hiljainen → Hiljainen	Istunto tapahtuu, konteksti koetaan
Ulkoistaminen	Hiljainen → Eksplisiittinen	/distill ekstraktoi strukturoidut faktat markdowniin
Yhdistäminen	Eksplisiittinen → Eksplisiittinen	/consolidate yhdistää, poistaa päällekkäisyydet, tunnistaa rappeutumisen
Sisäistäminen	Eksplisiittinen → Hiljainen	/remember lataa olennaisen kontekstin seuraavaan istuntoon

Järjestelmä tallentaa ekstraktoidun tiedon litteinä markdown-tiedostoina 10 nimiavaruuteen (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Jokainen tiedosto on ihmisen luettavissa ja versionhallinnassa.

Tätä vertailua varten lisäsimme ChromaDB:n markdown-tiedostojen alle: sekä raa'an tekstin että ekstraktoitujen tiivistelmien kaksoisindeksoinnin, ja käänteisen sijalukusummauksen kyselyhetkellä.

---

Menetelmä

Aineisto: LongMemEval_S (Wu ym., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory," ICLR 2025). 500 kysymystä, noin 48 heinäsuovaistuntoa per kysymys, istunnon keskimääräinen pituus 10 042 merkkiä.

Upotusmalli: all-MiniLM-L6-v2 (384-ulotteinen, 256 tokenin maksimisekvenssi). ChromaDB:n oletus.

Haku: istuntotason tarkkuus. Top-10-haku. Mittarit: Recall@5, Recall@10, NDCG@5, NDCG@10.

Ekstraktiomenetelmä: sääntöpohjainen tiivistys (ei LLM:ää). Poimii aiheen ensimmäisestä käyttäjän viestistä, jatkokysymyksen viimeisestä käyttäjän viestistä ja ratkaisun viimeisestä assistentin viestistä. Noin 500 merkkiä per istunto. Tämä simuloi /distill-komentomme tuottaman tulosteen rakennetta.

Hybridiyhdistäminen: käänteinen sijalukusummaus (RRF, k=60) raa'oista ja ekstraktoiduista hakupisteistä, sekä avainsanapäällekkäisyyden korotus (jopa 30 % tarkoille termiosumille).

Otos: 500 kysymystä (470 arvioitu, 30 pidättäytymistä ohitettu). Kaikki 6 kysymystyyppiä: yhden istunnon käyttäjä, yhden istunnon assistentti, yhden istunnon preferenssi, monen istunnon, ajallinen päättely, tiedon päivitys.

Koodi: seci_vs_mempalace.py

Varaukset

• Top-10-haku. MemPalace vertailee top-50-haulla (n_results=50) ja arvioi R@5:n tuosta joukosta. Meidän top-10 on rajatumpi. Reilu vertailu yhteensovitetuilla parametreilla on tulossa.
• Sääntöpohjainen ekstraktio. Ekstraktiomme käyttää regex-/heuristista tiivistystä, ei LLM-tiivistämistä. LLM-pohjainen ekstraktio parantaisi todennäköisesti laatua, mutta lisäisi kustannuksia ja viivettä.
• Yksi upotusmalli. Tulokset koskevat nimenomaan all-MiniLM-L6-v2:ta (256 tokenia). Pidemmän kontekstin mallit kaventaisivat raa'an ja ekstraktoidun menetelmän välistä eroa.
• Tiedon päivitys on heikko kohta. MemPalacen menetelmä saa 98,6 % vs. meidän 96,5 % kysymyksissä, joissa faktat muuttuvat ajan myötä. Ekstraktio voi tasoittaa päivityssignaalin pois.

---

Mitä tämä tarkoittaa rakentajille

Jos rakennat tekoälyn muistijärjestelmää:

1. Tarkista upotusikkunasi. Jos upotusmallisi katkaisee 256 tai 512 tokenin kohdalla ja dokumenttisi ovat pidempiä, menetät tietoa upotuskerroksessa riippumatta tallennusstrategiastasi.

2. Ekstraktio ei aina hukkaa tietoa. Kun ekstraktio tiivistää pitkän dokumentin esitykseksi, joka mahtuu upotusikkunaan, se säilyttää enemmän haettavaa tietoa kuin raaka tallennus, joka katkaistaan.

3. Vain käyttäjän indeksointi auttaa. Assistentin vuorojen poistaminen keskustelumuistista vähentää kohinaa. 6,2 pisteen parannus ilmaiseksi.

4. Hybridihaku lisää sijoituslaatua. Raa'an ja ekstraktoidun pisteen yhdistäminen RRF:llä ei paranna palautuvuutta pelkkään ekstraktioon nähden, mutta se parantaa NDCG:tä (sijoituslaatua). Oikeat dokumentit sijoittuvat korkeammalle, kun yhdistät molemmat signaalit.

5. Vertaile järjestelmääsi. LongMemEval on ilmainen, hyvin suunniteltu ja toistettava. Sen ajaminen vie muutaman tunnin. Tulokset voivat yllättää sinut.

---

Näiden tulosten toistaminen

# Asenna riippuvuudet
pip install chromadb sentence-transformers

# Lataa LongMemEval-data
mkdir -p data && cd data
curl -L -o longmemeval_s_cleaned.json \
  https://huggingface.co/datasets/xiaowu0162/longmemeval-cleaned/resolve/main/longmemeval_s_cleaned.json
cd ..

# Aja vertailu
python seci_vs_mempalace.py --dataset s --mode retrieval

Koko koodi: github.com/rankfor/ai-memory-benchmark

---

Mitä testaamme seuraavaksi

1. Pidemmän kontekstin upotusmallit (bge-large, nomic-embed-text) nähdäksemme, kuroko raaka tallennus kiinni, kun katkaisu poistetaan.
2. LLM-pohjainen ekstraktio (Gemini Flash istuntotiivistelmiin) vs. sääntöpohjainen ekstraktiomme.
3. Ajallinen korotus päivätietoiselle haulle ajallisen päättelyn kysymyskategoriassa.
4. Top-50-haku MemPalacen tarkan asetelman kanssa reilua vertailua varten.

Koodi on avoin. Otamme toistot ilolla vastaan.

---

Dmitrij Żatuchin, Rankfor.AI. Huhtikuu 2026.

Tämä tutkimus on riippumaton. Meillä ei ole yhteyttä MemPalaceen, LongMemEvaliin tai ChromaDB:hen. Vertailun koodi ja tulokset ovat avoimia toistettavaksi.