С разделением на классы согласен, но не с тем что сравнение бессмысленно. В эксперименте разные harness выполняют одну задачу с одинаковыми моделью, средой, MCP-инструментами и оценкой - это позволяет сравнить их влияние на результат.
По исходникам базовый цикл у них одинаков: задача -> системный prompt -> tool calls -> выполнение -> проверка. Совпадают TODO-статусы, shell/file tools, форматы patch/edit и правила plan -> implement -> verify; некоторые формулировки совпадают дословно. Поэтому специализация различается, но их Agent Loop сопоставим.
Провал OpenCode на памяти это не оценка coding agent в целом, а конкретное архитектурное ограничение. Например, в Qwen Code полноценная Auto-Memory включена по умолчанию.
Сравнение внутри отдельных классов тоже полезно. Но наша цель не общий рейтинг, а карта применимости harness по разным классам задач.
Сильно близкая по духу платформа, но цели разные: у нас фокус на удобном сравнении связок "модель + harness", у Harbor на оценке и тюнинге агента/промптов.
Там, где есть пересечения, я бы выделил такие различия:
1. Harness у нас - черный ящик снаружи. Агент живет в отдельном контейнере и достает до песочницы только через MCP-мост, Harbor же ставит агента внутрь среды задачи. Эта изоляция позволяет нам легко трассировать действия агента, выявлять проблемы, сравнивать агентов между собой. 2. В Harbor задача это физическая директория с инструкцией, докер-файлом и т.д. Бенчмарк у нас - код. Все то же самое умещается в одном методе, поэтому обернуть стандартный датасет дешево - одна точка входа в коде.
Да, по реализации они абсолютно разные. Но job у них один: превратить модель в работающего агента. Это как раз причина их сравнивать, а не повод этого не делать. Цель сравнения - выбрать наилучшую связку harness+модель под задачу. Различия и определяют выбор: что лучше получается у одного, а что у другого, как раз и можно наблюдать на тестах.
Это не одно и то же. Закинуть тест в обучение - значит дать модели увидеть конкретные примеры. Здесь же модель примеры теста не видит вообще, оптимизируется только промпты по сигналу метрики.
Потом не всегда есть доступ к данным теста - иногда клиент их закрывает и отдаёт наружу только функцию метрики. В таком сценарии ГА как раз и подходит: подстраиваемся под тест, не видя его примеров.
А если всеравно боишься переобучиться на тесте, то стандартное решение: один набор используется как валидация внутри ГА (по нему считается fitness), второй держится в стороне как финальный.
Вы использовали апскейл-модели или какие-то другие трюки для работы с низким качеством картинки?
Мы сейчас пытаемся такое вытягивать обычной интерполяцией (PIL/OpenCV) или просто берем модельки потяжелее (распознаватели, классификаторы и т. п.). Но спасает не всегда: фото со сложными шрифтами, рукописный текст или совсем мелкие скрины (типа 320x240) приходится пропускать.
А как вы делали предобработку распознанного текста перед тем, как отдать его в NER?
Мы много работаем с документами и распознанные тексты из блоков находятся вдали друг от друга. Мы два стандартных пути использовали: склеивали их перед подачей в NER, либо прогоняли через NER каждый блок по отдельности. У нас лучше работает именно поблочный вариант. Когда мы пытались предварительно склеивать текст из разных частей картинки, терялась связность, и из-за этого качество NER заметно падало.
Тесты как раз и измеряют этот "нюанс". Word и Excel тоже можно сравнить на конкретной задаче, например, подготовить финансовый отчет.
Цель такого сравнения не "что лучше вообще", а где заканчивается применимость одного инструмента и начинается преимущество другого.
С разделением на классы согласен, но не с тем что сравнение бессмысленно. В эксперименте разные harness выполняют одну задачу с одинаковыми моделью, средой, MCP-инструментами и оценкой - это позволяет сравнить их влияние на результат.
По исходникам базовый цикл у них одинаков: задача -> системный prompt -> tool calls -> выполнение -> проверка. Совпадают TODO-статусы, shell/file tools, форматы patch/edit и правила plan -> implement -> verify; некоторые формулировки совпадают дословно. Поэтому специализация различается, но их Agent Loop сопоставим.
Провал OpenCode на памяти это не оценка coding agent в целом, а конкретное архитектурное ограничение. Например, в Qwen Code полноценная Auto-Memory включена по умолчанию.
Сравнение внутри отдельных классов тоже полезно. Но наша цель не общий рейтинг, а карта применимости harness по разным классам задач.
Сильно близкая по духу платформа, но цели разные: у нас фокус на удобном сравнении связок "модель + harness", у Harbor на оценке и тюнинге агента/промптов.
Там, где есть пересечения, я бы выделил такие различия:
1. Harness у нас - черный ящик снаружи. Агент живет в отдельном контейнере и достает до песочницы только через MCP-мост, Harbor же ставит агента внутрь среды задачи. Эта изоляция позволяет нам легко трассировать действия агента, выявлять проблемы, сравнивать агентов между собой.
2. В Harbor задача это физическая директория с инструкцией, докер-файлом и т.д. Бенчмарк у нас - код. Все то же самое умещается в одном методе, поэтому обернуть стандартный датасет дешево - одна точка входа в коде.
Да, по реализации они абсолютно разные. Но job у них один: превратить модель в работающего агента. Это как раз причина их сравнивать, а не повод этого не делать.
Цель сравнения - выбрать наилучшую связку harness+модель под задачу. Различия и определяют выбор: что лучше получается у одного, а что у другого, как раз и можно наблюдать на тестах.
Это не одно и то же. Закинуть тест в обучение - значит дать модели увидеть конкретные примеры. Здесь же модель примеры теста не видит вообще, оптимизируется только промпты по сигналу метрики.
Потом не всегда есть доступ к данным теста - иногда клиент их закрывает и отдаёт наружу только функцию метрики. В таком сценарии ГА как раз и подходит: подстраиваемся под тест, не видя его примеров.
А если всеравно боишься переобучиться на тесте, то стандартное решение: один набор используется как валидация внутри ГА (по нему считается fitness), второй держится в стороне как финальный.
Да, конечно!
Вы использовали апскейл-модели или какие-то другие трюки для работы с низким качеством картинки?
Мы сейчас пытаемся такое вытягивать обычной интерполяцией (PIL/OpenCV) или просто берем модельки потяжелее (распознаватели, классификаторы и т. п.). Но спасает не всегда: фото со сложными шрифтами, рукописный текст или совсем мелкие скрины (типа 320x240) приходится пропускать.
А как вы делали предобработку распознанного текста перед тем, как отдать его в NER?
Мы много работаем с документами и распознанные тексты из блоков находятся вдали друг от друга. Мы два стандартных пути использовали: склеивали их перед подачей в NER, либо прогоняли через NER каждый блок по отдельности. У нас лучше работает именно поблочный вариант. Когда мы пытались предварительно склеивать текст из разных частей картинки, терялась связность, и из-за этого качество NER заметно падало.