MemPalace osiąga 96,6% w LongMemEval. Uruchomiliśmy ten sam benchmark. Ustrukturyzowana ekstrakcja wypadła lepiej.

Wiralowa teza: surowe przechowywanie tekstu słowo w słowo bije wszystko w kwestii pamięci AI. Odtworzyliśmy benchmark i doszliśmy do innego wniosku. Wąskim gardłem jest ucinanie tekstu przy tworzeniu embeddingów, nie utrata informacji podczas ekstrakcji. Oto dane.

---

Dlaczego uruchomiliśmy ten benchmark

MemPalace (github.com/milla-jovovich/mempalace) wystartował 5 kwietnia 2026 i w 48 godzin zdobył 14 500 gwiazdek na GitHubie. Główna teza: zapisuj każdą rozmowę słowo w słowo w ChromaDB, całkowicie pomiń ekstrakcję przez LLM, a uzyskasz 96,6% recall w standardowym benchmarku pamięci AI (LongMemEval).

Wniosek dla całej dziedziny: każdy system, który używa LLM do ekstrakcji lub streszczania wspomnień, przeinżyniera problem. Wygrywa surowy tekst z dobrymi embeddingami.

Budujemy systemy zarządzania wiedzą oparte na modelu SECI (Nonaka i Takeuchi, 1995), w których ustrukturyzowana ekstrakcja jest podstawową operacją. Jeśli surowe przechowywanie faktycznie bije ekstrakcję, nasza architektura jest błędna. Więc to przetestowaliśmy.

---

Co testowaliśmy

Benchmark: LongMemEval_S (Wu i in., ICLR 2025). 500 pytań sprawdzających pięć zdolności pamięci długoterminowej: ekstrakcję informacji, wnioskowanie wielosesyjne, aktualizacje wiedzy, wnioskowanie temporalne i wstrzymanie się od odpowiedzi. Każde pytanie obejmuje około 48 sesji rozmów pełniących rolę „stogu siana", z których 1 do 3 zawiera odpowiedź.

Cztery podejścia do wyszukiwania, ten sam model embeddingów (all-MiniLM-L6-v2), te same dane:

#	Podejście	Opis
1	Surowe wszystkie tury	Zapisz pełny tekst sesji (użytkownik + asystent), utwórz embedding bez zmian
2	Surowe tylko użytkownik	Metoda MemPalace: zapisz tylko tury użytkownika, utwórz embedding bez zmian
3	Ekstrakcja SECI	Skondensuj każdą sesję do około 500 znaków ustrukturyzowanych faktów
4	Hybryda SECI + słowa kluczowe	Połącz wyniki surowe i po ekstrakcji przez reciprocal rank fusion, dodaj wzmocnienie za pokrycie słów kluczowych

Wszystkie podejścia używają ChromaDB z wyszukiwaniem po podobieństwie kosinusowym. Żaden LLM nie bierze udziału w wyszukiwaniu. Jedyna różnica polega na tym, co trafia do indeksu.

---

Wyniki

LongMemEval_S: wyszukiwanie na poziomie sesji (500 pytań, wszystkie 6 typów)

Podejście	R@5	R@10	NDCG@5	NDCG@10
Surowe wszystkie tury	85,9%	92,8%	80,3%	83,0%
Surowe tylko użytkownik (metoda MemPalace)	92,1%	96,3%	86,8%	88,5%
Ekstrakcja SECI	93,7%	96,7%	89,1%	90,3%
Hybryda SECI + słowa kluczowe	93,9%	96,6%	89,7%	90,8%

Hybryda SECI pobiła surowe przechowywanie w stylu MemPalace o 1,8 punktu procentowego w R@5.

Podział na typy pytań

Podejście	Aktual. wiedzy (n=72)	Wielosesyjne (n=121)	SS-User (n=64)	Temporalne (n=127)
Surowe tylko użytkownik (MemPalace)	98,6%	90,6%	92,2%	86,9%
Ekstrakcja SECI	95,8%	93,2%	96,9%	88,8%
Hybryda SECI + sł. kl.	96,5%	93,7%	96,9%	88,4%

Ekstrakcja SECI prowadzi w 4 z 6 typów pytań. Metoda MemPalace wygrywa przy aktualizacjach wiedzy (+2,1 pp), gdzie oryginalne brzmienie zmienionych faktów ma znaczenie. Przewaga SECI jest największa przy pytaniach jednosesyjnych dotyczących użytkownika (+4,7 pp), gdzie odpowiedź jest głęboko ukryta w długiej rozmowie.

---

Dlaczego ekstrakcja wygrywa: problem ucinania przy 256 tokenach

Wynik nas zaskoczył. Teza MemPalace jest intuicyjna: ekstrakcja traci informacje, surowy tekst zachowuje wszystko. W teorii surowy tekst powinien wygrać.

