Context Graph делает GPT 6.1 Terra на 42% быстрее и использует на 43% меньше токенов

4 ноября 2026 г.

Вы когда-нибудь вносили небольшое изменение в API, выпускали его с успешно пройденными тестами, а затем узнавали от другой команды, что вы сломали их интеграцию?

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

Теперь вы ищете путь к эндпоинту по всем репозиториям, отслеживаете импорты SDK и читаете клиентские обертки, чтобы выяснить, кто еще его использует. Некоторые совпадения — это реальные вызывающие стороны. Другие — примеры, тестовые фикстуры или устаревший код. Перед слиянием вам был нужен список потребителей, включая тех, которых нет в репозитории, который вы проверили. Получение этого списка оказывается отдельной инженерной задачей.

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

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

Реестр ключей дает им начальный список. В нем записано, у кого есть ключ и какую дверь он открывает. Им все равно нужно проверить, использует ли его каждый человек и не пропал ли кто-то. Но они могут начать с того, что свяжутся с людьми из списка.

Postman Context Graph делает нечто подобное для вашей экосистемы API. Он индексирует сервисы, эндпоинты и их взаимосвязи по подключенным источникам. Вы спрашиваете, какие сервисы зависят от API, и ваш агент получает список кандидатов для проверки. Ему все еще нужно проверить доказательства и установить, имеет ли каждое из зависимостей значение для вносимых вами изменений.

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

Поэтому я создал обвязку и задал GPT 6.1 Terra одни и те же 17 инженерных вопросов дважды: один раз только с кодом, а другой — с результатами Context Graph, предоставленными до начала поиска.

С графом Terra использовала на 43% меньше входных токенов, стоила на 43% дешевле в плане токенов модели и потратила на 42% меньше времени на работу. Она предприняла меньше шагов и сделала меньше вызовов инструментов.

Основные цифры

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

По 17 вопросам количество входных токенов сократилось с 14,71 миллиона до 8,35 миллиона, а общее затраченное время сократилось примерно с 3,2 часа до 2,4 часа.

При той же средней стоимости модели 1000 вопросов стоили бы около 128 долларов вместо 226 долларов, что дает экономию примерно в 98 долларов, а также на 374 миллиона меньше входных токенов. Это экстраполяция данного прогона, и она не включает плату за запрос к графу.

Преимущества в эффективности сохранились для большинства вопросов: группа с графом стоила дешевле в 15 из 17 случаев и сократила рабочее время Terra в 16 случаях. В остальной части статьи показано, откуда взялись эти преимущества, а где их не было.

Что содержит Context Graph

Postman Context Graph — это частная, аутентифицированная карта ваших API и сервисов, которые их используют. Она объединяет информацию из Postman, GitHub и New Relic, чтобы вы могли отследить зависимость, не собирая все воедино самостоятельно.

В Postman есть контракты и коллекции. В GitHub есть реализация и места вызовов. В New Relic есть информация о развертывании и времени выполнения. Их объединение дает вам возможность спросить: кто вызывает этот API, работают ли они в продакшене и кто ими владеет?

Допустим, вы меняете поле суммы, возвращаемое GET /claims/{id}, с долларов на центы. Претензия на 125 долларов в настоящее время возвращает 125.00. После вашего изменения она возвращает 12500.

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

Вот как я бы исследовал это в гипотетической системе:

Поиск по коду может найти клиента воркера. Граф помогает вам связать этого клиента с работающим сервисом, владеющей командой и другими зависимостями, которые стоит проверить. Вашему агенту все равно нужно изучить код и установить, какие потребители затронуты.

Вы также услышите, как эти отношения описываются как восходящие (upstream) и нисходящие (downstream). В этом примере settlement-worker является нисходящим потребителем claims-service. Claims-service является восходящей зависимостью воркера.

Когда вы меняете claims-service, вы хотите знать, кто от него зависит. Когда вы пытаетесь запустить settlement-worker локально, вы хотите знать, от чего он зависит, чтобы вы могли запустить или симулировать эти сервисы.

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

В документации Context Graph описаны поддерживаемые источники и взаимосвязи.

Как мы тестировали: 17 вопросов, 802 репозитория, 34 прогона

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

Мы протестировали Terra на 17 инженерных вопросах об одной публичной организации на GitHub с 802 репозиториями. Мы искали этот код, чтобы создать ключ ответа для каждого вопроса, независимо от Context Graph. Ключ ответа — это справочный список репозиториев, который оценщик ожидает для этого вопроса.

Затем мы задали Terra каждый вопрос дважды:

• Без Context Graph: Terra должна была найти ответ, обыскивая репозитории.
• С Context Graph: Мы сначала задавали графу тот же вопрос, а затем давали Terra его результаты в качестве начального списка для проверки по коду.

В обеих группах использовалась одна и та же модель GPT 6.1 Terra, один и тот же закрепленный чек-аут и одни и те же инструменты только для чтения: read_file, list_dir, grep, glob, git_log и git_blame. Промпты не предоставляли имена репозиториев в качестве подсказок для поиска и не говорили Terra, сколько результатов нужно найти. Запрос к графу — это один и тот же короткий вопрос для каждого прогона данного промпта, и он не называет репозиторий, поэтому мы не даем Terra стратегию поиска. У базовой линии не было доступа к графу. В группе с графом обвязка предоставляла результаты начального запроса, а Terra все равно использовала те же инструменты поиска по коду для исследования.

Это дало нам 34 прогона: 17 вопросов, каждый из которых тестировался с графом и без него. Мы выполнили каждое сравнение по одному разу, поэтому эти результаты показывают, что произошло в данном тесте. Потребовались бы повторные запуски, чтобы измерить, насколько стабильно Terra выдает одинаковые результаты.

Девять вопросов о межрепозиторных зависимостях

Семь вопросов требовали от Terra определить каждый репозиторий, интегрирующийся с конкретной службой, с указанием файла и строки в качестве доказательства.

Два других вопроса были такими:

• Какие репозитории используют тему topic, опубликованную указанной службой?
• Какая внешняя служба имеет больше всего зависимых репозиториев, и что это за репозитории?

Это вопросы, доказательства которых распределены по разным репозиториям. Обычно не существует одного файла, содержащего полный ответ, а часть информации может вообще отсутствовать в локальной копии. По всем 17 вопросам вариант с использованием графа называл около 12 репозиториев на вопрос, которые не разрешались в какой-либо код в локальной копии, по сравнению с примерно 2 для базового варианта — это тот охват, который не может обеспечить grep.

Шесть вопросов по инвентаризации

Вопросы по инвентаризации не называют службу для поиска. Они просят Terra перечислить всё в организации, что обладает заданным свойством, например, каждую службу, которая предоставляет HTTP-эндпоинты или отправляет телеметрию. Ответы объемны и не ограничены. Ключи ответов варьируются от 11 служб (потребители сообщений) до 161 (HTTP-эндпоинты), поэтому нет очевидного момента, когда Terra может прекратить поиск и завершить работу. Локальная копия может показать только те репозитории, которые есть у вас на диске. Граф также может называть службы, которые находятся в репозиториях, которых у вас нет.

Два вопроса о влиянии

Мы также спросили, какие службы вызывают собственный HTTP API организации и какие развернутые службы зависят от SDK, в котором произошли критические изменения, и требуют повторного развертывания.

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

Как мы оценивали: 70% ключ ответа, 5% цитирования, 25% оценка судьи

Бенчмарк объединяет три проверки, и веса фиксированы: 70% ключ ответа, 5% цитирования и 25% оценка модели-судьи.

1. Ключ ответа (70%). Ключи были получены путем поиска в локальной копии кода, а не через Context Graph. Оценка графа на основе его собственного вывода была бы проверкой домашнего задания самим учеником. Для каждого ответа мы сообщаем:

• Ключевая полнота (recall): правильные совпадения, деленные на количество записей в ключе ответа. Это половина метрик точности и полноты.
• Точность (precision): правильные совпадения, деленные на количество оцененных записей ответа.
• F1: гармоническое среднее точности и полноты, 2 × точность × полнота / (точность + полнота). Список «наугад» не может победить по этому показателю.
• Найденные службы: абсолютное количество правильных совпадений с ключом. Сопоставление происходит преимущественно на уровне репозитория, при этом имена компонентов нормализуются до родительских репозиториев.

