Искусственный интеллект. С неба на землю

Из практики: схема «чат + файл»

Что делать с переполнением — проще, чем кажется. Два правила. Первое: ведите работу в чате, но периодически сохраняйте главное в документ-якорь — решения, договорённости, наработки, черновики. Второе: как только чат начал деградировать — не боритесь с ним. Открывайте новый и начинайте с файла-якоря: «вот наработки, продолжаем отсюда». Свежий контекст плюс накопленный артефакт всегда сильнее длинного уставшего диалога.

В агентных режимах (Cowork у Anthropic и аналоги у других вендоров) проблема снята архитектурно: агент работает с файлами напрямую, сам актуализирует их по ходу работы, и переписка не забивает его память. Но это история про работу за компьютером. На телефоне вы, как правило, в обычном чате или проекте — и там переезжать в новый чат с файлом-якорем придётся заметно чаще. Принцип один, и он важнее инструмента: истина живёт в артефакте, а не в переписке. Чат — рабочая поверхность, файл — память.

Забегая вперёд: именно так устроен мой дневник из Главы 21 — один чат на месяц, в конце месяца «Снимок», с которого начинается следующий.

Прослеживаемость источника: требование, а не пожелание

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

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

Резюме главы

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

Ключевые выводы

— Девять из десяти ИИ-проектов строятся на больших языковых моделях; их сила — в предобученности.

— RAG работает как «факт-чекер» и снижает галлюцинации, Fine-tuning подстраивает модель под ваш стиль и данные.

— Ошибка LLM на одном шаге ломает всю цепочку рассуждений — спорить с моделью бессмысленно: начните заново или пересоберите рассуждение открытым вопросом (Глава 6).

Что с этим делать: Для корпоративных задач подключайте LLM к своим данным через RAG и не стройте критичные процессы на «голом» чате.

Вопрос для рефлексии: Какие ваши базы знаний и документы стоит подключить к LLM через RAG?

Глава 6. Промпт-инжиниринг: дисциплина постановки задач для ИИ

Промпт как управленческий инструмент

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

Вокруг prompt engineering долго было много мифов — специальные символы, секретные формулы, «магические» слова. Для большинства рабочих задач всё это не нужно. Разница между слабым и сильным запросом не в хитростях, а в том, что у модели есть роль, контекст, цель, входные данные, формат, ограничения и критерий хорошего результата. Поэтому создание инструкций — это не второстепенная техника для энтузиастов, а управленческий инструмент: по сути, дисциплина постановки задач, перенесённая на работу с машиной.

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

Базовая структура запроса

Для большинства практических задач достаточно простой формулы:

РОЛЬ — КОНТЕКСТ — ЗАДАЧА — ВХОДНЫЕ ДАННЫЕ — ФОРМАТ — ОГРАНИЧЕНИЯ — КРИТЕРИЙ ХОРОШЕГО РЕЗУЛЬТАТА

Структура удобна тем, что подходит и для простого общения с чат-ботом, и для проектирования корпоративных ассистентов. Базовые правила хорошего запроса:

— Начинайте с конкретной цели. Не «расскажи про маркетинг», а «предложи 10 тем для публикаций о промышленной автоматизации для директоров заводов».

— Давайте контекст. Кто вы, для кого нужен ответ, в какой ситуации он будет использоваться.

— Передавайте входные данные. Документ, таблица, выдержка из переписки, описание процесса — всё это резко повышает предметность ответа.

— Сразу задавайте формат ответа. Таблица, список шагов, письмо, записка, сценарий разговора, структура слайдов.

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

— Разделяйте сложные задачи. Если нужно и придумать идею, и оценить риски, и составить план — делайте это последовательными запросами.

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

— Не доверяйте первому ответу без проверки. Даже сильный запрос не отменяет галлюцинации и ошибки логики.

