Інженерія контексту для дослідницького агента Quant: рівні доведення та сховища даних

Визначення того, у що може довіряти агент

Уявіть собі дослідницьку систему на основі ШІ, створену для конкурсу з квантових алгоритмів WorldQuant BRAIN. Ще до появи спеціалізованих агентів, перевірок протягом життєвого циклу чи автономних циклів існує більш базова проблема проектування: які твердження система може вважати істинними? Сировина надходить у чотирьох формах, які майже не мають спільного.

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

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

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

Три рівні доказів

„Доведення“ має практичне значення. Для будь-якого твердження потрібно з’ясувати, які докази є достатніми, хто несе за них відповідальність та що дозволяє їх спростувати. Ці питання вирішуються за допомогою трьох рівнів.

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

L2 фіксує те, що система насправді бачила. Сюди належать результати симуляцій, щоденні показники PnL, сьогоднішній портфель, перевірки платформи, операційні події та найновіший стан табелю лідерів. Кожне вимірювання супроводжується позначкою часу спостереження. Перезапуск нічого не перезаписує – він створює нове спостереження, тому історія ніколи не впорядковується згодом.

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

Порядок цих рівнів не є суворим: L1 завжди має пріоритет перед L2, а L2 — перед L3. Кожен рівень відповідає на інший тип запитань. У разі суперечки щодо фактів між джерелами переважає найсильніше пряме джерело, тож офіційне правило має вищий пріоритет ніж парафраз у запиті агента, а обґрунтована відповідь — ніж те, чого можна було очікувати з книги. Однак щодо питання про те, що спробувати далі, правила та показники не можуть дати відповіді. Саме тоді потрібен L3, щоб зробити обґрунтований вибір.

У цій діаграмі відстежуються три ідеї. Ефект відхилення після оприлюднення фінансових результатів не було усунуто через його спотворювач; натомість було виявлено проблемну конструкцію, тож ідею було перебудовано на основі корекцій аналітиків, і було подано дві версії. Ідея, пов’язана з порівнянням акцій, спочатку ґрунтувалась лише на припущеннях без жодних доказів, проте все одно пройшла перевірку. Ідея, пов’язана з «годинником дивідендів», провалила всі десять конструкцій, тож урок полягав у обмеженні припущень лише датами виплати дивідендів. Зелені квадрати пройшли перевірки платформи, червоні — провалилися, сірі не мають жодних записів про перевірки, а квадрати з кільцем були подані для розгляду.

Одна база даних може містити як самі показники вимірювань (L2), так і їхні оцінки окремих осіб (L3), що означає, що рівень приписується самому твердженню, а не місцю його зберігання. Відповідно, корисний запис контексту є багатшим за звичайний текст. Він має містити саме твердження, його епістемічний рівень, джерело, власника, область застосування, час спостереження чи перевірки, ступінь невизначеності, стабільний ідентифікатор та будь-які докази, які можуть його скоригувати. Для фактів, які змінюються з часом, корисним є подвійний часовий рядок: коли щось було істинним та коли система про це дізналася. API, які відповідають з запізненням та доповнюють історичні дані, підкреслюють значимість цієї прогалини.

Контекст насправді є невеликою платформою даних

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

Як тільки існують рівні доказів, стає очевидним ще один момент: контекст — це не єдиний корпус даних. Він поводиться як невелика платформа для обробки даних. Найбільшою частиною є облікова книга досліджень, яка на перевіреній робочій станції є транзакційною базою даних SQLite. Називати її таблицею експерименту — це недооцінка, адже вона виконує функцію облікової книги доказів, що містить кілька груп записів. Одна група стосується цілей дослідження, тобто механізмів, гіпотез, прогнозів та історії їх реалізації. Інша група присвятована вимірюванням — вона зберігає відповіді платформи, статистику зразків даних, перевірки, щоденні показники PnL та метрики стрес-тестів. Третя група стосується інтерпретації — тут зберігаються пояснення, уроки та елементи, які дозволяють спростувати теорії. Четверта група пов’язана з управлінням — вона відстежує потенційні рішення, схвалення та те, що відбувалося під час подання заявок. Останнім є аналіз, який має матеріальну форму: дельти портфеля, екрани кореляції, кеші шаблонів та підсумки тестів на стійкість, усі з яких можна відтворити на основі канонічних вхідних даних.

Під час аудиту було виявлено неузгодження. У документі з проектування зазначено, що щоденні показники PnL були перенесені до файлів формату Parquet, але база даних все ще зберігає кожен рядок. Документ є припущенням (рівень L3), а база даних — спостереженням (рівень L2), і у разі конфлікту переважає спостереження.

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

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

Файлова система також вважається системою даних. Репозиторій зберігає недоторкані документи платформи, книги, статті та генеровані звіти, і завантажувати все це в пам’ять було б помилкою, оскільки їхні життєві цикли відрізняються. Документи платформи ніколи не змінюються. Специфікації є пріоритетами проектування під контролем версій. Звіти є похідними даними, які потребують заданих вхідних даних та способу їх повторної генерації. Файли в пам’яті — це короткі, читабельні посилання на універсальні уроки. Файли черги, кеш та журнали — це тимчасовий стан роботи, тоді як бінарні файли моделей, експорти PnL та великі знімки краще зберігати в об’єктному сховищі, а не в Git.

Історії невдач є показовими. Альфа-алгоритм з високою ефективністю ледь не було відхилено, оскільки облікова книга стверджувала, що всі перевірки пройшли успішно, тоді як скрипт читав файл з результатами, у якому було значення Sharpe 0. Один із ранніх переможців зовсім не мав записів про рішення, поки через шість тижнів процес узгодження не надав їх. Рішення про ставки проти бета-алгоритму існувало лише у файлі з інформацією у форматі Markdown, тож сама облікова книга нічого не могла зробити, щоб запобігти повторній спробі.

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

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