Różnica jest mniejsza, niż sugerowała nasza początkowa próba 100 pytań (+4,9 pp zawęziło się do +1,8 pp przy pełnej skali 500 pytań). Pytania o wnioskowanie temporalne i aktualizacje wiedzy zmniejszyły dystans. Dokładnie dlatego uruchamia się pełny benchmark.

Rzeczywistość: model embeddingów nie potrafi przeczytać całego dokumentu.

all-MiniLM-L6-v2 (domyślny model ChromaDB, używany zarówno przez MemPalace, jak i w naszym benchmarku) ma maksymalną długość sekwencji równą 256 tokenom. To około 1000 znaków.

Sesje w LongMemEval mają średnio 10 000 znaków. Niektóre przekraczają 30 000.

Kiedy zapisujesz surową sesję i tworzysz jej embedding, model czyta pierwsze około 1000 znaków i ignoruje resztę. 90% treści jest niewidoczne dla wyszukiwania.

Nasza ekstrakcja SECI kondensuje całą sesję do około 500 znaków ustrukturyzowanych kluczowych faktów. Każdy wyekstrahowany fakt mieści się w oknie 256 tokenów. Nic nie zostaje ucięte.

Teza „surowy tekst zawsze wygrywa" utrzymuje się tylko wtedy, gdy twój model embeddingów faktycznie potrafi przeczytać cały dokument. Przy 256 tokenach nie potrafi.

Surowa sesja (10 000 znaków):
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
 ↑ embedding (1000 znaków)   ↑ ucięte (9000 znaków) ← niewidoczne dla wyszukiwania

Ekstrakcja SECI (500 znaków):
[████████████████████]
 ↑ cała treść w embeddingu ← nic nie tracimy

Czy model embeddingów z dłuższym kontekstem zmieniłby wynik?

Prawdopodobnie tak. Modele takie jak bge-large-en-v1.5 (512 tokenów) albo nomic-embed-text-v1.5 (8192 tokenów) pozwoliłyby surowemu przechowywaniu objąć embeddingiem większą część każdej sesji. Opublikowany przez MemPalace wynik 96,6% może korzystać z optymalizacji wykraczających poza model domyślny. Testujemy dłuższe konteksty embeddingów jako kolejny krok.

Wniosek pozostaje w mocy: jakość wyszukiwania jest ograniczona przez okno embeddingów, a większość programistów tego nie sprawdza.

---

Co MemPalace zrobił dobrze

Należy oddać sprawiedliwość:

1. Indeksowanie tylko tur użytkownika. Usunięcie tur asystenta poprawiło surowe wyszukiwanie z 85,9% do 92,1%, czyli o 6,2 punktu. Odpowiedzi asystenta wprowadzają szum (ogólny, rozwlekły), który rozmywa embedding. Mądra decyzja projektowa.

2. Wydajność przy aktualizacjach wiedzy. Surowe tylko użytkownik osiąga 98,6% przy pytaniach o aktualizacje wiedzy wobec naszych 96,5%. Kiedy fakty zmieniają się w czasie, oryginalne brzmienie pomaga. Ekstrakcja może zatrzeć sygnał aktualizacji.

3. Kultura benchmarkowania. Publikowanie odtwarzalnych wyników LongMemEval wraz ze skryptami, przejrzystość co do tego, który tryb (surowy, AAAK czy rooms) daje który wynik, oraz uczciwe korekty w ciągu 48 godzin od startu. Tak powinno działać open source.

4. Kluczowa idea jest częściowo słuszna. W dużej skali z właściwym modelem embeddingów surowe przechowywanie stanowi mocny punkt odniesienia. Dziedzina przeinżyniera ekstrakcję kosztownymi wywołaniami LLM, podczas gdy prostsze podejścia działają. Niuans: „prostsze" musi uwzględniać okno embeddingów.

---

Model SECI dla pamięci AI

Nasze podejście do ekstrakcji opiera się na modelu zarządzania wiedzą SECI (Nonaka i Takeuchi, 1995), zaadaptowanym do pamięci agentów AI:

Faza	Przepływ wiedzy	Implementacja
Socjalizacja	Ukryta → Ukryta	Sesja się odbywa, kontekst zostaje doświadczony
Eksternalizacja	Ukryta → Jawna	/distill wyodrębnia ustrukturyzowane fakty do markdown
Kombinacja	Jawna → Jawna	/consolidate łączy, usuwa duplikaty, wykrywa dezaktualizację
Internalizacja	Jawna → Ukryta	/remember ładuje istotny kontekst do następnej sesji