Пример «до и после». Слабый запрос: «Напиши про наш продукт» — общие рассуждения без конкретики, 3—5 итераций доработки. Сильный запрос: «Ты — маркетолог с 10-летним опытом в B2B-продажах. Контекст: наш продукт — облачная CRM для малого бизнеса (10—50 сотрудников); аудитория — собственники и директора, уставшие от Excel; преимущество — запуск за 1 день. Задача: описание продукта для главной страницы лендинга. Формат: 3 абзаца по 50—70 слов — проблема клиента, решение, конкретная выгода. Тон: профессиональный, языком выгод, с цифрами. Ограничения: НЕ упоминай конкурентов, НЕ используй избитые фразы („инновационный“, „лучший на рынке“)». Результат — текст с чёткой структурой, по брендбуку, готовый к использованию почти без доработки. По моему опыту, такая постановка даёт прирост качества на 30—50% и экономит несколько итераций.

Точность термина: почему слово решает

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

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

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

Пример из практики. «Проверь эту деталь на проблемы» — модель начнёт рассуждать обо всём сразу: от геометрии до логистики. «Проведи FMEA-анализ детали: виды отказов, причины, последствия, критичность» — и вы получаете структурированный разбор в принятой инженерной логике, короче и по делу. Слов в запросе почти столько же, результат — несопоставим.

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

Особенно часто с этой проблемой сталкиваются ИТ-разработчики, которые не обладают предметной экспертизой отрасли заказчика или продукта. В итоге возникают проблемы из-за недопонимания.

Рабочее правило: прежде чем отправлять запрос, спросите себя — как эту задачу называют профессионалы? Знаете отраслевой термин, стандарт или методику — называйте прямо: «по SWOT», «в нотации BPMN», «FMEA-анализ», «наряд-допуск», «дефектоскопия». Не знаете — попросите модель предложить терминологию и проверьте её.

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

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

Отсюда правило, которое стоит запомнить дословно: ИИ не исправляет плохо поставленную задачу — он её масштабирует. Размытое поручение человеку оборачивается переделкой; размытый запрос ИИ — правдоподобным, быстрым и бесполезным результатом.

Формула качества задачи

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

Про постановку мы говорим всю эту главу. Пройдёмся по остальным трём.

Объём: не давайте ИИ сразу большую задачу. «Напиши стратегию развития» одним запросом — почти гарантированный провал. На длинной дистанции модель в какой-то момент свернёт не туда — и испорченным окажется весь результат. Причём заметите вы это в самом конце. Дробите: анализ → варианты → выбор → план, с вашей проверкой на каждом стыке. Отклонение ловится на границе шага, пока оно стоит минуты, а не всей работы (не путать с итерациями, о которых поговорим дальше: там вы гоняете один и тот же результат до кондиции, здесь — режете работу на последовательные шаги). Простая проверка, по моему опыту: если результат — больше двух-трёх страниц или задача требует нескольких разных умений сразу (посчитать, написать, оценить) — дробите. Бонус, который редко замечают: маленькой задаче хватает более простой модели — а это в разы дешевле и быстрее. Большая задача тянет за собой «самую умную» модель; цепочка маленьких часто обгоняет её и по качеству, и по цене. Поделюсь собственной хитростью. Можно попросить саму модель разбить задачу на простые шаги — вам останется утвердить план и идти по нему.

Данные: любую задачу прогоняйте через три вопроса. Какие данные нужны — и передал ли я их модели? Откуда они и доверяю ли я источнику? Что модель будет делать там, где данных не хватит? Ответ на третий вопрос всегда один, и мы разбирали его в главе о генеративном ИИ: она дорисует пробел — правдоподобно и уверенно. Галлюцинация зачастую не «поломка модели», а дыра в данных или неточность в формулировке, которую вы не заметили при постановке. «Проанализируй наш договор» без приложенного договора — фантазия на тему типовых договоров. «Сводка продаж за квартал» без выгрузки — красивая таблица выдуманных цифр. Модель не виновата: вы попросили результат, не дав сырья. Это похоже на то, как дать человеку задачу, но не дать ресурсов.

