Gdzie trzymać historię chatu? Microsoft ma odpowiedź

Microsoft Agent Framework opublikował techniczny przewodnik po wzorcach przechowywania historii konwersacji — i to jest ta decyzja projektowa, o której większość deweloperów myśli za późno.

Modele i prompty to nie wszystko

Zwiększość rozmów o budowaniu agentów kręci się wokół wyboru modelu, projektowania promptów i podłączania narzędzi. Tymczasem architektura składowania historii chatu potrafi położyć całego agenta — dosłownie. Wyobraź sobie użytkownika, który zadaje złożone pytanie, klika „spróbuj ponownie”, otwiera drugą kartę przeglądarki i wraca po 20 minutach. Jeśli historia konwersacji żyje tylko w pamięci podręcznej jednej sesji, agent nie ma pojęcia, co się wcześniej działo.

Microsoft identyfikuje kilka kluczowych scenariuszy, w których zły wybór wzorca przechowywania bezpośrednio psuje doświadczenie użytkownika albo generuje dodatkowe koszty przez wielokrotne wysyłanie tych samych danych do modelu.

Czy przechowywanie in-memory to zły pomysł?

Nie zawsze. Składowanie historii wyłącznie w pamięci procesu ma sens w bardzo konkretnym przypadku: krótkie, jednorazowe zadania, które nie wymagają ciągłości między sesjami. Narzędzie do jednorazowej analizy dokumentu albo prosty chatbot odpowiadający na FAQ — tam in-memory działa i nie dokłada niepotrzebnej złożoności infrastruktury.

Problem zaczyna się, gdy deweloper używa tego wzorca domyślnie, bo jest najprostszy do odpalenia. Przy skalowaniu do wielu instancji serwera każde nowe żądanie może trafić do innego procesu, który nie zna poprzednich wiadomości. Agent zaczyna zachowywać się jak ktoś z amnezją — użytkownik musi tłumaczyć kontekst od zera przy każdym odświeżeniu strony.

Trwałe składowanie i jego kompromisy

Microsoft Agent Framework opisuje podejście z zewnętrznym magazynem danych — bazą SQL, CosmosDB lub kompatybilnym storage’em. Historia konwersacji przeżywa restarty serwera, skalowanie poziome i wielodniowe przerwy między sesjami.

To rodzi inny problem: co wchodzi do kontekstu wysyłanego do modelu? Pełna historia rozmowy z trzech tygodni może spokojnie przekroczyć limit tokenów nawet najhojniej skonfigurowanego modelu. Framework sugeruje kilka strategii przycinania:

• Okno kroczące — agent widzi ostatnie N wiadomości, starsze są pomijane
• Podsumowania — starsze fragmenty konwersacji są kompresowane przez model do skrótu
• Selekcja semantyczna — do kontekstu trafiają fragmenty najbardziej związane z bieżącym pytaniem

Każde z tych podejść zmienia zachowanie agenta w subtelny, ale zauważalny sposób. Okno kroczące jest proste, ale agent „zapomina” ważne fakty z początku rozmowy. Podsumowania dokładają dodatkowe wywołania modelu i koszt. Selekcja semantyczna wymaga embedingów i wektorowej bazy danych.

Co z wielowątkowymi konwersacjami?

Najciekawszy fragment dokumentu dotyczy scenariusza, który większość tutoriali całkowicie pomija — co gdy jeden użytkownik prowadzi równolegle kilka wątków rozmów? Albo gdy agent obsługuje zadania w tle, a użytkownik jednocześnie pyta o coś innego w interfejsie?

Microsoft proponuje tu model z identyfikatorami sesji i wątków jako osobnymi bytami. Historia nie jest przypisana do użytkownika globalnie, lecz do konkretnej sesji lub zadania. Agent może wtedy prowadzić równoległe konteksty bez mieszania danych między nimi. To wymaga jednak przemyślanego schematu danych od samego początku — późniejsza migracja z płaskiej struktury do hierarchicznej potrafi boleć.

Distributed cache jako środkowa droga

Między in-memory a pełną bazą danych jest opcja trzecia: Redis lub inny distributed cache. Historia żyje krócej niż w bazie (TTL zwykle od kilku godzin do kilku dni), ale jest dostępna dla wszystkich instancji serwera. Przy typowym use-casie — sesja obsługi klienta trwająca do kilkudziesięciu minut — to często wystarczy i kosztuje mniej niż pełna persystencja.

Framework zaznacza wprost: nie ma jednego właściwego wzorca. Wybór zależy od tego, jak długo musi przeżyć kontekst, ilu równoległych użytkowników obsługuje system i jaki jest budżet na tokeny.

Dokumentacja nie podaje benchmarków wydajnościowych ani porównania kosztów między poszczególnymi podejściami — to akurat byłoby użyteczne uzupełnienie dla zespołów podejmujących tę decyzję po raz pierwszy.”, “coverImageAlt”: “Ilustracja przedstawiająca serwer przechowujący bąbelki konwersacji chatbota AI