Skip to main content
LLMLoRAAI-архитектура

Doc-to-LoRA від Sakana AI: LLM, які «вчаться» за секунди

Sakana AI представили Doc-to-LoRA та Text-to-LoRA: гіпермережі, що генерують ваги LoRA-адаптера прямо з документа чи текстового опису за один прохід, без класичного донавчання. Для бізнесу це означає майже миттєву спеціалізацію LLM під нову інструкцію, регламент чи продукт, а також значно дешевшу автоматизацію ІТ-процесів.

Технічний контекст

Я уважно розібрав Doc-to-LoRA (D2L) та Text-to-LoRA (T2L) від Sakana AI і побачив зсув, який рідко трапляється в адаптації LLM: замість оптимізації LoRA через градієнтний спуск вони пропонують генерувати ваги LoRA гіпермережею за один forward-pass.

Тобто «навчання» переноситься на етап мета-тренування гіпермережі, а в продакшені ми отримуємо адаптер майже миттєво — з документа або короткого опису завдання. За заявленими даними, це вкладається в < 1 секунди на генерацію адаптера, без циклів оптимізації та без збору датасету під кожен конкретний кейс.

T2L працює від текстового опису: енкодер робить embedding завдання, далі гіпермережа видає повний набір LoRA-матриць по шарах (в одному з прикладів йдеться про rank-8 і порядок мільйонів параметрів). D2L йде від документа: вони використовують Perceiver-подібну cross-attention схему, щоб перевести активації базової моделі в LoRA-матриці фіксованої форми.

Мене особливо зачепила механіка для довгих документів: D2L чанкує вхід на K сегментів, генерує LoRA рангу r для кожного чанка, потім конкатенує за виміром рангу, отримуючи ефективний ранг r×K. Архітектурно це означає лінійне масштабування «поглиненого» тексту без зміни самої гіпермережі.

У порівнянні з класичним підходом «засунемо документ у контекст і будемо питати» вони також підсвічують економіку пам'яті: для довгого контексту різниця в KV-cache може бути драматичною (умовні гігабайти проти десятків мегабайт). Це не магія — це зміна носія знання: з контексту в параметри адаптера.

Вплив на бізнес та автоматизацію

Для мене це не «one-click fine-tuning». Це нова примітивна операція в AI-архітектурі: синтез адаптера зі знання. І саме так я б її і проєктував у продакшені: як окремий сервіс, який за подією (новий документ/правило/каталог) генерує LoRA та публікує її в реєстр адаптерів.

Хто виграє першим? Команди, які будують ШІ автоматизацію навколо джерел, що швидко змінюються: продажі (оновлення офферів), сапорт (нові баги/патчі), комплаєнс (регуляторика), виробництво (інструкції, карти режимів). Там класичне впровадження штучного інтелекту найчастіше буксує на вартості підтримки актуальності.

Хто програє? Будь-які процеси, де «знання» не можна просто стиснути в LoRA без втрати сенсу: спірні юридичні інтерпретації, завдання з високим ризиком галюцинацій, домени, де важлива трасованість до джерела. У таких системах я все одно залишаю RAG і цитування, а D2L/T2L розглядаю як прискорювач для стійких, повторюваних навичок.

У наших проєктах в Nahornyi AI Lab я бачу практичний гібрид: RAG відповідає за перевірюваність і свіжість, а «швидкі LoRA» — за поведінкову спеціалізацію (формат відповіді, стиль рішень, типові дії агента) і за зменшення вартості довгого контексту. Але це вимагає дисципліни: версіонування адаптерів, тестів на регресію та політики відкоту.

Стратегічне бачення та глибокий розбір

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

Другий момент — стекінг LoRA. Я сприймаю це як модульність компетенцій: окрема LoRA на продукт, окрема на юридичний тон, окрема на інструментальні дії. Якщо додавання/конкатенація адаптерів стане стабільною практикою, ми наблизимося до «маркетплейсу навичок» всередині компанії, де навички не перенавчаються місяцями, а збираються як залежності.

При цьому я б не продавав це як заміну класичному файнтюнінгу. Мета-тренування гіпермережі — дороге, а узагальнення на дійсно нові домени може просідати. На практиці я очікую, що ринок розділиться: великі гравці будуть навчати гіпермережі під свої бібліотеки завдань і адаптерів, а компанії реального сектора будуть купувати/розгортати готові рішення і вбудовувати їх у свою ШІ інтеграцію.

Якщо ви плануєте зробити ШІ автоматизацію «живою» — такою, що реагує на документи та зміни правил без тижневого циклу ML — я б уже зараз закладав в архітектуру місце під генерацію адаптерів, реєстр LoRA та контроль якості. Інакше через півроку ви впретеся в стелю вартості контексту та ручного супроводу.

Цей розбір підготував я, Вадим Нагорний — провідний фахівець Nahornyi AI Lab з AI-архітектури, впровадження ШІ та автоматизації за допомогою ШІ в реальному секторі.

Якщо ви хочете застосувати Doc-to-LoRA/T2L-подібний підхід у вашому контурі (агенти, сапорт, регламенти, виробництво), напишіть мені: я допоможу спроєктувати архітектуру, оцінити ризики, вибрати стек і довести рішення до промислової експлуатації разом із командою Nahornyi AI Lab.

Share this article