Dev48
ЯЗЫК
  • О нас
  • Услуги
  • Индустрии
  • Технологии
  • Статьи
  • Контакты
Забронировать звонок
    Главная/Статьи/Ekonomicheskoe obosnovanie ispolzovaniya hranilischa dannyh v kachestve pervichn
Dev48
info@dev48.org+375 29 320-40-96WhatsApp@isky_by

© 2026 · Все права защищены.

Экономическое обоснование использования хранилища данных в качестве первичного контекста для ИИ

Источник: dbt Labs•11 ноября 2026 г. в 16:58

Экономическое обоснование использования хранилища данных в качестве первичного контекста для ИИ

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

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

Разница поддается измерению. Опрос руководителей, проведенный компанией Deloitte в Европе и на Ближнем Востоке, показал, что, хотя средние технологические инвестиции окупаются через 7-12 месяцев, a typical AI use case takes 2 to 4 years. Это ставит многие ИИ-проекты под угрозу закрытия.

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

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

Почему расходы на ИИ опережают его ценность

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

Хорошая новость заключается в том, что по мере развития ИИ стоимость токенов быстро снижается. С поправкой на производительность, LLM inference costs drop about 10x a year.

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

Агент потребляет больше токенов, чем оператор, работающий с Claude или ChatGPT со своего рабочего стола. Одиночные агенты обычно используют примерно в 4 раза больше токенов, чем чат-интерфейс. Многоагентная система, по данным Anthropic, can use about 15x more.

Мы видим влияние этих расходов на ИТ-бюджеты. Несмотря на снижение стоимости токенов, эксперты предвидели a 36% increase in average monthly AI spend in 2025. Похоже, что эта тенденция не замедлится и в 2026 году.

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

Этот разрыв вызывает внутренние конфликты. С одной стороны, согласно опросу 500 финансовых руководителей крупных предприятий США и Великобритании, проведенному DoiT, only 15% of companies said they could calculate AI ROI easily. В то же время 83% финансовых руководителей ожидают четких, количественно измеримых результатов от ИИ в течение года.

Как контекст на основе MCP тратит токены впустую

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

Если вы не можете ускорить процесс или немедленно рассчитать окупаемость проекта, вы можете хотя бы поработать над снижением затрат. Главным виновником скачков расходов в агентных решениях являются токены, потребляемые при использовании протокола контекста модели (MCP).

MCP часто является самым простым и быстрым способом подключения данных, поскольку он автоматически согласовывает возможности с агентами. Это избавляет команды по работе с данными от необходимости вручную подключать десятки API к своим агентам.

Вот почему нам казалось очевидным подключить более 20 серверов MCP после внедрения Claude в компании. Однако мы быстро поняли, что это увеличивает расходы тремя способами.

Определения инструментов при каждом вызове

Большинство клиентов MCP загружают определение каждого инструмента заранее. Это создает огромные накладные расходы.

Anthropic измерила это и обнаружила, что настройка из пяти серверов, использующая 58 инструментов, потребляет около 55 000 токенов. И это еще до начала разговора.

При 10 000 вызовов агента в месяц это 550 миллионов входных токенов накладных расходов до того, как будет выполнена какая-либо работа. На Claude Opus 5.5 это выливается в $2,200 a month чистых затрат на «разогрев».

Необработанные данные, которые проходят через модель, иногда дважды

Промежуточные результаты могут передаваться туда и обратно в запросах и ответах. Это означает, что одни и те же данные могут быть посчитаны дважды. Например, извлечение стенограммы продаж, а затем прикрепление ее к Salesforce лиду, пропускает одни и те же данные через модель дважды, consuming an extra 50,000 tokens на стенограмму двухчасовой встречи.

Один и тот же контекст, извлекаемый снова и снова

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

Сборка необработанных данных из более чем 20 источников в одном чате становится очень дорогой и очень быстро. И ни одна из этих работ не сохраняется между сессиями.

Как контекст, ориентированный на хранилище данных, меняет расчеты

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

Этот подход решает каждый из недостатков использования прямого MCP для извлечения контекста:

Используйте меньше определений инструментов на вызов

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

Это простое изменение означает, что мы не несем расходов на загрузку инструментов перед каждым запросом. Данные Anthropic показывают, что аналогичный подход .

Мы используем сервер dbt MCP, чтобы сделать этот контекст доступным для потребителей по всей компании. Мы просто пропускаем вызовы инструментов, которые несут высокие накладные расходы.

Используйте компактный контекст, а не необработанные полезные нагрузки

При таком подходе к контексту нам не нужно передавать агенту полные полезные нагрузки (например, полную стенограмму двухчасового звонка). Мы используем dbt для разбиения на части, встраивания и классификации стенограмм.

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

Это может привести к значительному сокращению расходов на токены. (сокращение на 98,7%) за счет изменения способа вызова агентом инструментов MCP.

Меньшие контексты не только сокращают расходы на передачу данных: они часто дают ответы более высокого качества. Это сокращает количество повторных попыток, что уменьшает время отклика.

Обработайте контекст один раз, затем используйте его повторно

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

Нескольким нашим командам нужно извлекать данные из звонков клиентов, записанных в Gong. Чтобы ИИ прочитал каждый звонок в наборе данных, каждый раз требуется около 3000 долларов. Сохраняя самые важные элементы этих звонков в хранилище данных, нам нужно только извлекать и обрабатывать новые звонки по мере их поступления через Fivetran.

Как обосновать бизнес-кейс для вашего финансового директора

Естественно, что финансовые директора хотят понимать финансовое влияние ИИ-проектов компании. Защита прибыли — их работа.

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

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

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

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

← Все статьи

О чём эта статья

Ещё в разделе «Данные и аналитика»

Все →
Почему RAG, основанный только на векторах, не справляется с аналитическими вопросами, и эталонная архитектура, которая решает эту проблему
Couchbase

Почему RAG, основанный только на векторах, не справляется с аналитическими вопросами, и эталонная архитектура, которая решает эту проблему

Сертификация Google Cloud Agentic Architect
Looker

Сертификация Google Cloud Agentic Architect

Как оценить готовность вашей организации к внедрению ИИ
dbt Labs

Как оценить готовность вашей организации к внедрению ИИ

Повышение планки корпоративной устойчивости в эпоху ИИ
Dynatrace

Повышение планки корпоративной устойчивости в эпоху ИИ

Письмо от наших основателей
Fivetran

Письмо от наших основателей

Новые правила iGaming в регионе EMEA теперь требуют запросов в реальном времени
SingleStore

Новые правила iGaming в регионе EMEA теперь требуют запросов в реальном времени

Ещё от dbt Labs

Как оценить готовность вашей организации к внедрению ИИ
dbt Labs

Как оценить готовность вашей организации к внедрению ИИ

Fivetran и dbt Labs завершили слияние для создания инфраструктуры данных для доверенных ИИ-агентов
dbt Labs

Fivetran и dbt Labs завершили слияние для создания инфраструктуры данных для доверенных ИИ-агентов

Все, что мы анонсировали на dbt Summit, и почему это важно
dbt Labs

Все, что мы анонсировали на dbt Summit, и почему это важно