6 решений, которых не учитают в обучении ИИ: компромиссы в производстве

Компромиссы в производстве, которые проявляются только после запуска модели.

Делиться

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

Как понять, когда следует полностью автоматизировать процесс, а когда лучше оставить человека в процессе?

Когда подсказок становится недостаточно, и тонкая настройка оправдывает затраты? Что на самом деле означает выбор вывода в реальном времени вместо пакетной обработки, когда приходит счет?

Эти вопросы не встречаются в учебных материалах. Они появятся на вашей первой неделе работы в производственной среде!

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

Здесь нет правильных ответов. Есть полезные ориентиры, реальные цифры и контекст, который ускоряет принятие следующего решения.

Индекс

1. Разработка собственных решений или покупка готовых в эпоху магистратуры в области права (когда использование API перестаёт иметь смысл)
2. Сложность модели против удобства сопровождения (Кто будет отлаживать это за 6 месяцев?)
3. Количество данных против качества данных (больше данных — не всегда решение)
4. Пропускная способность против задержки (пакетная обработка или обработка в реальном времени)
5. Оперативное проектирование против тонкой настройки (две совершенно разные кривые инвестиций)
6. Автоматизация против человеческого контроля (насколько вы доверяете модели действовать самостоятельно?)

Привет! Меня зовут Сара Нобрега, и на канале Learn AI я научу вас, как стать опытным пользователем ИИ. Подписка бесплатна!

1. Собственное строительство или покупка в эпоху магистратуры в области права.

Когда вызов API перестаёт иметь смысл

Раньше этот вопрос звучал так: обучаем ли мы собственную модель? Этот вопрос в основном решен. Сейчас почти никто не обучает модели с нуля.

Версия 2026 года сложнее.

Теперь у вас есть 3 варианта : обратиться к API, доработать модель с открытым исходным кодом или создать и разместить собственный стек. Каждый из них имеет совершенно разные кривые затрат и совершенно разные сценарии отказов.

Опрос Omdia 2025 года, проведенный среди 376 технических и деловых заинтересованных сторон, показал, что 95% согласились с тем, что строительство обеспечивает большую индивидуализацию и контроль [1].

Тот же опрос показал, что 91% респондентов согласились с тем, что готовые платформы внедряются быстрее . Обе цифры верны одновременно, и в этом проблема.

Конкретность проявляется в масштабе . При количестве запросов менее 100 000 в день обращение к API, такому как GPT-4o Mini, обычно является правильным решением. Низкие накладные расходы. Быстрая итерация. При количестве запросов более 1 миллиона в день затраты на токен начинают съедать прибыль [2].

Вот часть, которую команды недооценивают. Анализ 2024 года показал, что оборудование и электроэнергия составляют лишь 20-30% от стоимости самостоятельного размещения. Остальные 70-80% приходятся на персонал [2]. Это означает, что в большинстве таблиц «создать или купить» учитываются графические процессоры, а инженеры остаются без внимания.

Другое исследование показало, что команды в среднем превысили свои бюджеты расходов на LLM на 340% . В большинстве случаев причиной было отсутствие отслеживания использования на уровне арендаторов и отсутствие распределения затрат на уровне запросов, а не сама ставка за токен [3].

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

Привязка к фреймворку проявляется позже и проявляется очень остро. Функция генерации текста в Hugging Face перешла в режим поддержки в конце 2025 года, и командам, которые использовали её в своих разработках, пришлось перейти на другой фреймворк. Командам, которые использовали API, ничего делать не пришлось.

Практичная рама, которую я использую:

• Начнём с API.
• С первого дня система мониторинга каждого звонка включает в себя данные о стоимости, задержке и назначении функций.
• Переключайтесь, когда этого требуют математические расчеты.

2. Сложность модели против ремонтопригодности

Кто займется отладкой этого за 6 месяцев?

В известной статье Google был представлен принцип CACE : Изменение чего-либо меняет всё [4].

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

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

Почему? Потому что данные сложнее отслеживать, сложнее версионировать и сложнее объяснить тому, кто унаследует систему через 6 месяцев.

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

На практике команды выбирают более сложную модель ради повышения точности на 2% и платят за этот выбор в течение 18 месяцев временем на отладку, затратами на переобучение и «убытком в виде потери памяти о том, зачем мы это сделали».

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

Узнайте, как предоставить вашему любимому ИИ неограниченный доступ к обновляемому контексту : Предоставьте своему ИИ неограниченный доступ к обновляемому контексту | На пути к науке о данных

3. Количество данных против качества данных

Больше данных — не всегда решение.

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

Исследования показывают, что при превышении порога шума добавление большего количества низкокачественных данных приводит к выравниванию или ухудшению производительности модели [6].

Это означает, что взаимосвязь между размером выборки и точностью нарушается, как только уровень шума превышает определённый уровень!

Проблема «болота данных» — вот как это выглядит в компаниях. Команды собирают всё подряд, потому что хранение данных обходится дёшево, и они предполагают, что это когда-нибудь пригодится.

Без управления вы получаете пул, очистка которого занимает недели, увеличивает затраты на хранение и обработку данных, а также замедляет эксперименты, не улучшая результатов [7].

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

На практике я нахожу следующий вопрос:

