Языковые модели вошли в рабочий обиход быстрее, чем сложились привычки их использования. Мы применяем их в разработке и поддержке ежедневно и внедряем ассистентов клиентам, поэтому хорошо видим границу между теми, кто получает от модели пользу, и теми, кто через неделю говорит, что она пишет ерунду. Разница почти всегда не в модели, а в том, как с ней разговаривают. Ниже — пять ошибок, которые встречаются чаще всего, и что делать вместо них.
Ошибка 1. Вопрос вместо задачи
Типичный запрос звучит так: «расскажи про CRM». Модель отвечает обзорной справкой, которую можно найти в любой энциклопедии, и пользователь делает вывод, что инструмент бесполезен. Проблема в том, что вопрос не содержит задачи: непонятно, кто спрашивает, зачем и что должно получиться на выходе.
Рабочая формулировка описывает четыре вещи: роль, исходные данные, результат и ограничения. Вместо «расскажи про CRM» — «мы небольшая производственная компания, заявки ведём в таблице, теряем повторные обращения. Опиши, какие данные нужно перенести в CRM в первую очередь и какие поля обязательны. Ответ — списком, без рекламы конкретных систем». Такой запрос даёт применимый ответ с первой попытки.
Ошибка 2. Модель должна догадаться о контексте
Вторая по частоте ошибка — не давать материалов. От модели ждут разбора текста, который ей не показали, или правки кода, который она не видела. Модель не имеет доступа к вашим файлам, базе и переписке. Всё, что не приложено к запросу, для неё не существует.
Прикладывайте фактуру: фрагмент кода целиком, а не пересказ; текст ошибки полностью, а не «выдаёт ошибку»; пример правильного результата, если он есть. Один хороший образец заменяет три абзаца объяснений — это самый дешёвый способ поднять качество ответа.
Ошибка 3. Останавливаться на первом ответе
Работа с моделью — диалог, а не запрос к справочнику. Первый ответ почти всегда общий: модель не знает, какие из ваших ограничений важнее. Второй и третий заходы с уточнениями дают заметно лучший результат, чем попытка сразу написать идеальный запрос.
- Отсекайте лишнее: «убери всё про облачные решения, у нас закрытый контур».
- Просите альтернативы: «дай три варианта структуры и коротко объясни, чем они отличаются».
- Проверяйте рассуждение: «перечисли допущения, на которых построен ответ».
- Меняйте форму: «то же самое таблицей, столбцы — этап, срок, ответственный».
И обратное правило: если диалог тянется давно и накопил противоречивые правки, дешевле начать новый с уже уточнённой постановкой, чем распутывать старый.
Ошибка 4. Принимать факты на веру
Языковая модель предсказывает правдоподобный текст, а не сверяется со справочником. Поэтому она уверенно называет несуществующие функции библиотек, придумывает пункты нормативных документов и путает версии. Особенно опасны области, где ответ выглядит специальным и проверять его лень: юридические формулировки, параметры программных интерфейсов, статистика.
Наше рабочее правило простое: всё, что можно проверить исполнением или документацией, проверяется до применения. Код запускается, ссылки открываются, названия функций ищутся в официальной документации. Модель хороша как черновик и как способ быстро охватить варианты, но ответственность за факты остаётся на человеке.
Ошибка 5. Отправлять в чат то, что нельзя отправлять
Персональные данные клиентов, содержимое договоров, доступы, ключи, выгрузки из базы — всё это регулярно попадает в публичные чаты просто потому, что так быстрее. Между тем сотрудник не может ни отозвать отправленное, ни объяснить проверяющему, где именно теперь хранятся эти данные.
Минимальный набор правил, который стоит завести в компании: обезличивать примеры, не вставлять ключи и пароли, для регулярной работы с внутренними документами использовать решение в собственном контуре, а не публичный чат. Важно, что запрет без альтернативы не работает — сотрудники всё равно пользуются моделями, только тайком.
Сводка: как выглядит ошибка и что делать
| Ошибка | Как выглядит на практике | Что делать вместо этого |
|---|---|---|
| Общий вопрос | «Напиши текст про наши услуги» | Указать роль, аудиторию, объём, формат и запреты |
| Нет контекста | «Почему не работает форма?» | Приложить код, текст ошибки и описание ожидаемого поведения |
| Один заход | Ответ скопирован без правок | Два-три уточнения, запрос альтернатив и допущений |
| Доверие фактам | В код попала несуществующая функция | Проверка запуском и по документации |
| Чувствительные данные | В чат вставлена выгрузка с контактами клиентов | Обезличивание, решение в своём контуре |
| Нет процесса | Каждый сотрудник изобретает запросы заново | Общая библиотека проверенных запросов |
Что помогает встроить модель в работу
Отдельные удачные запросы пользы компании почти не приносят: они живут в переписке одного человека. Толк начинается тогда, когда появляется процесс.
- Выбрать две-три задачи, где потери времени очевидны: черновики писем, разбор обращений, подготовка описаний, первичная проверка кода.
- Собрать библиотеку запросов под эти задачи с примерами хороших и плохих ответов.
- Договориться, что можно отправлять во внешний сервис, а что нельзя.
- Определить, кто проверяет результат перед публикацией или отправкой клиенту.
- Через месяц пересобрать библиотеку: часть запросов окажется лишней, часть придётся уточнить.
Отдельно стоит сказать про ожидания. Модель не заменяет специалиста и не снимает с него ответственность. Она хорошо сокращает время на черновики, разбор больших объёмов текста и рутинные переформулировки — и плохо справляется там, где нужно знать контекст компании, которого нет в переписке.
Большинства этих ошибок не возникает, когда бот заменяется агентом с доступом к данным компании: чем они отличаются, разобрано на странице разработки ИИ-агентов.
Когда пора переходить от чата к ассистенту
Если одни и те же запросы повторяются каждый день, а нужные данные приходится каждый раз вставлять руками, работу пора автоматизировать. Ассистент подключается к вашим документам и системам, отвечает по внутренним регламентам и не требует от сотрудника помнить формулировки. Мы разрабатываем AI-ассистентов для бизнеса: разберём задачи, где это окупается, и соберём решение с учётом требований к данным.
