19 октября 2026 г.

Мы задали Claude Haiku 5.5 те же 17 инженерных вопросов о большой кодовой базе дважды: один раз самостоятельно, а второй — с предварительным одиночным запросом к API Context Graph. С графом модель отвечала в среднем на 23% быстрее, на 19% дешевле и за меньшее количество шагов. Она также не уступила или превзошла собственные показатели точности по каждому вопросу о межрепозиторных зависимостях, который мы задавали.

Haiku 5.5 — и без того маленькая, быстрая и недорогая модель. Вопрос заключался в том, делает ли Context Graph ее более эффективной в расчете на один промпт: то же качество ответа при меньших затратах времени, денег и меньшем количестве блужданий по коду. По результатам 102 оцененных запусков — да, делает.

Главные цифры

Все данные здесь приведены в расчете на один промпт, усредненные по 51 запуску для каждого варианта (17 вопросов, по 3 запуска на каждый).

Я прогнал те же 17 вопросов через Haiku 5.5 саму по себе и с Context Graph, по три раза каждый. Самый очевидный результат заключается в том, что граф заставил Haiku выполнять меньше работы. На один вопрос уходило на 20% меньше входных токенов, совершалось на 9% меньше вызовов инструментов, а стоимость была на 19% ниже.

Показатели времени интересны тем, что сам запрос к графу требует времени. Haiku потратила в среднем 8.5 минут на работу с графом по сравнению с 19.6 минутами в автономном режиме. Даже с учетом времени на запрос к графу, общее время ответа сократилось с 19.6 до 15.2 минут. Таким образом, запрос занял время, но Haiku сэкономила больше времени, чем потратила на ожидание.

Точность изменилась с 0.623 до 0.638 по 16 вопросам с эталонными ответами. Это небольшое улучшение, и я бы не стал делать громких заявлений опираясь только на эту разницу. Эти запуски яснее показывают, что Haiku достигла примерно той же точности с меньшим объемом поиска, меньшим количеством токенов, меньшей стоимостью и более быстрым ответом.

Эту разницу становится проще понять, если посмотреть, откуда Haiku начинает поиск.

Самый простой способ это представить

Представьте, что кто-то вываливает на стол огромную коробку с деталями LEGO и спрашивает, какие из этих деталей подходят к этому единственному синему кирпичику. Когда у вас есть только коробка, у вас есть один путь: брать кирпичики по одному, примерять каждый к синему и откладывать те, что подошли. Более быстрый и опытный сборщик справится с коробкой быстрее. Тем не менее, он все равно перебирает всю коробку и никогда не найдет деталь, которой там нет, например, ту, что лежит в коробке в другой комнате.

А теперь дайте ему инструкцию. В ней есть список деталей, в котором указано, какие элементы с какими соединяются и в какой коробке каждый из них живет, включая коробки, которых нет на вашем столе. Сборщик больше не перебирает каждый кирпичик. Он начинает со списка, берет то, что названо, и соединяет детали, чтобы убедиться, что они подходят.

Haiku 5.5 — это сборщик, клонированные репозитории — это коробка, а Context Graph — это инструкция. Граф представляет собой индекс сервисов, эндпоинтов, схем и связей между ними для всего, что с ним связано. (Подробное обоснование см. в статье о том, почему агентам программирования на базе ИИ нужны контекстные графы.) Он не заменяет процесс сборки. Haiku все равно должна убедиться, что детали подходят, а это значит — читать код. Граф лишь подсказывает, с чего начать.

Что мы тестировали: 17 вопросов, 802 репозитория, 102 запуска

Оба варианта используют одну и ту же модель (Claude Haiku 5.5), одни и те же инструменты только для чтения (чтение файла, список директорий, grep, glob, git log, git blame), одни и те же вопросы и один и тот же код в фиксированном коммите (pinned commit). Код находится в одной публичной организации на GitHub с 802 репозиториями.

Есть ровно одно отличие. Вариант с графом запрашивает Context Graph один раз перед запуском Haiku, и результаты передаются Haiku в качестве набора кандидатов для проверки. Базовый вариант ничего не знает о графе. Запрос к графу представляет собой один и тот же короткий вопрос для каждого запуска конкретного промпта.

Каждый вопрос запускается 3 раза для каждого варианта, потому что один запуск языковой модели — это лишь выборка, а не измерение. 17 вопросов × 3 запуска × 2 варианта = 102 запуска.

17 промптов

Это простые промпты, именно такие, какие задал бы инженер. Ни один из них не указывает Haiku, где искать или сколько ответов найти.