System przechowuje wyodrębnioną wiedzę jako płaskie pliki markdown w 10 przestrzeniach nazw (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Każdy plik jest czytelny dla człowieka i objęty kontrolą wersji.

Na potrzeby tego benchmarku dodaliśmy ChromaDB pod plikami markdown: podwójne indeksowanie zarówno surowego tekstu, jak i wyekstrahowanych streszczeń, z reciprocal rank fusion w momencie zapytania.

---

Metodologia

Zbiór danych: LongMemEval_S (Wu i in., „LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory", ICLR 2025). 500 pytań, około 48 sesji „stogu siana" na pytanie, średnia długość sesji 10 042 znaki.

Model embeddingów: all-MiniLM-L6-v2 (384 wymiary, maksymalna długość sekwencji 256 tokenów). Domyślny w ChromaDB.

Wyszukiwanie: granularność na poziomie sesji. Wyszukiwanie top-10. Metryki: Recall@5, Recall@10, NDCG@5, NDCG@10.

Metoda ekstrakcji: kondensacja oparta na regułach (bez LLM). Wyodrębnia temat z pierwszej wiadomości użytkownika, kontynuację z ostatniej wiadomości użytkownika, rozwiązanie z ostatniej wiadomości asystenta. Około 500 znaków na sesję. Symuluje to strukturę wyniku naszej komendy /distill.

Fuzja hybrydowa: Reciprocal Rank Fusion (k=60) wyników wyszukiwania surowego i po ekstrakcji, plus wzmocnienie za pokrycie słów kluczowych (do 30% za dokładne dopasowania terminów).

Próba: 500 pytań (470 ocenionych, 30 wstrzymań pominiętych). Wszystkie 6 typów pytań: single-session-user, single-session-assistant, single-session-preference, multi-session, temporal-reasoning, knowledge-update.

Kod: seci_vs_mempalace.py

Zastrzeżenia

• Wyszukiwanie top-10. MemPalace benchmarkuje z wyszukiwaniem top-50 (n_results=50) i ocenia R@5 z tej puli. Nasze top-10 jest bardziej ograniczone. Uczciwe porównanie z dopasowanymi parametrami wkrótce.
• Ekstrakcja oparta na regułach. Nasza ekstrakcja używa kondensacji opartej na regex i heurystykach, nie streszczania przez LLM. Ekstrakcja oparta na LLM prawdopodobnie poprawiłaby jakość, ale dodałaby koszt i opóźnienie.
• Pojedynczy model embeddingów. Wyniki są specyficzne dla all-MiniLM-L6-v2 (256 tokenów). Modele z dłuższym kontekstem zawęziłyby różnicę między podejściem surowym a po ekstrakcji.
• Aktualizacje wiedzy to słaby punkt. Metoda MemPalace osiąga 98,6% wobec naszych 96,5% przy pytaniach, gdzie fakty zmieniają się w czasie. Ekstrakcja może zatrzeć sygnał aktualizacji.

---

Co to oznacza dla twórców

Jeśli budujesz system pamięci AI:

1. Sprawdź swoje okno embeddingów. Jeśli twój model embeddingów ucina tekst przy 256 lub 512 tokenach, a twoje dokumenty są dłuższe, tracisz informacje na warstwie embeddingów niezależnie od strategii przechowywania.

2. Ekstrakcja nie zawsze traci informacje. Kiedy ekstrakcja kondensuje długi dokument do reprezentacji mieszczącej się w oknie embeddingów, zachowuje więcej wyszukiwalnych informacji niż surowe przechowywanie, które zostaje ucięte.

3. Indeksowanie tylko tur użytkownika pomaga. Usunięcie tur asystenta z pamięci rozmów zmniejsza szum. Poprawa o 6,2 punktu za darmo.

4. Wyszukiwanie hybrydowe podnosi jakość rankingu. Łączenie wyników surowych i po ekstrakcji przez RRF nie poprawia recall względem samej ekstrakcji, ale poprawia NDCG (jakość rankingu). Właściwe dokumenty trafiają wyżej, gdy łączysz oba sygnały.

5. Zbenchmarkuj swój system. LongMemEval jest darmowy, dobrze zaprojektowany i odtwarzalny. Jego uruchomienie zajmuje kilka godzin. Wyniki mogą cię zaskoczyć.

---

Odtwarzanie tych wyników

# Zainstaluj zależności
pip install chromadb sentence-transformers

# Pobierz dane LongMemEval
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 ..

# Uruchom benchmark
python seci_vs_mempalace.py --dataset s --mode retrieval

Pełny kod: github.com/rankfor/ai-memory-benchmark

---

Co testujemy dalej

1. Modele embeddingów z dłuższym kontekstem (bge-large, nomic-embed-text), aby sprawdzić, czy surowe przechowywanie nadgania, gdy usuniemy ucinanie.
2. Ekstrakcja oparta na LLM (Gemini Flash do streszczania sesji) kontra nasza ekstrakcja oparta na regułach.
3. Wzmacnianie temporalne dla wyszukiwania świadomego dat w kategorii pytań o wnioskowanie temporalne.
4. Wyszukiwanie top-50, aby dopasować się do dokładnej konfiguracji MemPalace dla uczciwego porównania.

Kod jest otwarty. Zapraszamy do odtwarzania wyników.

---

Dmitrij Żatuchin, Rankfor.AI. Kwiecień 2026.

To badanie jest niezależne. Nie mamy powiązań z MemPalace, LongMemEval ani ChromaDB. Kod benchmarku i wyniki są otwarte do odtworzenia.