Создание доверяемых агентных рабочих процессов с DSL и Ash PL

Почему механизм имеет значение

Два системы могут выдать идентичный результат, но уровень доверия к ним будет разным в зависимости от внутреннего процесса. Например, вывод от устаревшей модели и от современной системы, использующей критику и переработку, воспринимаются по-разному.

Механизм — это дизайнерский выбор, который зависит от задачи, домена и пользователя. Когда вы инвестируете в проектирование механизма, вы создаёте реальное доверие, отличая ваш продукт от простого генератора ответов.

Совет: Фокус на прозрачность процесса вместо только результата — вот что создаёт уверенность пользователей.

Три ключевых требования системы

При разработке исследовательского агента Elicit выделила три основных критерия, которые определяют качество рабочего процесса:

• Legibility (понятность) — процесс должен быть ясным для людей и других агентов (например, для критики). Это значит, что код должен быть прозрачен и легко проверяем.
• Fidelity (сохранение целостности) — добавление новых шагов или направлений в работу не должно приводить к «дрейфу» от первоначальной цели пользователя. Итерации должны сохранять исходный смысл.
• Faithful execution (точное выполнение) — система обязана строго следовать утверждённому плану действий без отклонений.

Эти требования привели к созданию специального языка (DSL), ориентированного на конкретный домен работы.

Ash PL: специальный язык для агентов

Ash PL — это предметно-ориентированный язык, разработанный в Elicit для управления агентными рабочими процессами в научных исследованиях и принятии решений.

Отличительные черты Ash PL

• Неполнота по Тьюрингу — нет циклов, рекурсии, мутации. Это чисто функциональный реактивный язык, обеспечивающий полную предсказуемость выполнения.
• Ограниченное подмножество Python — убраны ненужные возможности, добавлены доменно-специфичные примитивы (поиск академических статей, клинических trials, данные исследований).
• Статическая типизация — позволяет быстро находить ошибки и безопасно перерабатывать код без риска регрессии.

Пример: программа на Ash PL описывает процесс конкурентного анализа — поиск в сети, объединение результатов, обогащение источников и построение итоговой таблицы.

Важно: Отсутствие циклов и рекурсии гарантирует, что программа всегда завершится и её выполнение можно полностью проверить и воспроизвести.

Архитектура системы на базе DSL

Система построена вокруг цикла «написание → интерпретация → переработка» кода на Ash PL, обеспечивая каждый шаг как люди, так и автоматизированные компоненты.

Ключевые компоненты архитектуры

Паттерн Event Sourcing позволяет полностью воспроизвести любое состояние системы, а кэширующее хранилище — это ключевой рычаг производительности. При итеративной разработке ранее вычисленные части не пересчитываются благодаря кэшу, что значительно ускоряет добавление новых слоёв анализа.

Демонстрация: картографирование исследовательского ландшафта

Запрос

«Картографировать компании и институты, инвестирующие в фундаментальные модели для биологии».

Процесс, управляемый Ash PL

1. Уточнение задачи у пользователя (широкий ландшафт vs. конкретика).
2. Последовательное выполнение шагов: поиск академических статей, веб-поиск, фильтрация по релевантности, обогащение данных.
3. Создание артефакта — итоговой таблицы с организациями и их атрибутами (разработанные модели, модальности, активные коллаборации).

Как обеспечивается доверие

• Просмотр кода — каждый артефакт сопровождается кодом Ash PL, что обеспечивает полную проверяемость процесса.
• Визуализация процесса — графическое представление шагов автоматически генерируется из Ash PL, показывая пользователю весь путь выполнения.
• Итеративное развитие — пользователь добавляет новые слои анализа на естественном языке. Система расширяет исходную программу, но благодаря кэшированию ранее вычисленные части не пересчитываются.

Результат: таблица из 1000+ компаний и институтов с полной прослеживаемостью источников и логики выбора.

Выводы и практические рекомендации

DSL — не универсальное решение, а специализированный инструмент, который стоит выбирать, если ваши цели совпадают с требованиями: прозрачность, целостность, надежность.

Компромисс подхода

Elicit фокусируется на глубине, качестве и надежности, что требует больше времени, чем быстрый генератор ответов. Это не подходит для задач, где скорость критичнее доверия. Выбирайте DSL, если вам нужна проверяемость и воспроизводимость.

Что нужно учесть при реализации

1. Создание DSL (желательно на основе популярного языка с известной семантикой).
2. Эргономика для агента (обертка для изменения моделей и harness).
3. Обработка прерываний (возможность добавлять новые запросы без остановки процесса).
4. Восстановление сессий (rehydration — загрузка состояния из Event Log).
5. Изоляция credentials (безопасное хранение и управление ключами доступа).
6. Управление выводом моделей (парсинг, валидация, обработка ошибок).
7. Управление состоянием через Event Sourcing (полная история для аудита).
8. Инвестиции в оценку (eval) — критически важно в сложных динамических системах.

Главный вывод: Инвестируйте в проектирование механизма работы вашей системы. Именно детальный, проверяемый и воспроизводимый процесс создает реальное доверие у пользователей и отличает вашу систему от конкурентов.