Заказчик формулирует задачу своими словами, а у вас есть секунд тридцать, чтобы разместить её на карте из прошлой главы, пока разговор не ушёл дальше. Эта глава — такая карта, уже заполненная для пяти направлений, откуда приходит большинство AI-запросов. По каждому: фраза, которую реально говорит заказчик, класс решения, к которому она сводится, данные, которые должны существовать до того, как написана первая строчка предложения, и провал, который проявляется через полгода, а не в день запуска.
Ни в одном пункте ниже нет названий вендоров или продуктов — сознательно. Это каталог форм, а не шорт-лист: форму вы уносите с собой в переговорку, а вендора выбираете потом, отдельно, с бюджетом и тендером.
6.1 Поддержка клиентов
Запрос звучит как «хотим чат-бота на сайт» или «служба поддержки тонет в тикетах». Под одной формулировкой на самом деле скрываются три разных проекта.
Чат-бот отвечает клиенту напрямую, без человека между ответом и отправкой. RAG по базе знаний отвечает на те же вопросы, но черновик сначала видит оператор. Ассистент для операторов живёт внутри инструментов самого оператора: подсказывает формулировку, поднимает нужный регламент, суммирует переписку — а решает и нажимает «отправить» по-прежнему человек.
Нужные данные: база знаний или библиотека макросов, из которой действительно есть что доставать, и служба поддержки, готовая пару недель поработать под присмотром — чтобы понять, какая доля обращений реально закрывается документом, а какая требует заглянуть в заказ или в личный кабинет.
Стоит сказать прямо: обычно правильный первый проект — это ассистент оператора, а не чат-бот для клиентов. Чат-бот публичен и работает без присмотра: любая ошибка долетает до клиента, который её и получил, а любой пробел в базе знаний превращается в неверный ответ с именем компании под ним. Ассистент, который подсказывает обученному оператору, даёт человеку шанс поймать тот же пробел до того, как он вышел наружу, — и запускается на той неидеальной базе знаний, которая реально есть в компании, а не на той причёсанной, которая нужна чат-боту. Заказчики почти всегда хотят сразу чат-бота, потому что это выглядит как более крупная победа. На деле это обычно третий проект, а не первый.
Частое разочарование: база знаний писалась для поиска сотрудниками, которые уже знали, что ищут, а не для системы, которой нужно ответить на настоящий, коряво сформулированный вопрос клиента. Поиск отрабатывает честно; найденные фрагменты отвечают на другой вопрос, и это замечают только после запуска.
6.2 Продажи
Три запроса, часто от одного и того же руководителя продаж в рамках одного разговора: «менеджеры ничего не находят в CRM», «предложения готовятся слишком долго» и «помоги ответить на это письмо от тендерного отдела».
Поиск информации по CRM — это RAG, когда вопрос звучит как «что обсуждали с этим клиентом в прошлом квартале»: индексируются заметки, записи звонков, переписка. Но стоит вопросу превратиться в «сколько сделок в этом сегменте закрылось выше такой-то суммы» — а это число, а не фрагмент текста, — и задача становится text2SQL. Менеджеры задают оба вопроса подряд, не замечая разницы, — это и есть ловушка вопросов-близнецов из прошлой главы.
Подготовка коммерческих предложений — задача для ассистента: он выдаёт черновик, который человек правит, в идеале собирая типовые блоки и логику ценообразования из прошлых выигранных предложений, а не начиная с чистого листа. Ответы на входящие письма устроены так же, только у́же: черновик, не отправка, и кнопку по-прежнему нажимает менеджер, который знает клиента.
Нужные данные: CRM, где заметки — это действительно заметки, а не статус в одно слово, и, для предложений, архив прошлых документов, желательно с пометкой «выиграно / проиграно», чтобы модель не училась поровну на успехах и провалах.
Частое разочарование: половина реального знания о сделке живёт в голове менеджера или в переписке в мессенджере, а не в CRM, поэтому система уверенно отвечает по той половине, что записана, а руководитель считает, что она видела всё.
6.3 Юридические процессы
Формулировка здесь обычно конкретная: «нужно быстрее проверять договоры», «сравни этот проект с нашим типовым шаблоном» или «вытащи из этой пачки PDF все стороны, даты и обязательства».
Анализ договоров — подсветить рискованные пункты, суммировать обязательства — это ассистент, читающий один документ за раз, иногда с RAG по библиотеке прежних договоров ради прецедентов. Сравнение документа с шаблоном — задача у́же и механичнее, с более чёткой правильной формулировкой ответа, поэтому с неё безопаснее начинать. Извлечение сущностей — стороны, даты, суммы, условия продления — превращает неструктурированные договоры в строки таблицы и часто оказывается тихой предпосылкой для всего остального в этом направлении: вопрос «какие договоры продлеваются в этом квартале» нельзя задать базе данных, пока кто-то не вытащил дату продления из каждого договора.
Нужные данные: корпус договоров в читаемом формате, а не отсканированные факсы, и, в идеале, типовой шаблон или чек-лист, определяющий, что в этой компании считается «рискованным», — у модели нет собственного мнения о приемлемых лимитах ответственности без него.
Частое разочарование: юридическая проверка сильно завязана на прецедент, а не на общие знания. Пункт, стандартный в одной юрисдикции или отрасли и тревожный в другой, будет одинаково подсвечен — или одинаково пропущен, — пока системе не объяснили, что здесь считается нормой.
6.4 Знания компании
«Наша вики — кладбище», «никто не может найти нужный документ» и «хочу задать компании вопрос и получить ответ» — три формулировки одного и того же раздражения, и они соответствуют трём разным уровням амбиций.
Корпоративный поиск — самый скромный и самый надёжный вариант: улучшенный поиск по тому, что уже есть, с правильным ранжированием и правами доступа, возвращающий документы, а не готовые ответы. Умная база знаний добавляет сверху сгенерированный ответ — то есть это RAG, только теперь на масштаб всей компании, а не одной команды с её тикетами. Ассистент сотрудника идёт ещё дальше и часто подключает не только документы, но и корпоративные системы — остаток отпуска из HR, статус заявки из IT-сервиса, — отвечая на вопросы, наполовину документные, наполовину про текущее состояние систем.
Нужные данные здесь всегда сводятся к одному слову, и оно не опционально: права доступа. Поисковая система наследует те права, что уже есть у документов, — или становится самым быстрым способом для стажёра прочитать положение о выходных пособиях для руководства. Об этом стоит говорить до выбора технологии, а не после удачного демо.
Частое разочарование: пилот собирают на чистом подмножестве — аккуратной папке одного отдела — и он работает прекрасно. При раскатке на всю компанию система упирается в десять лет продублированных, противоречащих друг другу и ничьих документов, и честный ответ превращается в «я нашла три версии этого регламента, и они расходятся» — правильный ответ, который никто не хотел услышать.
6.5 Аналитика и отчётность
«А можно просто спросить у дашборда» — так формулируется запрос, и он чисто сводится к text2SQL по хранилищу данных: вопрос на обычном языке превращается в запрос, как уже разбиралось в прошлой главе.
Нужные данные — тот же вопрос о готовности хранилища из раздела 5.3: схема, которую человек способен объяснить, в идеале с уже собранными витринами, где заранее договорились, что считать «активным клиентом» или «выручкой за месяц», — потому что модель, которой поручат разрешить это разногласие, разрешит его молча и непоследовательно.
Честная оговорка, которую в этом направлении особенно стоит повторить: результат выглядит как число, а числа читаются как факты. Цифра, полученная таким способом, всё равно нуждается в шаге проверки, прежде чем попасть в отчёт. Аккуратно отформатированный, уверенно звучащий ответ никак не выдаёт, ушёл ли джойн в те таблицы, что нужно. Провал здесь не заметен как сбой — это правдоподобное число, выданное с полной уверенностью, которое незаметно неверно ровно до того момента, пока кто-то из руководства не задаст уточняющий вопрос, на который аналитик не сможет ответить.
Что взять с собой на встречу
Каталог сжимается до четырёх вопросов в этом порядке, независимо от направления: что заказчик реально просит своими словами? К какому классу решения из прошлой главы это сводится? Какие данные и в каком виде должны существовать до первого дня проекта? И каким характерным способом проект такого класса обычно разочаровывает — чтобы назвать это заранее, а не объяснять постфактум.
Заказчик, который слышит от вас название будущего провала ещё до того, как заплатил хоть рубль, доверяет остальной части предложения больше, а не меньше.