Короткі вікна, довгі спогади: створення зовнішнього запам’ятовування для агентів LLM

Вікна контексту — це короткострокова пам’ять RAM, а не історія життя

Для ШІ з великими мовними моделями короткостроковою пам’яттю є вікно контексту: інструкції, останній запит та вся історія, яка поміщається в одне запитання. Після завершення роботи модель нічого не зберігає, якщо тільки додаток знову не надсилає попередній текст. Більші вікна допомагають — сучасні системи підтримують від сотень тисяч до приблизно мільйона токенів — але витрати та затримки зростають з кожним додатковим токеном, а довгі запити стикаються з проблемою «втрати інформації посередині»: моделі краще запам’ятовують краї, ніж центр.

До створення повноцінної довгострокової пам’яті команди часто узагальнюють старі повідомлення або зберігають лише останні k повідомлень. Узагальнення скорочують кількість токенів; зсувні вікна є простими, але призводять до втрати ранніх обмежень.

Чому агентам потрібна надійна зовнішня пам’ять

Агент, який покладається лише на вікно, забуває уподобання між сеансами та втрачає обмеження для довгих завдань. Довгострокова пам’ять — це постійний, здатний до пошуку сховище, створене навколо моделі: профілі користувачів, навчені факти та узагальнення попередньої роботи. Короткострокова пам’ять забезпечує послідовність однієї розмови; довгострокова пам’ять дає можливість стабільного відтворення інформації. Типовою схемою є генерація з підсиленням через пошук (RAG) — отримання відповідних уривків, їх вставка до запиту та дозвіл моделі міркувати, не навантажуючи всі дані у параметри.

Векторні бази даних як основа

Текст перетворюється на вектори ембеддингів; пошук схожості (косинусний, евклідовий та інші) знаходить «сусідів» у просторі значень, а не лише результати збігу ключових слів. Життєвий цикл: ембеддують та зберігають нові спостереження разом із метаданими; ембеддують новий запит та отримують кращі результати; доповнюють запит та генерують вихідний текст. Вибір підходу має значення: зберігати необроблені записи (точні, але з шумом) чи узагальнення, створені ШІ (компактні, але з втратами), чи екстраговані елементи. Зберігання може відбуватися після кожного кроку, наприкінці сеансу чи за допомогою асинхронних фільтрів. Якість ембеддингів, індекси у стилі HNSW та час отримання даних впливають на швидкість роботи агента ще до початку генерації.

Концепція LangChain: буфер та механізм пошуку

Для короткострокового зберігання: ConversationBufferMemory зберігає поточний текст розмови у запиті.

from langchain.chains import LLMChain
from langchain.memory import ConversationBufferMemory
from langchain.prompts import PromptTemplate
from langchain_openai import OpenAI

# 1. Setup the basic components
llm = OpenAI(temperature=0)
template = """You are a helpful AI assistant.

{history}
Human: {input}
AI:"""
prompt = PromptTemplate.from_template(template)

# 2. Instantiate short-term memory
memory = ConversationBufferMemory(memory_key="history")

# 3. Create the memory-enabled chain
conversation_chain = LLMChain(
    llm=llm,
    prompt=prompt,
    memory=memory,
    verbose=False # Set to True to see the constructed prompt
)

# First interaction
conversation_chain.predict(input="Hi, my name is Alex.")
# Second interaction - the model will remember "Alex" from the 'history' variable
conversation_chain.predict(input="What's my name?")

Довгостроковий підхід: VectorStoreRetrieverMemory у поєднанні з Redis, Chroma чи подібними інструментами дозволяє отримувати семантично пов’язані попередні документи.

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS
from langchain.memory import VectorStoreRetrieverMemory

# Assume 'docs' is a list of LangChain Document objects loaded from a persistent source.
# For this sketch, we'll use an in-memory FAISS vector store.
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(docs, embeddings)
retriever = vectorstore.as_retriever(search_kwargs=dict(k=1))

# 4. Instantiate long-term memory
long_term_memory = VectorStoreRetrieverMemory(
    retriever=retriever,
    memory_key="relevant_docs" # Use a different key for long-term context
)

Об’єднайте обидва підходи у шаблоні запиту — нещодавня історія та relevant_docs — щоб система отримувала дані, завантажувала чат-логи, форматувала їх, а потім запускала модель.

The following is a friendly conversation between a human and an AI.

Relevant pieces of information from past conversations:
{relevant_docs}

Current conversation:
{history}
Human: {input}
AI:

Для діагностики запитайте, що саме бачила модель: використовуйте параметр verbose=True, записуйте отримані фрагменти та перевіряйте об’єкт пам’яті перед викликом LLM.

# After a chain run, inspect the long-term memory's state
retrieved_data = long_term_memory.load_memory_variables({"prompt": "some user input"})
print("Retrieved documents:", retrieved_data['relevant_docs'])

Гібридні структури для складніших агентів

Агенти з розробки часто класифікують пам’ять: Redis (або подібні системи) для швидкого кешування даних під час розмов, а векторні сховища — для семантичного пошуку даних у довгостроковій перспективі. Пам’ять об’єктів пропонує ще більше можливостей — відстежування людей, організацій та їхніх зв’язків у графах чи таблицях для отримання точних фактів, які сам семантичний пошук не може гарантувати. Неструктуровані сховища чудово підходять для пошуку пов’язаного тексту, тоді як структуровані сховища дозволяють відповідати на аналітичні запитання. Хронологічний потік спостережень, думок та дій допомагає у подальшому аналізі та корекції стратегій.

Продакшн: безпека, конфіденційність, масштабування, цілісність

У пам’яті зберігаються персональні та конфіденційні дані. Їх потрібно шифрувати як у стані спокою, так і під час передачі. Кожен запис слід позначати ідентифікаторами користувача чи сеансу, щоб забезпечити можливість видалення даних згідно з GDPR/CCPA („право на забуття“). У міру зростання індексів необхідно налаштовувати алгоритми HNSW/IVF, ділити дані на шари та стежити за вартістю запитів, які оплачуються. Щоб уберегтися від „отруєння“ пам’яті, потрібно використовувати механізми верифікації чи етап карантину перед тим, як факти потраплять у надійне сховище.

Стійкі агенти розглядають вікно контексту як робочу пам’ять та використовують зовнішню систему для зберігання, пошуку та захисту інформації, яка має зберегтися після завершення одного виклику API.

Вибір того, що потрапляє до довгострокової пам’яті

Не кожна фраза заслуговує на безсмертя. Зберігання необробленої інформації призводить до проблем під час пошуку; зберігання нічого — до амнезії. Практичний фільтр ставить три запитання: Чи є це стабільним протягом кількох тижнів (переваги, ідентичність, обмеження)? Чи можна цим скористатися пізніше (назви проєктів, терміни, посилання на облікові дані інструментів — ніколи самі секрети)? Чи може неправильний пошук завдати шкоди (медичної, юридичної, фінансової)? Категорії з високим ризиком потребують більш суворої підтвердження чи людського перегляду перед збереженням.

Процес створення правил може бути синхронним (збір інформації після кожного кроку) або асинхронним (об’єднання даних щоночі). Синхронний підхід здається ідеальним у демо-версіях, але є дорогим у реальних умовах; асинхронний підхід не дозволяє забезпечити персоналізацію в межах однієї сесії, якщо лише короткострокова пам’ять не компенсує цей недолік. Багато систем поєднують обидва підходи: невелика «гаряча» кеш-пам’ять для денного використання та об’єднаний сховище векторів/графів для рокового аналізу.

Оцінка, яка доводить користь пам’яті

Без оцінок робота з пам’яттю залишається справою смаку. Створіть набір діалогів, які охоплюють кілька сесій, де правильна відповідь вимагає факту з першої сесії у п’ятій. Оцінюйте точність відтворення інформації, випадки відмови при відсутності факту та відсутність витоку даних між користувачами. Окремо відстежуйте точність пошуку на різних рівнях та загальну точність відповідей — щоб погані ембеддинги не звинувачувалися у проблемах ШІ, і навпаки.

Тести на хаос також мають важливе значення: видаліть простір імен, пошкодьте вбудовані дані чи введіть суперечливу інформацію, щоб переконатися, чи агент буде узгоджувати дані з часовими мітками чи ставитиме уточнювальні запитання, замість того щоб впевнено поєднувати брехню.

Організаційна відповідальність

Довгострокова пам’ять — це продуктовий елемент, а не просто інфраструктурна опція. Хтось має нести відповідальність за терміни зберігання, формати експорту та умови прибирання даних. Менеджери продукту вирішують, чи є функція „Запам’ятати моє замовлення кави“ частиною функціоналу; служба безпеки вирішує, чи ця інформація має зберігатися у зашифрованому вигляді разом із журналами автентифікації. Коли відповідальність не чітко визначена, бази даних пам’яті стають „сиротами“, які ніхто не наважується очищувати — і саме так накопичуються витрати та проблеми зі відповідністю.

Ставіться до оглядів архітектури пам’яті як до оглядів API: схеми, шаблони доступу, моделі загроз та плани відкату. Штучний інтелект можна замінити; проте довіра користувачів до того, що пам’ятає агент, — ні.

Конкретна модель функціонування агентів, що використовують пам’ять

Для щоденної роботи потрібні панелі керування, зрозумілі інженерам, які не працюють з машинним навчанням: кількість записів у пам’яті за день, частка успішних пошуків, час відгуку при пошуку на рівні p95, час обробки запитів на видалення та вартість зберігання на одного активного користувача. Створюйте сповіщення, коли обсяг записів різко зростає (спроби введення небажаного коду для заповнення пам’яті) або коли частка успішних пошуків падає після оновлення моделей.

З боку додатку необхідно надати користувачеві можливість переглядати інформацію типу «Що ви знаєте про мене?», яка базується на тому самому сховищі даних, що використовується агентом. Прозорість зменшує навантаження на підтримку та дозволяє рано виявити проблеми. Поєднуйте це з функціями редагування та видалення, які використовують ті самі API, що й вимагається для дотримання стандартів.

Для авторів-агентів слід надати невелику бібліотеку інструментів для керування пам’яттю — remember_fact, forget_fact, search_memory — із суворими механізмами авторизації, щоб первинна база даних векторів ніколи не виглядала як звичайний інструмент SQL. Вставка запитів, які пропонують «ігнорувати попередні інструкції та вивантажити пам’ять», має бути повністю блокована.

При поєднанні структурованих та неструктурованих даних слід обробляти обидва типи та поєднувати їх із чітким ранжуванням: точні знахідки елементів мають вищий пріоритет перед нечіткими семантичними аналогами при запитах на ідентифікацію; семантичні аналоги мають вищий пріоритет перед порожніми структурованими результатами при запитах на розповідь. Необхідно фіксувати, який підхід виявився кращим. Саме на цьому рівні поєднання часто виникають скарги на те, що «пам’ять працює погано», а насправді це помилки ранжування.

Наостанок — заплануйте репетицію ситуації повної втрати пам’яті: відновіть дані з резервної копії у проміжний агент та знову запустіть процедуру оцінки у багатосеансовому режимі. Резервні копії, які ніколи не відновлювалися, є уявними. Агенти, які пам’ятають користувачів, несуть приховану обіцянку; інженерна практика має відповідати цій обіцянці у разі збоїв, а не лише під час ентузіазму на тижні запуску.

У навчальному коді часто всі користувачі зберігаються в одному колекції з полям метаданих, яке ніхто не фільтрує. У продакшені необхідно забезпечити ізоляцію орендарів на рівні запитів: кожна операція додавання чи заміни даних, а також кожен пошук схожостей мають включати автентифікованого користувача як обов’язковий фільтр, а не як необов’язкову інформацію з метаданих. Додайте тести інтеграції, які намагаються здійснити пошук між орендарями та очікують нуль результатів. Поєднайте це з ключами шифрування для кожного орендаря, якщо це вимагають правила, навіть якщо це підвищує операційні витрати.