Модель: под задачу, а не «самую мощную». В большинстве сервисов это переключатель прямо в шапке чата: «быстрая» или «лёгкая» модель — для рутины и коротких шагов, «умная» или «рассуждающая» — для сложного анализа. Для большинства шагов конвейера хватает быстрой. Сам принцип мы разобрали ещё в первой части: специализация бьёт масштаб, а рассуждающие гиганты проигрывают компактным моделям в точном пересказе фактов. Больше того: на практике сложная модель для простых задач, наоборот, портит результат. Например, когда мне нужно было просто перевести презентацию, я взял самую мощную модель — и на выходе получал поломанный файл. Она пыталась пересобрать всё с нуля. Я больше часа бился с задачей. Злился то на ИИ, то на себя. А как только переключился на более простой режим — всё получилось с первого раза.

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

И чтобы формула перестала быть теорией — один запрос в двух вариантах, с реальными ответами.

Один запрос — два ответа

Обычный запрос: «Сделай аналитику по обращениям клиентов». Ответ ИИ: «Обращения клиентов — важный канал обратной связи. В последнее время наблюдается рост числа обращений, прежде всего по вопросам качества сервиса и сроков. Число обращений выросло примерно на 25%. Рекомендуется усилить работу с обращениями, повысить скорость ответов и внедрить цифровые инструменты…» Проблема: общие слова, «25%» выдуманы, использовать в работе нечего.

Тот же запрос по формуле: «Ты — аналитик отдела клиентского сервиса. Проанализируй приложенный реестр обращений за второй квартал и подготовь: (1) топ-5 категорий по числу обращений с динамикой к первому кварталу; (2) три категории с наибольшим ростом просрочки; (3) три гипотезы причин с указанием, какими данными их проверить. Формат: таблица плюс не больше одной страницы выводов. Если данных не хватает — пиши „недостаточно данных“ вместо предположения. Работай только с приложенным файлом». Ответ ИИ: конкретные категории с цифрами и динамикой, рост просрочки по трём направлениям, проверяемые гипотезы — документ, с которым можно идти на совещание.

Разница не в модели — модель та же. Разница в том, что во втором случае есть роль, данные, формат, критерий остановки и запрет додумывать.

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

Четыре шаблона для разных ситуаций

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

S-M-A-R-T-P — когда задача уже понятна. S (Situation) — текущая ситуация; M (Mission) — требуемое изменение или цель; A (Actions) — что уже сделано; R (Restrictions) — ограничения и риски; T (Tools) — на что опираться; P (Payoff) — как понять, что результат хороший. Пример: «Ситуация: в службе закупок много ручной обработки заявок. Цель: определить три сценария применения GenAI для сокращения времени обработки. Уже сделано: описан процесс, собрана статистика. Ограничения: не выносить чувствительные данные во внешний контур, бюджет пилота до 3 млн рублей. Опираться на: описание процесса, статистику заявок за год, перечень уже закупленных ИТ-решений. Хороший результат: приоритизированный список сценариев с эффектом и рисками».

D-E-E-P — когда ИИ должен сначала уточнить задачу. D (Domain) — область; E (Experience) — уровень пользователя или адресата; E (Expectations) — желаемый тип и глубина результата; P (Priorities) — приоритет (скорость, качество, цена, простота, снижение риска). Пример: «Область: внедрение ИИ в техподдержке. Уровень: руководитель функции, не технический специалист. Хочу получить варианты архитектуры и план пилота. Приоритет: быстрое внедрение без сложной разработки».

B-R-I-E-F — универсальный корпоративный шаблон. B (Background) — фон и бизнес-контекст; R (Requirements) — требования и запреты; I (Inputs) — доступные материалы; E (Examples) — примеры желательного и нежелательного; F (Format) — конечный вид результата. Пример: «Фон: записка директору по операциям о применении ИИ в логистике. Требования: практично, без маркетинговых обещаний, с учётом ограничений по данным. Входные данные: процессы, показатели SLA, перечень ИТ-систем. Примеры: за образец — прошлогодняя записка по пилоту на складе; чего не надо — презентация вендора. Формат: 1 страница, затем таблица из 5 сценариев с эффектом, рисками и сложностью внедрения».