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ść:
-
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.
-
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.
-
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.
-
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:
-
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.
-
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.
-
Indeksowanie tylko tur użytkownika pomaga. Usunięcie tur asystenta z pamięci rozmów zmniejsza szum. Poprawa o 6,2 punktu za darmo.
-
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.
-
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
- Modele embeddingów z dłuższym kontekstem (bge-large, nomic-embed-text), aby sprawdzić, czy surowe przechowywanie nadgania, gdy usuniemy ucinanie.
- Ekstrakcja oparta na LLM (Gemini Flash do streszczania sesji) kontra nasza ekstrakcja oparta na regułach.
- Wzmacnianie temporalne dla wyszukiwania świadomego dat w kategorii pytań o wnioskowanie temporalne.
- 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.