ИИ-разработка в Узбекистане: что действительно полезно

Большинство запросов об ИИ описывают технологию, а не проблему: компания хочет «ИИ-ассистента» или «ИИ в нашей CRM». Проекты, которые действительно работают, устроены наоборот — они начинаются с задачи, которая каждую неделю стоит компании реальных денег, и только потом выясняется, является ли ИИ самым дешёвым способом её решить. В этом руководстве — что реалистично для бизнеса в Узбекистане сегодня: какие задачи подходят, какие нет, как выбрать между покупкой и разработкой и что проверить, прежде чем что-либо подписывать.

Что на самом деле стоит за словами «ИИ-разработка»

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

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

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

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

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

Четыре типа задач, где ИИ окупается

Тип задачи	Признаки, что она подходит	Как выглядит хороший результат
Извлечение полей из документов	Большой объём, фиксированный набор полей, сотрудники перепечатывают данные вручную	Каждое поле возвращается с оценкой уверенности; сомнительные случаи уходят на проверку
Классификация по большому справочнику	Тысячи категорий, экспертиза сосредоточена в двух-трёх сотрудниках	Ранжированные подсказки с обоснованием, которые подтверждает человек
Ответы на вопросы по вашим документам	Сотрудники раз за разом спрашивают одно и то же; ответы есть, но их трудно найти	Ответ ссылается на исходный абзац и честно говорит «не найдено», когда данных нет
Прогноз на основе вашей истории	Годы чистых и единообразных транзакционных данных	Измеримый выигрыш по сравнению с эвристикой, которой вы пользуетесь сейчас

Общее у них одно: задача повторяется часто, на входе текст или изображения, а неверный ответ поправим, потому что человек видит его раньше, чем он успеет навредить. Задачи классификации подходят под это описание почти идеально — наш проект «Таможенный ИИ-ассистент» предлагает коды и показывает, на чём основано предложение, а окончательное решение остаётся за сотрудником. Если ваша идея не проходит ни одну из трёх проверок, у вас исследовательский проект, а не бизнес-проект.

Когда честный ответ — «здесь ИИ не нужен»

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

Купить, интегрировать или обучать

Путь	Когда подходит	Чем приходится платить
Купить готовый продукт	Задача типовая: транскрибация, перевод, распознавание стандартных бланков	Быстро и дёшево, но нет контроля над вашими нестандартными случаями, а данные уходят на условиях поставщика
Интегрировать облачную модель в свою систему	Задача языковая и требует ваших данных, прав доступа и рабочего процесса	Самый быстрый путь к решению, которое действительно подходит; постоянная плата за запросы и зависимость от версий модели у провайдера
Дообучить или развернуть модель у себя	Узкая повторяющаяся задача с большим числом размеченных примеров или жёсткие требования к хранению данных	Самые высокие затраты на старте и сопровождение; может быть дешевле в эксплуатации и остаётся внутри вашей сети

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

Работа на узбекском, русском и английском

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

• Качество модели неодинаково по языкам. Универсальные модели обучены на несравнимо большем объёме английских текстов, чем узбекских, и это видно на отраслевой лексике, отрицаниях и редких терминах. Промпт, который хорошо работает на английском, может просесть на узбекском. Тестируйте на том языке, на котором реально пишут ваши пользователи.
• Узбекский существует в двух алфавитах. В обиходе и латиница, и кириллица, пользователи их смешивают, а русские заимствования и транслитерированные имена кочуют между ними. Без нормализации документ, заведённый в одной графике, невидим для поиска в другой.
• Документы приходят фотографиями и сканами, часто на русском, иногда с печатями и рукописными пометками поверх печатного текста. Узким местом обычно оказывается качество распознавания, а не языковая модель, — и именно эту часть стоит прототипировать первой.
• Соберите отдельный проверочный набор на каждый язык. Фраза «всё работает», измеренная на английском, ничего не говорит об узбекском сценарии, а жалобы придут именно оттуда.
• Перевод на английский перед обработкой — допустимый приём, но он добавляет шаг, теряет нюансы и уводит ошибки ещё на один слой дальше от того места, где вы могли бы их заметить.

Как выглядит реалистичный проект

1. Постановка. Выберите одну задачу, назовите её текущую цену в часах или ошибках и договоритесь, что означает «лучше» в цифрах, ещё до того, как кто-то напишет первый промпт. Что идёт не так: границы расползаются от «классифицировать входящие счета» до «ассистент для финансового отдела».
2. Соберите проверочный набор до создания системы. Наберите реальные примеры с правильными ответами, намеренно включив в них неудобные. Что идёт не так: набор собирают из лёгких случаев, и качество выглядит отличным ровно до дня запуска.
3. Прототипируйте на этом наборе. Нескольких недель обычно достаточно, чтобы понять, жизнеспособен ли подход. Что идёт не так: прототип оценивают по живой демонстрации, поэтому ему достаточно справиться с теми примерами, которые кто-то решил попробовать.
4. Доведите до продакшена. Аутентификация, права доступа, журналы аудита, повторные попытки и экран проверки, которым занятой человек действительно будет пользоваться, — это обычная разработка ПО, и именно на неё уходит основная часть усилий. Что идёт не так: интерфейс проверки оказывается медленнее, чем сделать работу руками, и сотрудники тихо перестают им пользоваться.
5. Наблюдайте и улучшайте. Логируйте входные данные, ответы, уверенность модели и каждое исправление человеком. Исправления — ваш самый ценный набор данных: они показывают ровно те места, где система ошибается. Что идёт не так: не логируется ничего, и никто не может доказать, помогло решение или нет.

Точность — это не одно число

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

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

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

Данные, конфиденциальность и место запуска модели

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

Разграничение доступа должно жить в поиске по документам, а не в промпте. Если документ закрыт, он не должен попадать в контекст модели для пользователя, которому его читать нельзя, — инструкция «храни это в секрете» не является границей безопасности. Развёртывание модели с открытыми весами у себя оставляет данные внутри вашей инфраструктуры и меняет плату за API на расходы на оборудование и эксплуатацию; выбирайте этот путь ради реального регуляторного или договорного требования, а не из общей тревожности. Наш подход описан в услуге ИИ-разработки.

Вопросы, которые стоит задать любому ИИ-подрядчику

• Что является нашим проверочным набором, кто его собирает и можем ли мы увидеть результаты на нём, а не демонстрацию?
• Какие части этого предложения относятся к модели, а какие — к обычному программному обеспечению, которое вы бы всё равно разрабатывали?
• Что видит пользователь, когда система не уверена в ответе?
• Какие данные покидают нашу сеть, какому провайдеру и на каких условиях хранения?
• Если этот провайдер поднимет цены, снимет модель с поддержки или столкнётся со сбоем, каков план действий?
• Кому принадлежат код, промпты, проверочный набор и веса дообученной модели?
• Во сколько обходится эксплуатация в месяц при нашем объёме и как эта сумма растёт?

Итог

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