Полнота (recall) показывает нам, какую часть известного набора зависимостей Terra пропустила. Точность (precision) показывает, сколько представленных результатов не совпали с этим набором. Важно и то, и другое: список, содержащий все правильные службы, менее полезен, если он также включает сотни посторонних. В ограниченных вопросах, где есть фиксированный набор правильных ответов, важнее полнота. В открытых инвентаризациях, где объем и точность взаимосвязаны, важнее количество найденных служб.

2. Цитирование (5%). Каждый путь к файлу, на который ссылается ответ, проверяется в репозитории по зафиксированному коммиту. Если вы выдумаете путь, вас поймают. Сама по себе эта проверка не доказывает, что цитируемый код подтверждает утверждение.

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

Прогон считается пройденным при суммарном балле 0,5. В бенчмарке также есть отдельная проверка ключа ответа, которая применяет коэффициент точности к полноте. Ни эта проверка, ни суммарный балл не являются взаимозаменяемыми с полнотой или F1, поэтому мы не используем их здесь как меры точности. Сопоставление имен допускает совпадение подчеркиваний и дефисов, распознает URL-адреса GitHub и приписывает компонент, такой как ingester-service, к его родительскому репозиторию.

Что считается ответом графа. Для части оценки по ключу ответа мы оцениваем вариант с графом на основе того, что вернул граф, плюс того, на что подписалась Terra, поскольку и то, и другое является частью того, что система передает пользователю. Проверка цитирования и судья видят только ответ Terra. Мы также оцениваем ответ Terra отдельно, чтобы вы могли увидеть, какая часть результата получена от графа, а какая — от Terra. У базового варианта нет вывода графа, поэтому его оценка — это его зафиксированный ответ. Вот почему позже в статье мы приводим полноту в двух версиях.

Результаты: на 43% дешевле, на 42% меньше рабочего времени

Terra считывает на 43% меньше входных токенов с Context Graph

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

С графом среднее количество входных токенов на вопрос упало с 865 000 до 491 000. Выходные данные сократились с 6 850 до 5 930 токенов, включая снижение количества токенов рассуждения с 924 до 740.

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

По типам вопросов: девять вопросов о зависимостях использовали на 27% меньше входных токенов, шесть вопросов по инвентаризации — на 67% меньше, а два вопроса о влиянии — на 50% меньше. Некоторые индивидуальные сокращения были намного больше. Вызовы времени выполнения сократились с 1,30 миллиона входных токенов до 191 000, HTTP-эндпоинты — с 737 000 до 142 000, а вызывающие API — с 1,56 миллиона до 419 000. В расчете на один вопрос вариант с графом считывал меньше токенов в 15 из 17 случаев.

Использование меньшего количества токенов важно не только для экономии средств. Исследование деградации контекста Chroma протестировало 18 передовых моделей и обнаружило, что каждая из них начинает деградировать задолго до заполнения контекстного окна, а исследование «потери в середине» (lost-in-the-middle) показало, что точность падает на 30% и более для информации, скрытой в середине промпта. Мы не измеряли этот эффект здесь, но более короткая транскрипция — это меньшая мишень для него. Статья Postman о том, почему агентам кодирования на базе ИИ нужны графы контекста, более подробно освещает эти исследования.

Расходы на модели снижаются на 43%

Вот стоимость всех 17 вопросов в каждом варианте.

Мы рассчитали эти цифры, используя опубликованные тарифы Terra: $1,00 за миллион входных токенов, $0,05 за миллион кэшированных входных токенов и $5,00 за миллион выходных токенов. Весь входной поток, который не был чтением из кэша, включая запись в кэш, оплачивался по полному тарифу. Цифры учитывают только токены модели, расходы на запросы к графу исключены.

Около 83% входных токенов пришлись на чтение кэша, что обходится в 20 раз дешевле, чем свежие входные данные. Этим объясняется то, почему один запуск, обрабатывающий сотни тысяч входных токенов, обходится в среднем примерно в $0.23 за вопрос, и почему экономия оказывается меньше, чем предполагает расчет по единому тарифу. Без скидки на кэш то же использование токенов обошлось бы в $15.29 для базового сценария и в $8.85 с использованием графа.

Вариант с графом обошелся дешевле на 15 из 17 вопросов: экономия составила до 74% для вызовов API (с $0.535 до $0.138) и 57% для вызовов во время выполнения.

Terra тратит на 42% меньше времени на работу с Context Graph

Мы измеряли как рабочее время Terra, так и общее время получения ответа. Сокращение на 42% относится к рабочему времени модели, не учитывая ожидание ответа от графа. Время ответа от начала до конца в среднем сократилось на 26%.

Результаты: что произошло с ответами

На вопросы о зависимостях: та же полнота, менее чем вдвое меньшее время (18,8 минут → 10,3 минут)

Вопрос о зависимостях требует от Terra найти каждый репозиторий, который зависит от чего-то одного. Семь из девяти вопросов касаются того, какие репозитории интегрируются с определенным сервисом: Datadog, Google Cloud Storage, Slack, AWS S3, PagerDuty, Vercel и OpenRouter. Каждый ответ должен содержать файл и строку кода, подтверждающие интеграцию. Вопрос о Slack, например, имеет эталонный ответ из 12 репозиториев, и Terra должна найти, какие именно 12 из 793 они собой представляют. Один вопрос касается того, какие репозитории используют топик Kafka, публикуемый указанным сервисом, и последний вопрос — от какого единственного внешнего сервиса зависит наибольшее количество репозиториев.

Это вопросы, наиболее близкие к проблеме «кто еще это использует?», с которой начинается статья. Код, отвечающий на них, рассредоточен по множеству репозиториев, и нет единого места, где они были бы перечислены.

По этим девяти вопросам показатель полноты (recall) в обоих вариантах уже составлял около 90%. Terra обычно могла собрать ответ из кода. Граф сократил объем работы, необходимый для этого: среднее рабочее время снизилось с 18,8 минут до 10,3 минут, то есть примерно на 45%.

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

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

Slack — полезный конкретный пример. Сама по себе Terra нашла 11 из 12 репозиториев, интегрированных со Slack. С графом она нашла все 12. Для Google Cloud Storage этот показатель вырос с 16 из 18 до всех 18. Для остальных указанных интеграций Terra уже находила всё или почти всё. Пространства для улучшения полноты оставалось немного, зато было много возможностей для сокращения поиска.

Это именно тот тип вопросов, где ответ рассредоточен повсюду. Такая зависимость, как Slack или S3, встречается в десятках репозиториев, каждый раз в новом файле, и ничто не сводит их в единый список. Поиск по файлам вынужден формировать этот список с помощью grep за grep'ом, в то время как граф уже имеет проиндексированные связи.

По вопросам инвентаризации полнота выросла почти вдвое: 0,22 → 0,42

По шести вопросам инвентаризации Terra в одиночку находила в среднем около 22% от эталонного ответа. Это были масштабные инвентаризации, включающие 161 сервис, предоставляющий HTTP-эндпоинты, и 137 сервисов, отправляющих телеметрию, причем базовая система часто останавливалась уже через пару минут с коротким списком. С графом собственный ответ Terra покрывал около 42% эталонного списка.

Полнота улучшилась по каждому вопросу инвентаризации, в то время как потребление входных токенов по группе сократилось на 67%. Граф нашел то, что Terra не могла обнаружить с помощью поиска, а сама Terra справилась, прочитав лишь треть от прежнего объема.

Но Terra также привнесла в свои ответы больше неверных кандидатов. Граф передает Terra длинный список кандидатов (240 названий эндпоинтов, 277 развернутых сервисов, 199 элементов телеметрии), и в случае с HTTP-эндпоинтами итоговый список Terra вырос с 36 до 139 наименований. По всем вопросам инвентаризации точность (precision) собственных ответов Terra снизилась с 0,71 до 0,46.

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

Где Context Graph оправдывает свое назначение

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

