Persistent Memory Architecture for Long-Horizon Autonomous Missions with Operator Rotation
Cross-domain validation on three independent datasets confirms: context redundancy ~50-60% is systemic in autonomous agents; operator rotation costs +136% dialogue rounds (Hedges' g=0.81); context completeness predicts correction need (r=-0.60, g=1.73).
Abstract
Cross-domain validation on three independent datasets confirms: context redundancy ~50-60% is systemic in autonomous agents; operator rotation costs +136% dialogue rounds (Hedges' g=0.81); context completeness predicts correction need (r=-0.60, g=1.73). Four contributions: three-layer memory, dual-mode retrieval, retrieval-correction signal, degraded mode for escalation.
Ключові слова: персистентна пам'ять, автономні агентні системи, ротація операторів, дворежимне витягування, сигнал корекції, ескалація подій, деградований режим, БПЛА, онтологічно-керовані системи
Вступ: проблема безперервності управління
Актуальність
Автономні агентні системи — від великих мовних моделей (LLM), що працюють як програмні агенти, до безпілотних літальних апаратів (БПЛА) та наземних роботизованих комплексів — дедалі частіше виконують місії тривалістю від годин до тижнів. У таких системах людина-оператор здійснює нагляд (oversight) за автономним агентом: коригує рішення, змінює пріоритети, підтверджує або відхиляє дії.
При ротації операторів (зміна екіпажу БПЛА, зміна вахти ситуаційного центру, передача управління між змінами) виникає критична проблема: втрата контексту рішень. У термінах трирівневої моделі ситуаційної обізнаності, ротація руйнує всі три рівні: сприйняття (які елементи обстановки актуальні), розуміння (яке їхнє значення для місії) та проєкцію (як обстановка розвиватиметься). Новий оператор повинен знати:
- які рішення прийнято попередником і чому;
- які корекції внесено та на підставі якої інформації;
- які загрози виявлено, але не усунено;
- який контекст місії залишається актуальним.
Існуючі підходи до пам'яті агентних систем організовані навколо діалогових епізодів і не вирішують проблему зміни операторів. Дослідження нагляду оператора за кількома автономними системами та взаємодії людина–автономія фіксують проблему когнітивного навантаження при передачі управління, але не пропонують архітектури пам'яті для її вирішення. Системи доповненого витягування для програмних агентів витягують фрагменти без провенансу рішень. Моделі з довгим контекстом демонструють деградацію уваги після ~200K токенів.
Зв'язок зі школою кібернетичного управління
Запропонована робота розвиває принципи школи онтологічно-керованих систем, закладені в працях Палагіна та ін.: формальна онтологічна структура повинна не лише описувати систему, а контролювати її поведінку. Цей принцип послідовно застосовувався на дедалі вищих рівнях обчислювального стеку — від архітектури систем через обробку природномовних текстів до контролю виходу великих мовних моделей та еволюційних кібернетичних систем.
У даній роботі онтологічний контроль застосовується до підсистеми пам'яті автономного агента: формальна структура визначає, який контекст подається оператору при ініціалізації сесії, як оновлюється контекст простоюючих місій, та як вимірюється якість витягування через сигнал корекції.
Постановка задачі
Мета: розробити архітектуру підсистеми пам'яті для автономних агентних систем, що забезпечує:
- збереження контексту рішень між сесіями операторів;
- автоматичне оновлення контексту для простоюючих задач;
- генерацію сигналу корекції для вдосконалення системи навчання.
Об'єкт дослідження: процеси людино-машинної взаємодії в автономних агентних системах з довгостроковими місіями.
Предмет дослідження: методи та моделі забезпечення безперервності контексту управління при ротації операторів.
Аналіз існуючих підходів
Системи пам'яті для діалогових агентів
MemGPT реалізує віртуальне управління контекстом за аналогією з ієрархічною пам'яттю операційних систем. Generative agents використовують епізодичну пам'ять для симульованих агентів. Mem0 забезпечує довгострокову пам'ять для LLM через зовнішнє сховище.
A-MEM розвиває парадигму епізодичної пам'яті у напрямку структурованого знання: кожне спостереження перетворюється на атомарну нотатку за принципом Zettelkasten з явними зв'язками між нотатками, утворюючи граф знань поверх потоку спостережень. Це наближає одиницю пам'яті до структурованого запису, проте зв'язки залишаються асоціативними, а не каузальними — нотатка не фіксує відхилені альтернативи та не прив'язується до конституційного принципу.
Letta, комерціалізований наступник MemGPT, вводить два механізми, безпосередньо релевантні цій роботі. По-перше, контекстні репозиторії (context repositories) — персистентні версіоновані сховища структурованого контексту, до яких агент звертається між сесіями; вони замінюють плоску архівну модель MemGPT типізованими колекціями з підтримкою запитів. По-друге, контекстна конституція (context constitution) — декларативна специфікація того, до якого контексту агент має доступ і з яким пріоритетом, аналогічна політиці витягування, вираженій як конфігурація, а не як код. Ці механізми наближають пам'ять агента до витягування за провенансом рішень: контекстні репозиторії надають субстрат зберігання, а контекстна конституція — рудиментарну політику витягування. Проте одиницею витягування в Letta залишається контекстний блок (текстовий фрагмент з метаданими), а не оперативне рішення з провенансом, альтернативами та конституційним обґрунтуванням.
Reflexion підтримує епізодичну пам'ять вербальних рефлексій — агент зберігає текстові описи минулих помилок для покращення майбутніх дій. Цей механізм паралельний до нашого рівня оператора, де зберігаються структуровані абстракції корекцій. Когнітивна архітектура CoALA декомпозує агента на модулі пам'яті, дії та прийняття рішень — наша трирівнева декомпозиція є конкретною реалізацією цієї рамки для довгострокових місій. Систематичний огляд механізмів пам'яті для LLM-агентів подано у Zhang та ін. (2024).
Обмеження: усі розглянуті системи — MemGPT, Generative Agents, A-MEM, Mem0, Letta — використовують як одиницю витягування діалоговий обмін, спостереження персонажа або контекстний блок, а не оперативне рішення з повним провенансом.
Витягування для програмних агентів
Парадигма доповненої генерації (RAG) забезпечує фундамент витягування для мовних моделей. Corrective RAG вводить оцінювач якості витягування з сигналами корекції — найближча до нашого retrieval-correction signal робота, хоча обмежена одиничними запитами без довгострокового контексту місії. RepoCoder та подібні системи витягують фрагменти коду за семантичною подібністю. CodeRAG-Bench забезпечує систематичний бенчмарк для витягування з доповненою генерацією коду, охоплюючи документацію, довідники API та приклади коду як джерела витягування. SWE-bench та SWE-agent оцінюють агентів на реальних задачах з GitHub (issues), демонструючи, що витягування з урахуванням структури репозиторію та контексту задачі підвищує частку успішних розв'язків.
Обмеження: усі зазначені системи витягують текст коду та ідентифікатори — без провенансу рішень: чому цей код написано саме так, які альтернативи розглядались, які обмеження враховано.
Записи архітектурних рішень
Практика формального документування архітектурних рішень має тривалу історію в програмній інженерії. Формат Architecture Decision Record (ADR), запропонований Найґардом, визначає легковагий шаблон у форматі Markdown — назва, статус, контекст, рішення, наслідки — що зберігається безпосередньо разом із кодовою базою. Стандарт ISO/IEC/IEEE 42010 (iso42010) формалізує опис архітектури на організаційному рівні, надаючи нормативну рамку для документування архітектурних точок зору та відповідностей. Y-формат Цьорнера структурує рішення у вигляді шаблонного висловлювання: «В контексті [ситуація], зіткнувшись із [проблемою], ми вирішили [варіант], щоб досягти [якість], приймаючи [компроміс]». Zimmermann та ін. (2015) розширює практику управління ADR до міжпроєктного керівництва, додаючи моделювання простору проблем та систематичне відстеження залежностей між рішеннями.
ADR фіксують провенанс рішень — саме той контент, що відсутній у витягуванні code-RAG. Проте механізм витягування ADR залишається файловим: рішення знаходять переглядом директорії за назвою та датою, а не семантичним запитом. Відсутні індекс вбудовувань (embedding index), гібридне витягування, перерангування за релевантністю до поточної задачі. Крім того, ведення ADR потребує ручного авторства: у високошвидкісному робочому процесі з продуктивністю 14,7 PR/день кураторське навантаження на підтримку повного реєстру ADR стає заборонно високим.
За військовою аналогією, ADR подібні до журналу рішень командира — цінний артефакт, але пошук у ньому здійснюється за датою та підрозділом, а не за семантичною релевантністю до поточної оперативної ситуації.
Моделі з довгим контекстом
Gemini 1.5 Pro підтримує контекст до 1M+ токенів. Проте дослідження демонструють деградацію уваги після ~200K токенів: модель "губить" інформацію в середині довгого контексту. Плоске завантаження всього контексту місії не масштабується з тривалістю місії.
Системи управління знаннями в ситуаційних центрах
Онтологічно-керовані системи підтримки рішень забезпечують формальне представлення знань для ситуаційної обізнаності. Палагін та ін. (2024) демонструють ефективність інтеграції нейромережевих та онтолінгвістичних парадигм. В Інституті кібернетики НАН України розвиваються суміжні напрямки: теорія конфліктно-керованих процесів для формалізації задач переслідування та ухилення (застосовна до автономного управління БПЛА), оптимізація маршрутів команд БПЛА з динамічними депо, гібридні нейромережі для інтелектуального управління літальними апаратами. Проте жодна з існуючих систем не поєднує онтологічну структуру з дворежимним витягуванням для забезпечення безперервності управління при ротації операторів.
Синтез. Жодна з п'яти ліній робіт — діалогова пам'ять, витягування для програмних агентів, реєстри архітектурних рішень, моделі з довгим контекстом, онтологічно-керовані системи — не розглядає провенанс рішення як першокласну одиницю пам'яті із семантичним витягуванням. Жодна не забезпечує примітиву повільного циклу оновлення (slow-loop refresh), що підтримує актуальність пам'яті про неактивні задачі на горизонтах у кілька тижнів — інтервалі, характерному для ротації операторів у штабних процесах. Архітектура, описана в цій роботі, займає перетин цих ліній: вона запозичує структуру провенансу з ADR, семантичне витягування з Code-RAG, персистентність із систем діалогової пам'яті та селективне завантаження контексту з RAG — додаючи дворежимне витягування (dual-mode retrieval) як нову архітектурну примітиву, спеціально спроектовану для забезпечення безперервності управління при зміні операторів.
Формалізація проблеми
Три характеристики довгострокових місій
Довгострокова автономна місія характеризується трьома вимірюваними властивостями, верифікованими на пілотному датасеті:
- Горизонт. Пов'язані рішення охоплюють дні — тижні. У верифікаційному розгортанні: 105 днів активної роботи з медіанним інтервалом між комітами менше 2 годин, але архітектурними потоками тривалістю 4–6 тижнів.
- Композиційність. Рішення A тижня 2 обмежує рішення B тижня 6. Вибір схеми бази даних визначив контракти 29 інструментів, побудованих впродовж наступних п'яти тижнів.
- Персистентність. Стан місії є спільним між сесіями операторів. Агент не зберігає історію діалогу — він повертається до зміненого стану місії кожної нової сесії.
Проблема ініціалізації сесії
Кожна нова сесія оператора починається із завантаження контексту. Вимірювання на 304 сесіях: медіана вартості ініціалізації — 30 115 вхідних токенів, з яких ~59% — надлишковий контекст. Медіана коефіцієнта надлишковості (файли, зчитані при ініціалізації, але жодного разу не використані під час сесії) — 60%.
При ротації операторів проблема загострюється: новий оператор не має жодного контексту рішень попередника — лише стан місії без обґрунтувань.
Формальна постановка
Нехай T — кількість токенів ініціалізації, K — кількість зчитувань файлів/записів, W — коефіцієнт надлишковості.
- Pull-режим зменшує K та T при ініціалізації: замість плоского завантаження — цільове витягування за описом задачі.
- Push-режим підтримує актуальність контексту: для простоюючих задач/секторів фонове оновлення забезпечує, що при відновленні роботи контекст вже актуальний.
- Метрика якості: частка корекцій оператора, спричинених недостатнім контекстом (retrieval-correction signal).
Цільові показники: T' ≤ 10 000 токенів, W' ≤ 20%.
Архітектура трирівневої пам'яті
Підсистема пам'яті декомпозується на три рівні з різною семантикою витягування та субстратом зберігання. Рисунок показує загальну архітектуру з обома режимами витягування.
Предметний рівень (Domain Layer)
Предметний рівень містить оперативні дані домену.
Витягування: семантична подібність (cosine similarity) з опціональною фільтрацією за метаданими. Архітектурна зміна порівняно з прямими викликами інструментів: маршрутизація через єдину підсистему пам'яті забезпечує уніфіковане логування всіх запитів, вимірювання частоти промахів та єдиний формат відповіді.
Робочий рівень (Workflow Layer)
Робочий рівень містить контекст рішень — провенанс, відсутній як у вихідному коді, так і в предметних даних.
Витягування: гібридне — семантична подібність + структуровані фільтри (компонент, тип місії, часовий діапазон).
Рівень оператора (Practitioner Layer)
Рівень оператора містить патерни рішень конкретного оператора, витягнуті з pipeline корекцій.
Ключова властивість: цей рівень ніколи не зберігає сирий контент — тільки структуровані абстракції: клас корекції, семантична категорія, афектований компонент, результат (прийнято/відхилено/модифіковано) та однореченневе резюме.
Застосування при ротації: новий оператор отримує профіль попередника — типові корекції, зони підвищеної уваги, рішення місії з обґрунтуваннями — у компактному дайджесті при ініціалізації сесії.
Витягування: гібридне з фільтрацією за часом та результатом.
Фаза 0: міст промпт–коміт.
Перед розгортанням повноцінного рівня оператора встановлюється мінімальний колектор даних.
Хук UserPromptSubmit у Claude Code створює orphan-коміт у bare-репозиторії git для кожного промпту оператора.
Кожний запис містить: текст промпту, мітку часу, ідентифікатор сесії, репозиторій, гілку та режим дозволів.
Протягом 4–6 тижнів пасивного збору формується природномовний корпус, що забезпечує вхідні дані для трьох задач:
- розмежувальні мітки (disambiguation labels) — класифікація типу наміру оператора;
- розподіли частот тем (topic-frequency distributions) — виявлення домінантних робочих контекстів;
- патерни перемикання між проєктами (cross-project switching patterns) — моделювання переходів оператора між репозиторіями та завданнями.
Цей корпус є сировинним матеріалом для embedding-pipeline рівня оператора: з нього витягуються структуровані абстракції, описані вище, без збереження сирого контенту промптів у довготривалій пам'яті.
Продуктивність: затримка захоплення становить 15 мс на один промпт — непомітна в межах 5-секундного таймауту хуків Claude Code. Фаза 0 розгорнута з 9 травня 2026 р.
Військова аналогія. Фаза 0 аналогічна пасивному збору радіоелектронної розвідки (SIGINT): накопичення даних без втручання в оперативну діяльність, формування базового розуміння патернів поведінки оператора до розгортання активних систем аналізу та адаптації.
Дворежимне витягування
Pull-режим (активні сесії)
При вході нового оператора система виконує запит до всіх трьох рівнів паралельно. Опис поточної задачі/сектора вбудовується у вектор (embedding), зіставляється з проіндексованим сховищем пам'яті, і k найрелевантніших записів збираються у компактний дайджест. Оператор починає роботу з фокусованим контекстом (K' ≪ K, T' ≪ T) і може витягувати додаткові записи на вимогу.
Push-режим (фонове оновлення)
Для простоюючих задач та секторів місії: планований фоновий процес відстежує активність і оновлює записи пам'яті пропорційно до швидкості релевантних змін. При відновленні роботи в секторі pull-запит повертає актуальний контекст без потреби повторного збору інформації.
Частота оновлення визначається як функція трьох сигналів активності:
f_refresh(task) = g( commits-touching-task, comments-on-issue, time-since-last-pull )
де g — монотонно зростаюча функція за кожним аргументом, обмежена зверху одним оновленням на 24 години та знизу — одним оновленням на 7 днів для будь-якої задачі з позначкою LONG-TERM.
Таке обмеження запобігає як надмірному витрачанню обчислювальних ресурсів на високоактивних задачах, так і повному застаріванню контексту для задач з низькою активністю.
Кожне оновлення породжує три артефакти:
- Виконавче резюме змін — генерується мовною моделлю на основі дифів релевантних комітів та коментарів до задачі; містить стислий виклад усіх суттєвих подій від попереднього оновлення.
- Дельта лінеажу інструментів — перелік нових, модифікованих та виведених з експлуатації інструментів із дифами параметричних схем, що дозволяє оператору при поверненні одразу бачити зміни в доступному арсеналі засобів.
- Відкриті питання — нерозв'язані альтернативи та точки прийняття рішень, позначені сумаризатором як такі, що потребують втручання оператора при відновленні роботи над задачею.
За військовою аналогією, цей механізм відповідає автоматизованій підготовці брифінгу передачі зміни: система формує зведення навіть тоді, коли жоден оператор не перебуває на бойовому чергуванні, — щоб наступна зміна при заступанні отримала актуальну обстановку без затримки на повторний збір інформації.
Критично для ротації: між змінами операторів push-режим оновлює контекст місії новими подіями, рішеннями інших секторів, змінами обстановки — так що наступна зміна починає з актуального стану.
Чому необхідні обидва режими
- Pull без push: після тривалої паузи контекст застарілий — оператор отримує рішення тижневої давності.
- Push без pull: надлишковий контекст при кожній сесії — оператор завалений інформацією з усіх секторів.
- Комбінація: push підтримує актуальність, pull фокусує витягування на поточну задачу.
Сигнал корекції витягування
Визначаємо корекцію витягування як корекцію оператора, яка була б непотрібною, якби підсистема пам'яті вчасно подала релевантний контекст.
Приклад: оператор БПЛА коригує маршрут, бо не знав про зміну обстановки в секторі. Якби push-режим оновив контекст місії, корекція не знадобилась би.
Цей сигнал виконує подвійну функцію:
- Метрика якості підсистеми пам'яті: частка корекцій, спричинених витягуванням, вимірює ефективність push/pull-механізмів.
- Додатковий сигнал навчання: кожна корекція витягування маркує конкретний промах системи — що мало бути подано і коли — створюючи датасет для вдосконалення моделі витягування.
Сигнал масштабується з автономністю агента: чим автономніший агент, тим більше рішень він приймає самостійно, і тим більше корекцій виникає через недостатній контекст.
Деталі реалізації
Інструмент запиту до пам'яті
Інтерфейсом витягування контексту для агента слугує єдиний MCP-інструмент workflow_memory_query, що забезпечує уніфікований доступ до всіх трьох рівнів пам'яті.
Вибір єдиного інструменту замість окремих точок доступу до кожного рівня є принциповим проєктним рішенням: агент формулює один запит природною мовою, а підсистема пам'яті самостійно маршрутизує його до релевантних рівнів та агрегує відповіді.
Параметри інструменту:
task_description(рядок, обов'язковий) — природномовний опис поточної задачі або оперативної ситуації.scope(перелічення:all|domain|workflow|practitioner) — рівні пам'яті для запиту. За замовчуванням:all.token_budget(ціле число, за замовчуванням 8 000) — максимальна кількість токенів у зібраному дайджесті.filters(об'єкт, опціональний) — структуровані фільтри: компонент, рівень критичності, часовий діапазон.
Інструмент повертає структурований прозовий дайджест із такими складовими:
- заголовки секцій відповідно до кожного рівня пам'яті, з якого витягнуто записи;
- оцінка релевантності (relevance score) для кожного запису;
- посилання на джерело (провенанс) — конкретний коміт, рішення командира, запис трекера або документ домену.
Формат дайджесту спроєктовано для безпосередньої ін'єкції у контекстне вікно агента без додаткової постобробки. Токенний бюджет забезпечує контрольовану вартість ініціалізації: підсистема ранжує записи за релевантністю і відсікає нижні записи, коли сумарний обсяг перевищує бюджет.
Військова аналогія. У системах управління БПЛА або ситуаційних центрах еквівалентом є уніфікований інтерфейс розвідувального запиту: оператор формулює інформаційну потребу один раз, а система агрегує дані з усіх доступних джерел у єдину розвідувальну зведення. Уніфікований інтерфейс запиту є реалізацією принципу інформаційного злиття (information fusion), що є стандартним елементом архітектур C4ISR.
Оркестратор довгострокових задач
Push-режим реалізований як окремий Docker-контейнер з власним cron-розкладом, ізольований від основного серверу обробки запитів. Архітектурна ізоляція забезпечує дві властивості: (1) фонові процеси оновлення не конкурують за ресурси з активними сесіями операторів; (2) збій оркестратора не впливає на доступність pull-режиму.
Цикл роботи оркестратора:
- Виявлення задач. Оркестратор надсилає запит до трекера задач (Plane API) і отримує список задач із позначкою
LONG-TERM. - Обчислення пріоритету оновлення. Для кожної задачі обчислюється пріоритет оновлення за формулою ().
- Генерація виходів. Для кожної задачі, що підлягає оновленню, оркестратор генерує три структуровані виходи за допомогою LLM-сумаризатора: резюме для командира, дельту лінійки інструментів та відкриті питання.
- Індексація та зберігання. Згенеровані виходи вбудовуються у вектори та зберігаються у колекції Qdrant робочого рівня пам'яті з метаданною позначкою
source: push-refresh.
Військова аналогія. Оркестратор є програмним аналогом автоматизованої підготовки розвідувальних зведень між змінами. Наступна зміна починає роботу не з порожнього аркуша, а з актуального зведення.
Експериментальна верифікація
Платформа верифікації
Архітектура верифікована на платформі юридичного штучного інтелекту LEX AI: 70+ MCP-інструментів, 380M+ записів у pipeline даних, 1 547 об'єднаних pull-запитів за 105 днів роботи одного практика з LLM-агентом. Ця платформа є стрес-тестом підсистеми пам'яті: один оператор з максимальною пропускною здатністю генерує щільний потік рішень, що моделює навантаження автономної місії з обмеженим людським контролем.
Метрики
Чотири кількісні метрики операціоналізують критерії успішності архітектури.
П'ята метрика — частота корекцій витягування — має якісний характер на Фазі 1. Очікувана траєкторія — спадна крива протягом перших 6–8 тижнів розгортання.
Попередні результати
Вартість ініціалізації (Експеримент 1, N=304 сесій).
Медіана вхідних токенів першого виклику 30 115 (середнє 29 693; σ=7 594; P10/P90: 18 540/41 774).
З цього обсягу ~17 600 токенів (59%) витрачаються на створення кешу для CLAUDE.md та системного контексту — завантажуються безумовно для кожної сесії.
Кількість зчитувань файлів в середньому 23,1 (медіана 14, P90: 61), проте 72% сесій мають нуль викликів Read у фазі ініціалізації.
Зростання CLAUDE.md (Експеримент 2, 25 комітів за 85 днів).
Файл CLAUDE.md зріс із 4 099 до 24 148 символів (152 до 474 рядків).
Лінійна регресія: 216,7 симв./день при R² = 0,87.
Коефіцієнт надлишковості (Експеримент 3, N=180 сесій). Медіана коефіцієнта надлишковості — 60% (середнє 56,7%; σ=26,3%). 66% сесій витрачають більше половини зчитувань марно. Зчитування вихідного коду: 78% надлишковість; файли пам'яті: 66,5%. Ця метрика є консервативною проксі: файл може бути зчитаний для контексту без подальшого редагування.
Фаза 0 (міст промпт–коміт) розгорнута з 9 травня 2026 р.; розподільний аналіз потребує 4–6 тижнів збору.
Загрози валідності
Один проєкт, один практик. Архітектура верифікована в контексті одного проєкту та одного практика. Пом'якшення: архітектура є проєктно-агностичною. В контексті управління БПЛА окремий оператор із закріпленим комплексом — типовий сценарій першої лінії.
Змішування з дозріванням кодової бази. Контроль: A/B-оцінювання шляхом увімкнення та вимкнення підсистеми пам'яті на тому самому розподілі задач.
Якість реєстру принципів. На Фазі 1 реєстр курується людиною; точність витягування обмежена якістю курації. Адресується на Фазі 2 напівавтоматичним витягуванням принципів з edit-traces.
Застосовність до управління БПЛА та ситуаційних центрів
Метрики платформи юридичного AI зіставляються з метриками бойових систем:
Обговорення
Від пам'яті програмного агента до пам'яті бойової системи
Запропонована архітектура є доменно-агностичною: трирівнева декомпозиція та дворежимне витягування працюють однаково для юридичного AI та управління БПЛА. Предметний рівень заповнюється даними домену (законодавство або оперативна обстановка), робочий рівень — рішеннями місії, рівень оператора — профілем конкретної людини.
Ключова відмінність — вимоги до латентності: мілісекунди для систем реального часу (БПЛА) проти секунд для юридичного AI. Це впливає на архітектуру push-режиму: для БПЛА оновлення мають відбуватися в реальному часі, а не за розкладом.
Еволюційна кібернетика та адаптація пам'яті
Палагін та ін. (2025) запропонував рамку для аналізу систем, де цілі, обмеження та структури самі еволюціонують — на відміну від класичної теорії управління з фіксованою цільовою функцією.
Підсистема пам'яті місії є саме такою еволюційною системою: контент пам'яті, пріоритети витягування та навіть структура рівнів адаптуються до зміни обстановки. Push-режим є механізмом еволюційного оновлення: він не просто підтримує актуальність, а перебудовує контекст у відповідь на якісні зміни ситуації.
Зв'язок з онтологічно-керованими системами
Три рівні пам'яті природно зіставляються з концепціями онтологічно-керованих систем:
- Предметний рівень = онтологія домену (формальне представлення знань про предметну область).
- Робочий рівень = онтологія процесу управління (рішення, їх обґрунтування, залежності).
- Рівень оператора = модель когнітивного профілю (патерни рішень, зони уваги).
Дворежимне витягування розширює цю аналогію: pull-режим відповідає активному запиту до онтології, push-режим — автоматичному оновленню онтології при зміні фактів про світ. Палагін та ін. (2024) демонструють, що інтеграція нейромережевих та онтолінгвістичних підходів дає кращі результати, ніж кожна парадигма окремо — наша гібридна схема витягування (семантичне + структуроване) є реалізацією цього принципу.
Пам'ять як субстрат навчання з підкріпленням
Та сама інфраструктура, яка дозволяє одному практику виконувати сотні сесій протягом кількох місяців, генерує сигнал переваг, придатний для навчання з підкріпленням на основі зворотного зв'язку від людини (RLHF). Пам'ять і дані переваг є двома проєкціями одного і того ж довгострокового робочого процесу: кожна корекція після витягування є одночасно збоєм підсистеми пам'яті та сигналом вирівнювання.
Ця двоїстість не є випадковою: вона становить архітектурну тезу. Підсистема пам'яті не лише споживає дані вирівнювання — вона їх продукує. У бойовому контексті кожна корекція оператора під час управління БПЛА — зміна маршруту, перепризначення цілі — є одночасно записом пам'яті місії та зразком для навчання системи.
Пам'ять як поверхня масштабованого нагляду
Підсистема пам'яті виконує подвійну функцію: обслуговує агента під час виконання місії та генерує сигнал нагляду під час узгодження. Із зростанням автономності агента відношення спостережуваних результатів до внутрішніх рішень агента падає. Нагляд на рівні результатів стає вузькосмуговим каналом.
Підсистема пам'яті змінює цю динаміку. Кожне витягування є спостережуваною подією з відомим контекстним вікном, відомим результатом витягування та подальшим слідом редагування. Щільність сигналу на одиницю активності є вищою, ніж при RLHF на рівні результатів: кожна сесія генерує множину пар «витягнуто X, скориговано Y».
Поведінка пам'яті при ескалації подій
Попередні підсекції розглядають підсистему пам'яті в режимі стаціонарного навантаження. Окремого аналізу потребує поведінка при ескалації — каскадному зростанні кількості одночасних подій, коли інформаційне навантаження на оператора та агента зростає експоненціально.
Каскадні сценарії. В бойовому контексті ескалація виникає при одночасному обстрілі кількох секторів, радіоелектронному придушенні каналів зв'язку та втраті контакту з частиною рою БПЛА. У програмному контексті — при каскадних виробничих інцидентах у кількох сервісах одночасно.
Деградований режим. Коли частота подій перевищує пропускну здатність обробки, підсистема пам'яті має переключитися з семантичного витягування на тріаж на основі критичності. Формально, функція ранжування змінюється з
score(e) = sim(q, e) → score(e) = α · criticality(e) + (1-α) · sim(q, e)
де α → 1 при зростанні частоти подій.
Ротація під час кризи. Найгірший сценарій для підсистеми пам'яті — ротація оператора посеред ескалації. Дайджест для нового оператора повинен передати не лише статичний стан, а й динаміку: що ескалює, що каскадує, які зв'язки між подіями виявлені, які рішення прийняті попереднім оператором. Це вимагає розширення формату дайджесту від плоского переліку фактів до темпоральної структури з причинно-наслідковими зв'язками.
Повна реалізація деградованого режиму виходить за межі поточної роботи (див. обмеження (iii) у секції), проте архітектурні точки розширення — функція ранжування з параметром критичності та черга пріоритетів у push-режимі — є частиною проєкту.
Узагальнення на команди
Архітектура обслуговує одного практика. Багатооператорне розгортання породжує три виклики: по-перше, реєстр принципів стає багатозаписувачем з необхідністю вирішення конфліктів; по-друге, рівень оператора потребує індивідуальних представлень; по-третє, записи пам'яті можуть містити контекст, чутливий до рівня доступу.
Трирівнева декомпозиція спроєктована для підтримки цих розширень: предметний рівень є спільним, робочий підтримує обмежені представлення через фільтрацію метаданих, а рівень оператора є за природою індивідуальним.
Чим це не є
Архітектура не є заміною моделей з довгим контекстним вікном — вона є витягувальним субстратом, що зменшує обсяг контексту, який повинна обробити модель. Це не є граф знань (не використовує RDF-трійки і не надає SPARQL-інтерфейс). Це не є корпоративна система управління знаннями (Enterprise KMS). Це витягувальний субстрат, оптимізований для одного операційного режиму — довгострокової агентної композиції малою кількістю практиків.
Військова аналогія. Це не є повноцінна система C4ISR. Це підсистема пам'яті, що інтегрується в існуючу інфраструктуру управління — компонент, що забезпечує безперервність інформаційного контексту для тих підсистем, які приймають рішення.
Обмеження
- Верифікація на одній платформі. Архітектура верифікована на юридичному AI, не на БПЛА або ситуаційному центрі. Доменна агностичність — гіпотеза, що потребує перевірки.
- Одиничний оператор. Усі вимірювання отримані від одного практика. Поведінка при багатооператорній ротації потребує окремого дослідження.
- Push-режим та деградований режим. Фонове оновлення описане архітектурно, але повна реалізація ще не завершена. Тріаж на основі критичності є проєктним, не реалізованим.
- Латентність. Вимірювання латентності витягування отримані для не-реального часу. Для БПЛА потрібна оптимізація під мілісекундні вимоги.
Висновки
Запропоновано архітектуру підсистеми персистентної пам'яті для автономних агентних систем, що виконують довгострокові місії з ротацією операторів.
Основні результати:
- Трирівнева декомпозиція (предметна область / робочий процес / оператор) забезпечує розділення контексту за семантикою витягування та терміном життя.
- Дворежимне витягування (pull + push) вирішує проблему безперервності контексту: pull фокусує ініціалізацію на поточну задачу, push підтримує актуальність для простоюючих задач та ротації операторів.
- Сигнал корекції витягування надає метрику якості підсистеми пам'яті, яка масштабується з автономністю агента та слугує додатковим джерелом навчального сигналу.
Базові вимірювання на 304 сесіях підтверджують наявність проблеми: 60% надлишковість контексту при ініціалізації, що зростає лінійно з віком проєкту.
Архітектура є доменно-агностичною і застосовна до систем управління БПЛА та ситуаційних центрів, де ротація операторів є штатною процедурою, а безперервність контексту рішень — критичною вимогою бойової готовності. Окремо обговорено поведінку при ескалації подій: деградований режим із тріажем на основі критичності та проблему ротації посеред кризи.
Подальші дослідження: (1) верифікація на багатооператорній когорті; (2) реалізація push-режиму в реальному часі; (3) інтеграція з онтологічно-керованими системами підтримки рішень для формалізації робочого рівня пам'яті; (4) реалізація деградованого режиму та емпірична верифікація тріажу на основі критичності.