Межрепозиторные зависимости (9 вопросов):

Вопросы по инвентаризации (6 вопросов):

Вопросы о влиянии изменений (2 вопроса):

Как мы оценивали: 70% эталонный ответ, 5% цитаты, 25% оценка судьи

Каждый ответ оценивается тремя способами, и весовые коэффициенты зафиксированы в бенчмарке: 70% по эталонному ответу, 5% по цитатам и 25% по оценке судьи.

Эталонный ответ (70%)

Каждый вопрос имеет список репозиториев, которые дают на него правильный ответ, и этот список берется из кода. Мы ищем в проверенных репозиториях то, о чем спрашивается в вопросе. Это никогда не берется из Context Graph. Оценивать граф по его собственному выводу было бы все равно что проверять выполненную им же домашнюю работу.

Оценка по эталону представляет собой полноту (recall), умноженную на коэффициент точности (precision factor). Полнота и точность здесь измеряют разные вещи: полнота показывает, какая часть эталона была найдена в ответе, а коэффициент точности снижает балл, если в ответе также перечислена куча репозиториев, которых нет в эталоне. Список «по площадям» не побеждает. Побеждает правильность.

Мы расширили эталоны, но делали это осторожно. Для каждого репозитория, названного графом, которого не хватало в эталоне, мы открывали код и проверяли его на соответствие определению вопроса. Репозиторий добавлялся в эталон только в том случае, если код на диске подтверждал это наличием файла и строки в качестве доказательства. Это добавило 14 эндпоинт-сервисов, 16 развернутых сервисов, 9 эмиттеров телеметрии, 8 вызывающих элементов во время выполнения (runtime callers), 2 декларатора схем и 1 потребителя. Граф предлагает, а код решает.

Цитаты (5%)

Каждый путь к файлу, на который ссылается ответ, проверяется по репозиторию на зафиксированном коммите. Выдумаете путь — попадетесь.

Судья (25%)

Языковая модель (Claude Opus 4.7) оценивает каждый ответ по критериям (рубрикатору). Этот компонент имеет наименьший вес, поскольку он не может проверить репозиторий так, как это делают два других оценщика.

Запуск считается успешным при оценке 0.5 или выше. Сопоставление названий лояльно: символы _ и - считаются эквивалентными, ссылки на GitHub учитываются, а такой компонент, как ingester-service, засчитывается в пользу его родительского репозитория.

Что считается ответом варианта с графом

Для части оценки по эталонному ответу мы оцениваем вариант с графом по тому, что вернул граф, плюс по тому, с чем определилась Haiku, поскольку и то, и другое является частью того, что система выдает пользователю. Цитаты и судья оценивают только ответ Haiku. Мы также отдельно публикуем список, выбранный самой Haiku, чтобы вы могли видеть, какая часть любой оценки получена от графа, а какая — от Haiku. Базовый вариант не имеет вывода графа, поэтому его оценкой является его собственный ответ.

Результаты: на 19% меньше денег, на 23% меньше времени

Haiku 5.5 на 19% дешевле с Context Graph

Вот счет за 51 запуск для каждого варианта по опубликованному тарифу Haiku 5.5: $0.50 за миллион входных токенов и $2.50 за миллион выходных токенов (см. ценообразование Anthropic). Это более высокий тарифный план для объема более 100 тыс. токенов, поэтому воспринимайте эти цифры как верхнюю границу.

Все сводится к токенам. В цикле агента на каждом шаге происходит повторная отправка всей стенограммы, поэтому входные токены составляют около 84% счета, причем вариант с графом использовал 365 000 входных токенов на один вопрос против 459 000. Эти цифры учитывают только токены модели, без платы за сам запрос к графу.

По типам вопросов: вопросы о зависимостях стали дешевле на 21% (с $0.376 до $0.298 за вопрос), а вопросы об инвентаризации и влиянии — на 13% (с $0.156 до $0.135). Вариант с графом оказался дешевле для 12 из 17 вопросов — до 48% (интеграции Vercel, с $0.365 до $0.191) и 44% (потребители топика, с $0.732 до $0.407). Он стоил дороже в 5 случаях, в основном на тех вопросах, которые изначально были дешевыми. Вызовы во время выполнения выросли в цене с $0.061 до $0.099, а HTTP-эндпоинты — с $0.073 до $0.119, поскольку граф передает Haiku длинный список для обработки.

Haiku 5.5 отвечает на 23% быстрее благодаря Context Graph

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

