Коротко

Разработка ИИ в Казахстане редко начинается с вопроса «какую модель взять». В реальных проектах всё быстрее упирается в язык, каналы и ответственность. Клиент пишет по-русски, вставляет казахские слова, потом кидает голосовое в WhatsApp. Кандидат отвечает латиницей: «smena keshki bar ma?». Сотрудник ищет инструкцию не по официальному названию, а по слову, которым все пользуются в филиале.

Государственная рамка уже есть: правительство приняло Концепцию развития искусственного интеллекта на 2024-2029 годы. Но для бизнеса ИИ проверяется не на презентации. Он проверяется в amoCRM, Bitrix24, 1C, WhatsApp, Telegram, Google Docs, PDF-инструкциях и таблицах, куда сотрудники руками переносят данные.

Поэтому локальный AI-проект надо проектировать от процесса. Модель важна, но сама по себе она не знает, как у вас называются филиалы, где лежит актуальный регламент, кто имеет право обещать скидку и почему «аға, бүгін заберу» может быть нормальным клиентским сообщением, а не шумом.

Что ломает красивые AI-демо

На демо всё обычно чисто. Есть вопрос. Есть база знаний. Агент отвечает. Все довольны.

В живом процессе вопрос приходит не так. Клиент пишет кусками, без контекста, с ошибками, с фото документа, с фразой на двух языках. Менеджер может вести сделку в amoCRM, оплату смотреть в 1C, а важную договорённость держать в личном WhatsApp. Если агент видит только один кусок этой картины, он будет уверенно ошибаться.

Отдельная тема - казахский и shala-Kazakh. Исследования вроде Do LLMs Speak Kazakh? хорошо напоминают: нельзя считать, что большая модель «и так всё понимает». В проекте нужны свои примеры. Не литературные. Настоящие: «можно ертен?», «скиньте договор ватсапқа», «жалақы қанша выходит», «филиал Абая возле магнума».

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

Где локализация важнее всего

В HR агенту мало знать название вакансии. Ему нужны город, район, график, транспорт, язык кандидата и готовность выйти в конкретный филиал. В Magnum HR Agent такая логика важнее красивого ответа: рекрутеру нужна структурированная карточка, а не эссе.

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

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

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

Как собирать языковую базу

Хороший старт - не промпт. Хороший старт - выгрузка реальных примеров.

Для пилота обычно достаточно 200-500 кейсов: переписки, заявки, резюме, тикеты, документы, внутренние вопросы сотрудников. Их надо разметить не академически, а по делу: какой был intent, что должен сделать хороший сотрудник, где нужен уточняющий вопрос, где нельзя отвечать без человека.

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

Это скучно. Зато именно здесь появляется качество.

Архитектура без лишней магии

Для большинства компаний не нужен «свой ChatGPT». Нужен рабочий контур вокруг модели.

Минимальный контур выглядит так: канал входа, нормализация сообщения, поиск по источникам, правила риска, ответ или черновик действия, лог, оценка качества. Если агенту нужно действовать, добавляются инструменты: CRM, task tracker, база документов, почта, мессенджер, иногда 1C. На первом этапе лучше давать чтение и подготовку черновиков, а не прямую запись в критичные системы.

Если система отвечает по документам, нужен не просто vector search. Нужны метаданные, приоритет источников, свежесть, гибридный поиск, reranking и правила отказа. Иначе агент найдёт похожий текст, но не тот регламент. Это подробно разобрано в статье про RAG и почему embedding’ов недостаточно.

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

Что тестировать до запуска

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

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

Здесь помогают evals для AI-проектов. Это не «тесты ради тестов». Это способ понять, стало ли лучше после изменения промпта, базы знаний или модели.

С чего начать компании

Выберите один процесс, где язык и ручная рутина уже стоят денег. Не «весь бизнес». Один поток.

Хорошие первые кандидаты: первичный HR-скрининг, ответы поддержки в WhatsApp, поиск по внутренним инструкциям, контроль сделок в CRM, проверка документов перед согласованием. Для каждого можно собрать данные, назначить владельца и за 30 дней понять, есть ли смысл масштабировать.

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

FAQ

Нужно ли обучать свою модель на казахском?

Не всегда. Часто хватает сильной модели, локальных примеров, словарей, RAG и evals. Своя модель или fine-tuning нужны, когда есть объём, требования к приватности, стоимость запросов или стабильная языковая проблема, которую нельзя закрыть проще.

Можно ли запускать ответы клиентам сразу?

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

Что важнее: казахский язык или интеграции?

Оба слоя связаны. Если агент понял фразу, но не видит CRM или 1C, он не сможет дать полезный ответ. Если он видит данные, но плохо понимает смешанный язык, он выберет не тот сценарий.

Как понять, что подрядчик умеет локальные проекты?

Попросите показать, как он тестирует русский, казахский, латиницу, WhatsApp-диалоги, филиалы, роли, права доступа и передачу человеку. Если ответ только про модель, этого мало.