Останнім часом я трохи замислююся над безперервним навчанням, особливо щодо довготривалих агентів (і проведення кількох експериментів з іграшками з MLX). Статус-кво швидкого ущільнення у поєднанні з рекурсивними субагентами насправді надзвичайно ефективний. Здається, ми можемо зайти досить далеко. (Ущільнення запиту = коли контекстне вікно наближається до повного значення, модель генерує коротший підсумок, а потім починає з нуля з використанням резюме. Рекурсивні підагенти = розкладають завдання на менші для роботи з скінченними контекстними вікнами) Рекурсивні субагенти, ймовірно, завжди будуть корисними. Але швидке ущільнення здається трохи неефективним (хоч і дуже ефективним) прийомом. Є ще дві альтернативи, про які я знаю: 1. Онлайн-налаштування та 2. Техніки, засновані на пам'яті. Онлайн-налаштування: навчати деякі адаптери LoRA на даних, які модель отримує під час розгортання. Загалом я менш оптимістичний щодо цього. Окрім інженерних викликів розгортання індивідуальних моделей / адаптерів для кожного випадку використання чи користувача, існують деякі фундаментальні проблеми: - Онлайн-налаштування є за своєю суттю нестабільним. Якщо тренуватися на даних у цільовому домені, можна катастрофічно знищити можливості, які не націлилися. Один із способів обійти це — зберігати змішаний набір даних із новим і старим. Але це досить швидко ускладнюється. - Як взагалі виглядають ці дані для онлайн-налаштування? Чи генеруєте ви пари Q/A на основі цільового домену для навчання моделі? Також виникає проблема пріоритезації інформації у суміші даних за умови скінченної ємності. Техніки на основі пам'яті: по суті, політика збереження корисної пам'яті та відкидання зайвого. Це набагато більше схоже на те, як люди запам'ятовують інформацію: «використовуй або втратиш». Для цього потрібно лише кілька речей: - Політика виселення/утримання. Щось на кшталт «зберігати пам'ять, якщо вона була доступна хоча б раз за останні 10 тисяч токенів». - Політика має бути ефективно обчислюваною - Місце для зберігання та доступу моделі до довготривалої пам'яті. Можливо, мало доступного кешу KV буде достатнім. Але для ефективного доступу до великої пам'яті може бути ієрархічна структура даних.