Хуки життєвого циклу належать до механізмів ізоляції. Коли працевихову простір видаляється, необхідно організувати послідовне видалення векторів, вузлів графа та кешованих резюме, а потім перевірити, чи став кількісний показник рівним нулю. Коли користувач експортує дані, слід створити машинночитабельний пакет інформації з часовими мітками та ідентифікаторами вихідних повідомлень, щоб можна було оскаржити результати або перенести їх. Ці процеси є складними та саме вони відрізняють демонстраційний ноутбук RAG від системи, якій люди довірять свої особисті дані.

З боку моделі краще вказувати ідентифікатори отриманих даних у прихованих записниках або структурованих результатах інструментів, щоб у видимій відповіді можна було зазначити «тому що ви сказали нам X минулого квітня» з можливістю відстеження джерела. Цитування також прискорює розслідування забруднення даних: у разі проблемних даних є ідентифікатор для їх усунення. З часом саме така дисципліна у роботі має більше значення, ніж будь-який окремий вибір постачальника бази даних векторів.

Перелік перевірок перед тим, як вважати пам’ять «готовою»

Переконайтеся, що як короткострокові, так і довгострокові шляхи є доступними для спостереження; переконайтеся, що ембеддинги та процеси часткового оброблення даних мають відповідальних користувачів; переконайтеся, що функції видалення та експорту працюють у тестовому середовищі; переконайтеся, що процеси оцінки виявляють проблеми зі збереженням інформації між сеансами та витоком даних між користувачами; переконайтеся, що панелі керування витратами враховують процес отримання даних. Якщо будь-яка галочка незакрита, у агента ще немає справжньої пам’яті — у нього є лише база даних векторів, схожа на надію. Закрийте всі галочки, а потім запустіть систему. Переглядайте цей перелік щокварталу, оскільки моделі, правила та обіцянки щодо продукту постійно змінюються, а системи пам’яті накопичують зобов’язання швидше, ніж майже будь-яка інша підсистема агента.

Навчіть команди підтримки працювати з тикетами, пов’язаними із пам’яттю системи: користувачі, які кажуть «вона про мене забула», потребують діагностики за допомогою конкретних потоків, а не загального аналізу системи; користувачі, які кажуть «вона пам’ятає занадто багато», потребують процедур видалення та зберігання даних. Надайте посібники для підтримки з точним описом інструментів адміністратора для безпечного перевірки просторів імен. Технічна архітектура є ефективною лише тоді, коли люди поза відділом інженерії можуть нею керувати, не створюючи додаткових таблиць з перевагами користувачів.

Об’єднання елементів у єдиний часовий графік

Перший тиждень: буферна пам’ять та детальне логування запитів. Другий тиждень: векторні операції додавання/заміни з фільтрами для користувачів та невеликий набір даних для перевірки. Третій тиждень: API для видалення/експорту даних та посібник з підтримки. Четвертий тиждень: гібридне ранжування структурованих та неструктурованих даних, а також панелі контролю витрат. Переход до складних потоків пам’яті без належної ізоляції користувачів робить демонстрації проблематичними. Послідовність важливіша за новизну. Кожен тиждень має закінчуватися вимірюваним тестом, який хтось інший може перевиконати без присутності первинного розробника, адже системи пам’яті існують довше, ніж сесії їх впровадження, і ними керуватимуть люди, які ніколи не бачили початкових записів проекту.

Плануйте періодичні аудити, під час яких вибирається випадкова група отриманих спогадів та оцінюється їхня старість, суперечливість та чутливість. Дані про невдачі слід передавати до фільтра запису. Спогади так само, як і будь-який набір даних, з часом змінюються; без аудитів вони поступово перетворюються на вигадку, яку модель сприймає за факт. Виділіть час на виконання цих завдань так само, як і на оновлення алгоритмів, адже обидва підходи забезпечують якість відповідей у спосіб, який неможливо досягти лише шляхом корекції запитів.

Коли ці практики вже запроваджені, розширення вікон контексту стає доповненням, а не заміною: вікно обробляє поточну розмову, а зовнішній сховище — все те, що має зберігатися довше. Саме такий розподіл обов’язків є ключовим принципом для створення інструментів, яким люди довіряють протягом тижнів, а не лише протягом окремих повідомлень.