Ornith 9B vs 35B полезен только в том случае, если он приводит к принятию более обоснованного решения о реальной работе по программированию. Короткая локальная задача, изменение в масштабе всего репозитория и очередь агентных задач имеют разные ограничения по времени проверки, времени отклика и эксплуатационным затратам. Рассматривайте их как разные тесты.
В этом руководстве нет универсального победителя. Релизы моделей, их доступность, цены и схемы обслуживания меняются. Практическая цель — небольшое, поддающееся аудиту испытание OdiRouter, которое начинается с работы, уже понятной вашей команде.
Начинайте с задачи, а не с метки параметра
Определите первый класс задач, который хотите протестировать. Это может быть узкое объяснение кода, исправление модульного теста, типовой рефакторинг или ограниченный вызов инструмента. Сделайте первое испытание достаточно небольшим, чтобы проверяющий мог увидеть, в чём результат помог и где он оказался недостаточным.
Отделяйте исследовательскую работу от работы, способной изменить общую кодовую базу. В интерактивном цикле разработки приоритетом могут быть предсказуемое время отклика и минимальные препятствия. Более широкий агентный рабочий процесс может требовать качественного планирования, надёжного использования инструментов и меньшего числа дорогостоящих исправлений. Это требования рабочей нагрузки. Метка параметра их не определяет.
Для каждого случая сохраняйте набор входных данных, ожидаемый результат, обязательные тесты и путь восстановления. Это даёт сравнению основу, выходящую за рамки одного запроса и интуитивного ощущения.
Рассматривайте контекст как тест рабочей нагрузки
Длинный контекст полезен лишь тогда, когда модель способна использовать важный материал. Задача по репозиторию может включать исходные файлы, сведения об инциденте, результаты тестов, результаты работы инструментов и соглашения проекта. Дополнительный текст также может привести к задержкам, увеличению затрат и отвлечению внимания.
Создайте контекстный тест на основе реального, но безопасного фрагмента работы. Для обоих маршрутов укажите один и тот же фрагмент репозитория, инструкции и инструменты. Проверьте, сохраняет ли каждая модель чёткие границы между файлами, соблюдает ли ограничения, замечает ли проваливающиеся тесты и запрашивает ли недостающую информацию вместо догадок. Повторите после изменения объема контекста.
Результатом должен быть порог, а не маркетинговое заявление. Команда может продвигать маршрут для класса задач только в том случае, если он сохраняет необходимые факты в неизменном виде, создает патч, подлежащий проверке, и проходит соответствующие проверки с приемлемой эффективностью.
Сравнивайте скорость, стоимость и объём работ по исправлению вместе
Самый быстрый первый ответ не всегда означает самое быстрое завершение задачи. Измеряйте весь цикл: время до получения пригодного ответа, время ожидания вызовов инструментов, правки проверяющего, повторные запуски тестов и восстановление после неверного изменения. Маршрут, требующий меньшего числа последующих действий, может быть лучшим вариантом, даже если его первый ответ медленнее.
Применяйте ту же дисциплину к стоимости. Отслеживайте фактическую нагрузку, включая контекст, повторные попытки, вызовы инструментов и параллельные задания. Не полагайтесь на заявленную цену и не считайте, что один эксперимент представляет рабочую среду. Фиксируйте маршрут, характер запроса, результат и вмешательство человека, чтобы команда могла сопоставить стоимость с полезной работой.
Перед развёртыванием ознакомьтесь с текущими вариантами в OdiRouter model list и OdiRouter pricing page. Это не позволит оценочной заметке превратиться в обещание относительно модели или цены, которые уже изменились.
Используйте небольшую таблицу оценок
Дайте обоим маршрутам одинаковые репрезентативные задачи. Краткая таблица оценок полезнее, чем один бенчмарк или одна запоминающаяся неудача.
Показатель | Что фиксировать | Почему это важно |
|---|---|---|
Выполнение задачи | Тесты, замечания при проверке и факт внесения намеченного изменения | Беглый ответ не означает выполненную инженерную задачу. |
Соблюдение ограничений | Защищённые файлы, соглашения по написанию кода и границы инструментов | Это выявляет предотвратимую работу по проверке и обеспечению безопасности. |
Использование контекста | Использовал ли маршрут релевантные файлы и проигнорировал ли несвязанный материал | Дополнительный контекст должен улучшать выполнение задачи, а не затруднять его. |
Общее время | Время на подготовку запроса, использование инструментов, проверку и восстановление | Команды видят весь цикл, а не только один показатель задержки. |
Стоимость рабочей нагрузки | Время на запросы, повторные попытки и ручную корректировку | Полезной единицей является выполненная работа, а не отдельный запрос. |
Храните таблицу оценок вместе с входными данными и заметками оценщика. Если результат изменяется после обновления модели или изменения способа обслуживания, выполните те же самые тесты, прежде чем изменять маршрут по умолчанию.
Определите, к какому маршруту относится каждый из них.
Используйте результаты для составления правила маршрутизации. Меньший маршрут может быть разумной отправной точкой, когда работа ограничена по объёму, часто повторяется и легко проверяется. Более требовательный маршрут может оправдать своё место, если оценка показывает воспроизводимое улучшение при решении более масштабных задач планирования или задач, связанных с репозиторием. Указывайте в правиле класс задач, а не только модель.
Отдельно тестируйте параллельную обработку. Запрос одного разработчика — не то же самое, что несколько агентов, использующих одну конечную точку. Проверьте постановку в очередь, тайм-ауты, повторные попытки и резервный вариант до того, как команда начнёт зависеть от маршрута. Также определите правило отката. Если маршрут не проходит обязательный тест, изменяет защищённый файл или превышает порог бюджета, передавайте работу проверяющему или известной безопасной альтернативе.
Превратите оценку в пробный запуск OdiRouter
OdiRouter публикует quick-start guide и актуальный model list для команд, готовящих интеграцию. Выберите вариант, указанный на момент пробного запуска, и держите среду оценки отдельно от изменений в рабочей среде.
Начните с небольшого набора репрезентативных задач. Сохраняйте инструкции, политику контекста, результаты тестов и решения проверяющего. Сравнивайте одну и ту же нагрузку после каждого изменения маршрута. Когда доказательства подтверждают вариант по умолчанию, переводите вперёд только этот класс задач и сохраняйте правило отката.
Чтобы получить более широкое представление о платформе, посетите OdiRouter. Смысл не в том, чтобы выбирать Ornith 9B или Ornith 35B по названию. Смысл в том, чтобы выбрать маршрут, который ваша команда может проверять, эксплуатировать и пересматривать по мере изменения нагрузки.