Чистое рабочее время Haiku сократилось в среднем на 57% — с 19.6 до 8.5 минут. Это время, затраченное на рассуждения и поиск, без учета ожидания ответа от графа.

В целом, включая ожидание графа, ответ на вопрос занимал 15.2 минуты вместо 19.6. В среднем это на 23% быстрее. Даже с учетом оплаты запросов к графу для каждого вопроса, вариант с графом в итоге сэкономил 3.8 часа по результатам 51 запуска.

Haiku 5.5 делает на 9% меньше вызовов инструментов с Context Graph

В разбивке по типам вопросов: количество вызовов инструментов для вопросов о зависимостях снизилось с 35.6 до 32.0 (на 10% меньше), а для вопросов об инвентаризации и влиянии — с 28.5 до 26.8 (на 6% меньше). Вариант с графом сделал меньше вызовов для 9 из 17 вопросов. Наибольшее сокращение наблюдалось для схем (с 33.0 до 17.7), телеметрии ( с 24.3 до 11.3) и развернутых сервисов (с 34.3 до 20.7).

Это сокращение заложено намеренно. Варианту с графом сообщают, что кандидаты поступают из индекса, поэтому ему не нужно перепроверять то, что уже указано в индексе. Именно этого вы и ждете от контекстного слоя: Haiku тратит шаги на то, чего не хватает в индексе, вместо того чтобы заново открывать то, что там уже есть.

Выход за рамки клонированного репозитория: 49 упомянутых репозиториев на вопрос против 29

Вариант с контекстным графом упоминает в своих ответах гораздо больше репозиториев: 49 на вопрос против 29. Некоторые из них вообще не содержат кода в локально клонированных репозиториях. Это внешние системы, вызываемые во время выполнения, или сервисы, находящиеся в других частях более широкой экосистемы. Вы не сможете найти их с помощью команды grep. Система оценки также не может учесть их, поскольку эталоны ответов берутся из клонированного кода, поэтому каждое число в этой статье занижает данный показатель.

Здесь содержатся ответы, которые Haiku использует не всегда: поступает 64% ключей телеметрии, учитывается 13%

В вопросах о телеметрии и вызовах во время выполнения собственные строки графа покрывали 64% и 55% эталона ответа. Haiku сама по себе покрывала 8% и 6%. Используя граф, Haiku задействовала в своем финальном списке лишь 13% и 3% ключей, то есть оставила без внимания многое из того, что нашел граф. Это решение самой Haiku о том, что включать в отчет, а не ограничение графа. Это также указывает на самую очевидную неиспользованную возможность: информация уже поступает, и ее более эффективное применение станет следующим шагом к улучшению.

Где Context Graph доказывает свою эффективность: на 19% дешевле, на 23% быстрее, победа 9 из 9 в вопросах о зависимостях

Для небольшой быстрой модели граф нужен не для того, чтобы сделать каждый ответ более умным. Он нужен для того, чтобы сделать получение каждого ответа более дешевым: меньше токенов, меньше шагов, меньше времени при той же или более высокой точности. Это выразилось в снижении затрат на 19%, уменьшении количества входящих токенов на 20% и сокращении объема работы самой Haiku на 57%.

Он приносит наибольшую пользу в решении вопроса, которого страшится каждый инженер: что еще зависит от этого? Когда ответ разбросан по дюжинам репозиториев, и нет ни одного файла со списком их названий, Haiku в одиночку приходится искать каждый из них вручную. Получив готовый список компонентов, модель отталкивалась от этого ответа и оказалась в выигрыше по всем 9 вопросам о зависимостях.

Пробелы тоже существуют. Граф должен помогать Haiku сообщать о большем объеме получаемых данных, а вопросы об инвентаризации требуют доработки, прежде чем они продемонстрируют ценность графа в баллах. Тем не менее, по стоимости, скорости и охвату множества репозиториев результат подтвердился на 102 проверенных запусках. Haiku 5.5 с Context Graph выполняет ту же работу дешевле, а в самых сложных вопросах о зависимостях справляется с ней лучше.

Попробуйте на своем собственном коде

Выберите вопрос, охватывающий несколько репозиториев, который ваша команда часто задает, например, что еще вызывает этот сервис. Запустите его сначала с обычным агентом, а затем с запросом к Context Graph. Сравните время, токены и список репозиториев, возвращаемый каждым запуском, и проверьте любой репозиторий, который упомянул только один из вариантов. Начните с рабочей области Context Graph API или настройте MCP-клиент для работы с графом, следуя документации по MCP-запросам.