Jak sprawdzić, czy pamięć agenta AI zna aktualną decyzję?

Oryginalna publikacja o RAG opisuje model łączący generowanie z dostępem do pobieranej pamięci nieparametrycznej. To pomaga, gdy problemem jest znalezienie dowodów istotnych dla zapytania. Nie definiuje jednak uniwersalnego lifecycle dla każdego rekordu, który aplikacja może odnaleźć.

Aktualne frameworki agentowe również rozdzielają zakresy pamięci. Dokumentacja LangChain odróżnia krótkotrwałą pamięć wątku od długoterminowych magazynów współdzielonych między sesjami. LangMem opisuje z kolei profile, kolekcje, aktualizację, konsolidację i reconciliation. Praktyczny wniosek nie brzmi „retrieval jest wadliwy”. Brzmi: retrieval, trwałość i polityka lifecycle są osobnymi decyzjami projektowymi.

Załóżmy, że pamięć projektu zawiera dwa zdania:

Wczoraj: Używaj SQLite jako bazy aplikacji.
Dzisiaj: Zastąp SQLite bazą PostgreSQL.

Oba fragmenty są istotne dla pytania o bazę danych. Wyszukiwanie podobieństwa może rozsądnie zwrócić oba. Pytanie operacyjne jest inne: która decyzja obowiązuje teraz i co stało się z poprzednią?

Proof tworzy jednorazową bazę SQLite, zapisuje obie fikcyjne decyzje, wykonuje chronioną operację supersession i sprawdza wynikowy current state, historię, relację oraz provenance. Stabilny JSON pomija ścieżki tymczasowe, wygenerowane identyfikatory, znaczniki czasu i hash podglądu, ale nadal potwierdza, że chroniony preview istnieje.

Znacznik czasu może uporządkować zdarzenia. Nie wyjaśnia ich relacji semantycznej.

• Korekta może dotyczyć innego projektu, środowiska, klienta albo scope.
• Późniejsze zdanie może być propozycją lub opinią, a nie zatwierdzoną decyzją.
• Dwie sesje mogą aktualizować różne części tego samego projektu bez wzajemnego zastępowania.
• Data utworzenia nie dowodzi, że jeden rekord zastępuje drugi.

Wiarygodne zapytanie o current state potrzebuje więc jawnej polityki: typu rekordu, scope, stanu lifecycle i relacji pomiędzy starą a nową informacją. „Najnowsze” może być jednym z sygnałów, ale nie jest całą polityką.

Drugi reprodukowalny scenariusz zapisuje dwa fikcyjne ustalenia:

Runbook operacyjny: Backup codziennie o 02:00 UTC
Przegląd incydentu:  Backup codziennie o 04:00 UTC

Wybranie późniejszego rekordu albo bardziej podobnego fragmentu ukryłoby rzeczywisty problem: dwa nazwane źródła są sprzeczne. Proof MAPI zachowuje oba rekordy i oba odwołania do źródeł, tworzy relację sprzeczności, oznacza klaster jako nierozstrzygnięty i nie wybiera automatycznego zwycięzcy.

Provenance ma znaczenie, ponieważ następny krok może zależeć od autora ustalenia i jego kontekstu. W3C PROV jest ogólną rodziną standardów wymiany informacji o pochodzeniu. MAPI używa własnego modelu produktowego, ale realizuje tę samą praktyczną potrzebę: rekord powinien pozostać powiązany ze swoim dowodem źródłowym.

Tabela opisuje typowe role, a nie gwarantowane możliwości każdej implementacji. Konkretny system rozmów lub vector store może dodać wersjonowanie, metadane, obsługę konfliktów albo governance.

Dwa scenariusze pokazują ograniczony, konkretny zestaw właściwości produktu:

• Decision supersession daje jeden aktualny stan, zachowuje poprzednią decyzję i jawną relację.
• Sprzeczne źródła pozostają dwoma rekordami z provenance, widocznym konfliktem i bez cichego nadpisania.
• Oba scenariusze używają danych syntetycznych i jednorazowych baz.
• Działają lokalnie, bez zewnętrznego LLM i bez wywołań API.
• Agregator zwraca stabilny, machine-readable JSON oraz krótki raport dla człowieka.

python scripts/run_product_proofs.py

Przed oparciem się na powyższym podsumowaniu sprawdź kod agregatora oraz metodologię i oczekiwane wyniki.

Supersession nie jest wyłączną cechą MAPI. Aktualna dokumentacja Cloudflare Agent Memory również opisuje ewolucję faktów przez supersession z zachowaniem starszych wersji. Wartość scenariuszy MAPI jest węższa: repozytorium udostępnia wykonywalne kontrole własnych deklarowanych zachowań.

MAPI może działać obok retrieval, historii rozmów, modelu językowego, runtime agenta i klienta MCP. Nie zastępuje modelu, RAG-u ani reszty architektury agenta. Koncentruje się na lifecycle pamięci projektu: kontrolowanych zapisach, current-state resolution, historii, relacjach, provenance, review konfliktów i audytowalności.

Ten nacisk ma sens tylko wtedy, gdy dodatkowe mechanizmy kontroli uzasadniają koszt operacyjny. Prosty plik, transkrypt albo magazyn może być lepszym wyborem, gdy decyzje rzadko się zmieniają, konflikty mają małe znaczenie albo nikt nie potrzebuje ścieżki audytu.

Te dwa pytania można wykorzystać bez wdrażania MAPI:

1. Zapisz jedną decyzję, jawnie ją zastąp, a następnie zapytaj zarówno o aktualny stan, jak i jego historię.
2. Zapisz sprzeczne ustalenia z dwóch źródeł i sprawdź, czy żaden łańcuch provenance nie znika przed review.

Jeżeli system potrafi tylko zwrócić podobny tekst, brakującą funkcją nie musi być „lepsze wyszukiwanie”. Może nią być jawna polityka lifecycle i konfliktów. Właśnie tę granicę artykuł ma uczynić testowalną.

Rozróżnienie użyte w artykule opiera się na źródłach pierwszorzędnych i wykonywalnych scenariuszach MAPI:

• Lewis i in.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — pierwotna formuła RAG łączy generowanie parametryczne z pobieraną pamięcią nieparametryczną.
• Przegląd pamięci LangChain — aktualna dokumentacja rozróżnia krótkotrwałą pamięć wątku od pamięci długoterminowej współdzielonej między sesjami.
• Koncepcje LangMem — kolekcje i profile pokazują różne modele aktualizacji oraz potrzebę uzgadniania nowych informacji z wcześniejszym stanem.
• Dokumentacja Cloudflare Agent Memory — przykład aktualnego produktu pamięciowego, który również dokumentuje supersession faktów i zachowanie starszych wersji.
• Przegląd W3C PROV — rodzina standardów dla interoperacyjnej informacji o pochodzeniu danych.
• MAPI GitHub, agregator proofów oraz metodologia proofów.