Насколько шумно у нас работает, и что нам даст дополнительный час уборки по сравнению с дополнительным днем вывоза мусора?

4. Пропускная способность против задержки: пакетная обработка или обработка в реальном времени.

Пакетная обработка или обработка в реальном времени

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

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

Вывод в реальном времени : прогнозы по запросу, от миллисекунд до секунд. Всегда актуальные и более дорогие (круглосуточная работа). Больше движущихся частей и сложнее контролировать [8].

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

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

Но для решения большинства бизнес-задач не требуются прогнозы с точностью до долей секунды!

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

Практический совет: если ваши пользователи не заметят, если прогноз сделан 5 минут назад или 5 миллисекунд назад, используйте пакетный вывод вместо вывода в реальном времени.

5. Оперативное проектирование против тонкой настройки

Две совершенно разные инвестиционные кривые

За последние месяцы логика принятия решений здесь стала более понятной.

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

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

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

Вот реальный пример, который я видел: тонкая настройка GPT-4o для чат-бота службы поддержки клиентов обошлась примерно в 10 000 долларов США на вычислительные ресурсы и 6 недель на подготовку данных [9]. Альтернатива RAG была выпущена за 2 недели.

Моё мнение о современных рекомендациях для практикующих специалистов: начинайте с подсказок .

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

Анализ 2025 года показал, что быстрая оптимизация с помощью таких инструментов, как DSPy, превосходит тонкую настройку на 6–19 пунктов по некоторым бенчмаркам, используя в 35 раз меньше развертываний [10].

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

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

6. Автоматизация против человеческого контроля

Насколько вы доверяете модели в плане самостоятельного действия?

В производственной сфере важно задать вопрос: какова цена неверного решения и кто её несёт?

Концепция «человек в контуре управления» (Human-in-the-loop, HITL) занимает определённое место в спектре.

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

Большинство производственных систем находятся где-то посередине, направляя прогнозы с низкой степенью достоверности людям и пропуская прогнозы с высокой степенью достоверности [11].

Но операционные издержки HITL реальны: пересмотр каждого решения, принятого моделью, не масштабируется!

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

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

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

Вот как можно осмыслить этот разрыв:

• Искусственный интеллект справляется с обработкой больших объемов данных, скоростью и распознаванием образов.
• Человек способен справиться с необратимостью.

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

Что следует вынести из этого опыта

Если бы мне пришлось свести 6 компромиссов к одному принципу , он звучал бы так: в производстве издержки принятия решения редко оплачиваются там, где это решение принимается.

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

Некачественные данные в больших масштабах обходятся вам в циклах переобучения. Умные подсказки приводят к уязвимости в крайних случаях. А полная автоматизация обходится вам дорого, когда происходит что-то необратимое!

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

Спасибо за чтение!

Ссылки

[1] Omdia, Навигация по динамике «создание против покупки» для ИИ, готового к использованию на предприятиях (2025).

Источник: https://www.techtarget.com/searchenterpriseai/tip/LLM-build-vs-buy-A-decision-framework-for-LLM-adoption

[2] Птолемей, LLM Общая стоимость владения 2025: Математика строительства против покупки (2025).

Источник: https://www.ptolemay.com/post/llm-total-cost-of-ownership

[3] Тяньпань, Решение о строительстве или покупке инфраструктуры для программы LLM, которое большинство команд принимают неправильно (2026).

Источник: https://tianpan.co/blog/2026-04-15-build-vs-buy-llm-infrastructure

[4] Д. Скалли и др., Скрытый технический долг в системах машинного обучения (2015), NeurIPS.

Источник: https://lathashreeh.medium.com/hidden-technical-debt-in-machine-learning-systems-27fa1b13040c

[5] CMU MLIP, Технический долг — машинное обучение в производстве (2024).

Источник: https://mlip-cmu.github.io/book/22-technical-debt.html

[6] Z. Qi et al., Влияние некачественных данных: экспериментальная оценка (2018).

Источник: https://arxiv.org/pdf/1803.06071

[7] С. Сигари, Достижение баланса между качеством и количеством данных в машинном обучении (2023).

Источник: https://medium.com/@sigari.salman/striking-the-balance-between-data-quality-and-quantity-in-machine-learning-1f935a89f59b

[8] C. Чжоу, Пакетный вывод против вывода в реальном времени: что, когда и почему (2025).

Источник: https://medium.com/@conniezhou678/be-a-better-machine-learning-engineer-part-1-batch-inference-vs-0857587bf39a

[9] С. Йолфаи, Тонкая настройка против RAG против оперативного проектирования: когда что использовать (2025).

Источник: https://medium.com/@sa.aghadavood/fine-tuning-vs-rag-vs-prompt-engineering-when-to-use-what-b288340e33aa

[10] LLM Stats, Is Fine-Tuning Better Than Prompt Engineering in 2026? (2026).

Источник: https://llm-stats.com/blog/research/fine-tuning-vs-prompt-engineering-2026

[11] А. Масуд, Операционализация доверия: ИИ с участием человека в масштабе предприятия (2025).

Источник: https://medium.com/@adnanmasood/operationalizing-trust-human-in-the-loop-ai-at-enterprise-scale-a0f2f9e0b26e

Сара Нобрега Посмотреть все работы Сары Нобреги

Источник: towardsdatascience.com