По девяти вопросам о зависимостях Terra уже нашла большинство правильных ответов. Благодаря списку кандидатов от графа она потратила на 45% меньше времени на работу и получила более высокий суммарный балл. По всем 17 вопросам использование графа обошлось дешевле в 15 случаях и сократило рабочее время в 16. Terra и раньше могла выполнять эту работу. Граф помог ей справиться с меньшими затратами на поиск.

К таким вопросам, как «перечислите каждый сервис», я бы относился осторожнее. Граф помог Terra найти гораздо больше, но он также предоставил ей больше кандидатов, которых нужно исключить. Связи тоже должны быть ясными. Приложение, отправляющее ошибки через SDK Sentry, делает не то же самое, что сервис, вызывающий REST API Sentry. Разбор этого может занять время.

В случае изменения API я бы запрашивал конкретно прямых HTTP-вызывающих абонентов, пользователей SDK или подписчиков на топики. Затем я бы попросил агента проверить код, предоставить доказательства и отделить подтвержденных потребителей от тех, которых еще предстоит проверить. Если бы я хотел понять влияние на продакшн, я бы также проверил, что именно развернуто и реально работает. Зависимость в коде сама по себе этого не гарантирует.

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

Как агент выполняет запросы к Context Graph

Агент может отправлять запросы к графу через HTTP API, Postman CLI или протокол Model Context Protocol (MCP). Аутентификация ограничивает доступ к графу команды. Вы можете оставить свой текущий инструмент кодирования и модель, а граф предоставит дополнительный контекст во время инференса.

HTTP-интерфейс использует POST /context-graph/asks для отправки вопроса и GET /context-graph/asks/{askId} для получения его результата. Завершенные результаты могут включать ответ, структурированные сущности, цитаты и происхождение запроса. В справочнике API определены поля ответа. Через MCP соответствующими инструментами являются submitContextGraphAsk и getContextGraphAsk.

Для гипотетического изменения заявлений (claims) я бы задал конкретный вопрос: «Какие сервисы напрямую вызывают HTTP-эндпоинт claims и какие доказательства идентифицируют каждого вызывающего?» Это более узко, чем «что зависит от claims?», что может также включать зависимости от SDK, потребителей сообщений или другие связи.

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

Попробуйте выполнить сравнение на собственных репозиториях

Выберите вопрос о зависимостях, ответ на который вам уже известен (например, какие сервисы вызывают billing-api). Это позволит проверить, что агент упустил из виду и что включил ошибочно.

Сначала убедитесь, что в графе есть ваши данные. В Postman перейдите в Home > Agent Context, нажмите Manage Data Sources, а затем Index. Индексация выполняется в фоновом режиме, поэтому вы можете продолжать работу, пока она завершается. Для сравнения на уровне репозиториев убедитесь, что тестируемые репозитории включены. В документации по настройке описана настройка источников. Затем выполните аутентификацию в Postman CLI с помощью команды postman login и отправьте вопрос:

Вы также можете подключить агент с поддержкой MCP к серверу Context Graph. Для Claude Code команда настройки выглядит следующим образом:

Перед выполнением запросов завершите аутентификацию для MCP-подключения. Удаленная конечная точка в США поддерживает OAuth или ключ API, а в документации по настройке MCP описаны конфигурация клиента и региональные параметры.

Запустите один и тот же вопрос дважды: один раз со списком кандидатов из графа в промпте, а второй — без него. Зафиксируйте для каждого варианта количество токенов модели, вызовов инструментов и общее затраченное время, а затем сравните оба ответа с проверенными данными, которым вы доверяете (например, с результатами проверенного grep). Ожидайте, что список от графа окажется длиннее истинного ответа, и заставляйте агент подтверждать каждое имя чтением кода перед фиксацией.

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

Ресурсы

• Знакомство с Context Graph API
• Начало работы с Context Graph
• Команды Context Graph в Postman CLI
• Запрос к Context Graph с помощью MCP-клиента
• Справочник по Context Graph API
• Поля результатов Context Graph API
• Почему ИИ-агентам кодирования необходимы графы контекста
• Исследование устаревания контекста от Chroma