если модель — это всего лишь провайдер событий, как построить детерминированную систему, которая переживёт смену Claude → GPT → Qwen → MiMo без переписывания логики? И выбирать в итоге ту, которая актуальна с точки зрения цены на прямо сейчас?
Забавно, репо топикстартера даёт 39/100, мой репо написанный практически полностью АИ: 14/100. Я не понимаю цель таких исследований, кроме самоутверждения. Вроде как доказано, что АИ умеет писать код и даже недавно был отчёт антропик вроде про это. В общем, снёс расширение. Но за опыт спасибо
Да, именно. Сам протокол вызова инструментов обычно не хранит состояние диалога и не управляет логикой работы модели — он лишь даёт стандартизированный способ вызвать инструмент и вернуть результат обратно в контекст.
Поэтому интереснее выглядит подход, где поверх инструментов появляется явный конечный автомат: модель отвечает только за генерацию решений, а порядок шагов, проверки, откаты и условия переходов задаются отдельно. Такая архитектура делает систему гораздо более предсказуемой, воспроизводимой и наблюдаемой.
Возможно, именно в эту сторону и будут развиваться агентные системы: меньше свободы в управлении процессом и больше контролируемой логики исполнения с понятным аудитом каждого шага.
Мы можем дать вам полностью детерминистический, воспроизводимый и масштабируемый evaluation framework для Алеметрии.
nano-vm берёт на себя всю оркестрацию, трассировку, параллелизм, A/B-тестирование и мокинг, а вы сосредотачиваетесь на научной части (кодбук, правила B1, интерпретация результатов).
Это позволит вам:
Значительно увеличить размер корпуса (с 10 кейсов до сотен).
Проводить систематические эксперименты по снижению зависимости от судьи.
Публиковать не только методику, но и полностью воспроизводимые трейсы экспериментов.
Да, очень близко к тому, над чем мы сейчас работаем. Главная проблема современных AI-агентов в том, что они часто действуют хаотично: состояние скрыто внутри промптов, решения трудно проверить, а ошибки почти невозможно нормально воспроизвести. Мы как раз строим систему, где поведение агента становится более предсказуемым и контролируемым — с явным состоянием, логом всех действий и возможностью восстановить весь процесс шаг за шагом. Я бы хотел посмотреть формальную часть ваших исследований.
Хороший разбор, по сути вы описали связку “NL → intent → deterministic execution + UI actions”.
Мы пошли дальше в том же направлении: LLM у нас не участвует в исполнении и не является слоем логики — только строго ограниченный intent/candidate слой.
Все действия (данные, UI, инструменты) проходят через детерминированный execution layer на FSM + StepResult контракте, где система не интерпретирует, а исполняет граф состояний.
Фактически то, что у вас реализовано как прикладной модуль внутри панели, у нас вынесено в универсальное ядро исполнения.
Посмотрел, спасибо! Отличная работа — граф действительно решает часть проблем vector search. Особенно интересно, что можно практически использовать: извлечение триплетов, построение knowledge graph, обход через PPR — это реально прикладные вещи. Но это всё ещё попытка научить поиск “думать”. Любое решение всё равно принимает LLM — просто на более структурированном контексте.
Как понять, что система начинает деградировать до появления плохих ответов?
если модель — это всего лишь провайдер событий, как построить детерминированную систему, которая переживёт смену Claude → GPT → Qwen → MiMo без переписывания логики? И выбирать в итоге ту, которая актуальна с точки зрения цены на прямо сейчас?
Для конфиденциального только своё поднимать, и я бы в сторону Яндекс тем более не смотрел
Забавно, репо топикстартера даёт 39/100, мой репо написанный практически полностью АИ: 14/100. Я не понимаю цель таких исследований, кроме самоутверждения. Вроде как доказано, что АИ умеет писать код и даже недавно был отчёт антропик вроде про это. В общем, снёс расширение. Но за опыт спасибо
Да, именно. Сам протокол вызова инструментов обычно не хранит состояние диалога и не управляет логикой работы модели — он лишь даёт стандартизированный способ вызвать инструмент и вернуть результат обратно в контекст.
Поэтому интереснее выглядит подход, где поверх инструментов появляется явный конечный автомат: модель отвечает только за генерацию решений, а порядок шагов, проверки, откаты и условия переходов задаются отдельно. Такая архитектура делает систему гораздо более предсказуемой, воспроизводимой и наблюдаемой.
Возможно, именно в эту сторону и будут развиваться агентные системы: меньше свободы в управлении процессом и больше контролируемой логики исполнения с понятным аудитом каждого шага.
ФСМ для критичных инструментов и ХИТЛ для совсем медного таза типа удали все
Мы можем дать вам полностью детерминистический, воспроизводимый и масштабируемый evaluation framework для Алеметрии.
nano-vm берёт на себя всю оркестрацию, трассировку, параллелизм, A/B-тестирование и мокинг, а вы сосредотачиваетесь на научной части (кодбук, правила B1, интерпретация результатов).
Это позволит вам:
Значительно увеличить размер корпуса (с 10 кейсов до сотен).
Проводить систематические эксперименты по снижению зависимости от судьи.
Публиковать не только методику, но и полностью воспроизводимые трейсы экспериментов.
Как вы это реализуете? Примеры кода по текущему проекту будут? Потому что препринт открылся один раз, не скачался и совсем замолчал сайт
А вы пробовали задать задачу про яблоко одной и той же сетке 100 раз, в приватных чатах?
Да, очень близко к тому, над чем мы сейчас работаем. Главная проблема современных AI-агентов в том, что они часто действуют хаотично: состояние скрыто внутри промптов, решения трудно проверить, а ошибки почти невозможно нормально воспроизвести. Мы как раз строим систему, где поведение агента становится более предсказуемым и контролируемым — с явным состоянием, логом всех действий и возможностью восстановить весь процесс шаг за шагом. Я бы хотел посмотреть формальную часть ваших исследований.
Хороший разбор, по сути вы описали связку “NL → intent → deterministic execution + UI actions”.
Мы пошли дальше в том же направлении: LLM у нас не участвует в исполнении и не является слоем логики — только строго ограниченный intent/candidate слой.
Все действия (данные, UI, инструменты) проходят через детерминированный execution layer на FSM + StepResult контракте, где система не интерпретирует, а исполняет граф состояний.
Фактически то, что у вас реализовано как прикладной модуль внутри панели, у нас вынесено в универсальное ядро исполнения.
Посмотрел, спасибо! Отличная работа — граф действительно решает часть проблем vector search. Особенно интересно, что можно практически использовать: извлечение триплетов, построение knowledge graph, обход через PPR — это реально прикладные вещи. Но это всё ещё попытка научить поиск “думать”. Любое решение всё равно принимает LLM — просто на более структурированном контексте.
Пропускной портам не хватит если делить. Просто паралелить мелкие - оркестратор нужно будет пилить.