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

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

Пилот сработал. Продакшн — это то место, где выявляются обходные пути

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

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

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

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

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

Вы платите по ценам за вычисления, чтобы решить проблему с данными

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

Спросите инфраструктурную команду, как поживает среда ИИ, и вы обычно получите какую-то версию метрики использования или потребления. В среде с собственными графическими процессорами это может быть использование парка оборудования. В облаке это может быть использование токенов или затраты на инференс.

Но эти цифры говорят вам только об используемой инфраструктуре. Они ничего не говорят о том, стоит ли вообще выполнять эту работу.

Большая часть ее — нет. Один и тот же массив данных встраивается (эбеддится) повторно, потому что другая команда не смогла найти векторы первой команды или нашла их, но не доверилась им. Один и тот же контекст извлекается и перерабатывается при каждом сеансе, потому что его негде надежно сохранить. Агент читает одни и те же 40 документов, чтобы ответить на вопрос, на который он ответил вчера, а затем делает это снова завтра для следующего пользователя. Задания простаивают в ожидании хранилища, которое не может подать их достаточно быстро, и это ожидание засчитывается как работа. Ни один из этих сценариев не является необычным. Это нормальное поведение системы, чей слой данных никогда не проектировался для повторного использования.

Теперь перенесем это в бюджет на ИИ.

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

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

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

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

Управление может либо ускорить производство, так и стать узким местом

Большинство предприятий рассматривают управление (гэвернанс) в первую очередь как требование соответствия нормативным требованиям. Но в производственном ИИ оно также оказывает прямое влияние на то, как быстро могут двигаться команды.

Если команда не может получить четкий ответ на вопрос «Разрешено ли этой модели использовать эти данные?», работа останавливается, пока кто-то не примет это решение. Модель может быть готова. Данные могут быть доступны. Но если правила доступа приходится каждый раз интерпретировать вручную, переход от одного варианта использования к другому замедляется.

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

Команды движутся быстрее всего с теми данными, вокруг которых уже установлены четкие правила доступа.

Я также прямо скажу, что самая сложная версия этой проблемы не решена. Контролировать, какие документы модель может извлекать, вполне реально. Управлять тем, что модель может вывести (инферировать) из документов, которые ей официально разрешено видеть, и что она затем может раскрыть пользователю, у которого не должно быть к ним доступа, не решено нигде в индустрии, и я включаю сюда Everpure. Что вы можете сделать сегодня, так это сделать это видимым: регистрируйте, к чему на самом деле обращаются агенты, следите за тем, где их останавливают, и используйте эти журналы (логи) для дополнения каталога и демонстрации того, как на практике осуществляется доступ к данным.

3 вопроса, которые стоит задать перед расширением вычислительных мощностей

Если бы другая команда захотела построить что-то на основе уже загруженных нами данных, смогли бы они найти их, довериться им и использовать их без повторного создания?
Какая доля наших расходов на инференс приходится на работу, которую мы уже выполнили?
Можем ли мы доказать без созыва совещания, к чему разрешен доступ любой конкретной модели?

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

Пришло время навести порядок в ваших активах данных

Дорожная карта ускорителей выглядит интереснее, чем за последнее десятилетие, и я буду на конференции NVIDIA GTC Berlin 2026, чтобы изучить ее вместе со всеми остальными.

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

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

Я буду на GTC Berlin с 20 по 22 октября и поговорю с командами о том, что происходит при переходе ИИ от пилотного проекта к промышленной эксплуатации. Найдите нас, если хотите обменяться мнениями по поводу работы с данными на этом этапе перехода.

Ознакомьтесь с этими ресурсами, чтобы узнать больше: