AI-функции, которыми клиенты реально пользуются (и которые игнорируют)

Большинство AI-функций для бизнеса умирает на этапе демо. На пятничной презентации они выглядят впечатляюще, собирают одобрительные кивки, уезжают в продакшен — а через три недели ими никто не пользуется. Я выкатил их достаточно много — чат-боты, генерацию контента, интеллектуальный поиск — на Vercel AI SDK, чтобы увидеть чёткую закономерность: какие из них окупаются, а какие превращаются в дорогостоящую витрину для демо. Дело почти никогда не в модели. Дело в том, была ли функция привязана к метрике до того, как написана хоть одна строка кода.

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

Тест, который я провожу перед тем, как строить любую AI-функцию

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

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

Вот и весь фильтр. «Было бы круто, если бы сайт умел общаться в чате» не называет ни одной метрики — значит, это витрина для демо. «Команда нашего шоурума каждый день отвечает на одни и те же 40 вопросов о запасе хода и зарядке» называет отклонение запросов — значит, это продукт. Разница кроется в том, как клиент описывает проблему, а не в технологии. Витрину для демо слышно уже в брифе.

AI-функции, которые действительно сработали

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

Это самая недооценённая AI-функция для бизнеса и та, которую я почти всегда стал бы строить первой. На региональной EV-платформе NIO каталог и контент живут в Sanity, а региональная аудитория ищет на смеси английского и транслитерации с непостоянной орфографией. Обычный поиск по ключевым словам не вернёт ничего по запросу «battary range» или недопечатанному названию модели — а страница с нулём результатов означает потерянного лида.

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

Заземлённый чат-бот, но только на правильной поверхности

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

Поверхность важна не меньше, чем сама реализация. Тот же бот, который бесполезен, прикрученный к маркетинговой главной странице, отлично работает внутри личного кабинета или сценария поддержки, где вопросы узкие, а у пользователя уже есть намерение. Для продукта вроде HR-платформы alfii вопрос «как провести зарплату для сотрудника, вышедшего в середине месяца» — это ограниченный, отвечаемый вопрос к собственной документации продукта. Это отклоняет реальное обращение. «Расскажите о вашей компании» на лендинге — нет. Именно поэтому я встраиваю функцию в продукт, а не в универсальный виджет — она должна стоять рядом со всем остальным в инженерном AI-проекте, а не быть прикручена сбоку.

Генерация контента как движок черновиков, но никогда как кнопка публикации

Генерация контента работает, когда она пишет черновик, а человек его одобряет, и проваливается в тот момент, когда вы разрешаете ей публиковать без присмотра. В проектах на CMS я встраиваю генерацию прямо в редактор — первые черновики описаний товаров, alt-текст, мета-описания, перевод между английским и русским — как кнопку, которую редактор нажимает, проверяет и правит. Метрика — это сэкономленные часы на каждый опубликованный материал, и она велика: миграция каталога, которая раньше отнимала неделю копирайтинга, превращается в день правок. Всё живёт внутри стека — в том же редакторе Sanity, которым маркетинговая команда уже пользуется, — так что осваивать новый инструмент не нужно. Человек остаётся в контуре, поэтому голос бренда и юридические риски остаются под контролем.

AI-функции, которые превратились в витрину для демо

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

• Чат-консьерж на главной странице. Выглядит как будущее, не отклоняет ничего, потому что никто не приходит на главную страницу с ограниченным вопросом. Хорошая версия этого — поиск, а не чат.
• «AI-рекомендации» без данных за ними. Рекомендательный движок хорош ровно настолько, насколько хороши поведенческие данные, которые его кормят. На свежем каталоге без истории покупок это виджет случайного товара с иконкой-блёсткой. Сначала выкатите аналитику; добавляйте AI, когда появится сигнал.
• Автономный агент, прогоняющий весь рабочий процесс. Vercel AI SDK выпустил по-настоящему хорошие полноценные агентские циклы — многошаговое планирование, последовательность вызова инструментов, условия остановки — и они полезны для ограниченных внутренних задач. Но «агент, который ведёт весь процесс продаж» — это самое дорогое демо, которое можно построить: каждый лишний автономный шаг умножает поверхность отказов, а одно неверное действие на глазах у клиента обходится дороже, чем экономит вся функция. Я держу агентов внутренними, под надзором и узкими.
• Чат-бот, который сам себя «разземляет». Бот без извлечения и без пути к отказу уверенно выдумает политику возврата. Это не функция, это обуза с индикатором набора текста.

Почему выбор модели — наименее интересное решение

Я строю всё это model-agnostic намеренно. Vercel AI SDK даёт единый интерфейс над Claude, OpenAI и Google, так что смена провайдера — это изменение конфига, а не переписывание. Это важно, потому что фронтир тасуется каждые несколько месяцев — лучшая модель для суммаризации, для вызова инструментов, по стоимости за токен и под ваш бюджет задержки — это редко одна и та же модель, и редко одна и та же в следующем квартале.

Поэтому я отношусь к провайдеру как к рантайм-решению, а не к архитектурному. Берите самую дешёвую модель, которая проходит эвалы для задачи; держите подключённый запасной вариант на случай, когда у API плохой день; никогда не позволяйте выбору провайдера протекать в код продукта. Интересная инженерия никогда не была про модель. Она про неброские 80% вокруг неё.

Те 80%, которые делают AI-функцию надёжной

Задемонстрировать чат-бота может кто угодно. Работа, благодаря которой AI-функция переживает столкновение с реальным трафиком, — это та часть, которую никто не скриншотит:

• Эвалы. Набор тестов из реальных вопросов с ожидаемым поведением, прогоняемый при каждом изменении промпта или модели, чтобы вы знали, не сломало ли «улучшение» что-то тихо.
• Заземление и отказы. Извлечение по реальным данным, цитирование и явный путь «я не знаю». Функция, которая не умеет сказать «нет», — это функция, которая врёт.
• Запасные варианты и потолки по стоимости. Второй провайдер на случай отказа первого и жёсткий лимит расходов, чтобы всплеск трафика или петля prompt-injection не накрутили за ночь счёт в пять цифр.
• Наблюдаемость. Логирование входов, выходов и стоимости каждого вызова, чтобы вы могли измерять обещанную метрику, а не гадать.

Именно это отличает AI-функцию от AI-демо, и это бóльшая часть инженерии. И именно поэтому я вшиваю AI в существующее приложение на Next.js или Laravel, а не прикручиваю сторонний iframe — чтобы быть надёжной, функция должна разделять аутентификацию, данные, лимиты запросов и пайплайн деплоя приложения.

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