Механізми виступають як зв’язок між двома базами даних. У графі вони представлені як економічні ідеї разом із їхніми джерелами, а в обліковій книзі — як теги до кожної гіпотези та кандидата, які їх застосували. Емпіричні підсумки можна пов’язати з вузлами графа для полегшення навігації, але це лише дзеркала, а справжні дані знаходяться у базі даних експериментів. Тому хороший пакет контексту створюється шляхом об’єднання інформації з різних систем. Він поєднує невелику групу сусідніх вузлів графа, інформацію про походження джерел, поточні емпіричні підсумки, нещодавні невдачі та обмеження платформи. Модель не потребує всього графа чи кожної рядки з даними PnL. Корисним є найкоротший шлях доказів до конкретного рішення.

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

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

Якщо підсумувати підхід до проектування, то граф — це контекст, реєстр — це контекст, а зв’язок між ними також є контекстом. Цей зв’язок потребує такої ж інженерної уваги, як і код моделі.

Де це перетинається з інженерією керування

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

Це позначає межу між інженерією контексту та інженерією керування. Керування контекстом відповідає за рівні від L1 до L3: воно зберігає джерела, вимірювання, попередні дані, походження, часові мітки, обсяг та стабільні ідентифікатори. L4, агентне керування, вирішує, які докази потрібно отримати, скільки даних дозволено після переходу між етапами, який спеціаліст їх отримає та які висновки є обґрунтованими. Нижче знаходяться вихідний код (L5), локальна інфраструктура (L6) та розподілена інфраструктура (L7). Ці шари бездоганно виконають неправильне рішення, але не мають права вирішувати, чи був вхідний даний правилом, спостереженням чи переконанням.

Рання версія стерла це розділення. Основний файл інструкцій перетворився на вікі з 627 рядками, яке поєднувало правила турніру, поточний статус, методи та уроки попереднього дня. Після того, як його скоротили до невеликого формату, інформація надходила до агента через чотири канали. Короткий шар залишається завантаженим постійно. Пакет запуску передає нові уроки та попередження. Правила, специфічні для певної області, додаються лише тоді, коли завдання стосується цієї області, а спеціалістичні ролі з їхніми „спогадами“ завантажуються за потреби.

Одна заявка, простежена через канали

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

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

Кожен етап має свою мету. Рівень L2 реєстру отримує необроблені результати платформи та нормалізовані показники. Операційні події, такі як початок виконання, виклики інструментів, повторні спроби та трафік координації, зберігаються у сховищі подій. Якщо результат дає урок чи інформацію про можливі помилки, він зберігається у рівні L3. Об’єднані дані графа формуються шляхом узгодження з реєстром та ніколи не піддаються ручній обробці, тоді як великі серії даних про PnL, графіки та адаптовані моделі стають об’єктами, на які посилаються інші записи.

Обидва альфа-варіанти, які були подані, починалися з пакетів, які вже містили необхідні дані. Одна група раніше вдосконалила портфель, а інша ідея використала вже існуючу структуру, яка раніше дала некорелювані альфа-результати. Ідея зі зміною рейтингу також отримала пакет, неперевірену клітинку на карті можливостей та попереднього переможця для наслідування, проте усі 18 її конструкцій все одно зазнали невдачі.

Етапи розвитку інфраструктури

Переміщувати все одночасно було б помилкою. Кожен канал змінюється у свій час, а шлюз відкривається лише тоді, коли існує вимірюваний тригер, який це виправдовує. На правій стороні показаний єдиний надійний шлях запису (commit, outbox, exporter, projection), на відміну від подвійного запису, який створює дві суперечливі версії даних.

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

Фаза 0 полягає у приведенні дизайну у відповідність із реальністю: або завершити незавершену міграцію PnL, або свідомо скасувати її, а потім автоматизувати аудит, який порівнює документацію з даними у реальному часі. Фаза 1 передбачає переміщення великих об’єктів даних — щоденні дані PnL, графіки, файли моделей, великі звіти та знімки баз даних — у об’єктне сховище, сумісне з S3; при цьому дані PnL розділяються на стиснуті частини формату Parquet, підтримувані незмінними маніфестами, контрольними сумами та правилами життєвого циклу. Фаза 2 передбачає переміщення метаданих лише тоді, коли конкурентність змушує це зробити. Коли віддалені працівники, кілька машин чи співробітники мають записувати дані одночасно, журнал транзакцій та хранилище подій переміщуються у керований PostgreSQL як окремі бази даних або принаймні окремі схеми з власними правилами зберігання. Фаза 3 включає використання інструментів MLOps як допоміжних засобів, а не як джерела істини; тому такі інструменти, як Weights & Biases чи MLflow, можуть допомогти, не замінюючи журнал транзакцій чи граф структур даних. Фаза 4 відокремлює оркестрацію від стану: дослідники працюють у контейнерах із незмінними маніфестами завдань, тоді як черга чи двигун робочих процесів розподіляє ідемпотентні завдання з функціями оренди, повторних спроб та таймаутів. Фаза 5 забезпечує більш детальну аналітику лише тоді, коли обсяг роботи це дозволяє. Формат таблиць у стилі lakehouse, спеціалізована база даних графів чи платформа стрімінгу можуть згодом виявитися корисними, але лише тоді, коли певні запити починають створювати проблеми — наприклад, сканування мільярдів записів, багато одночасних перебірок графів, еволюція схеми у великих колекціях формату Parquet чи споживачі подій із низькою затримкою.

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

Пов’язана література

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