Нейросеть: от чего зависит результат работы генеративного ИИ
Разбираю, от чего зависит результат работы генеративной нейросети: задача, исходные данные, контекст, формат, выбор модели и проверка на примере анонса.
Д
Денис
Продакт LibraChat
8 мин чтения
На листке передо мной две просьбы к чату. Первая: «Напиши анонс встречи». Вторая: «Напиши короткий анонс открытой встречи библиотеки для родителей: в субботу в 12:00 разбираем семейные фотографии; вход свободный, мест 20; цель — чтобы человек понял, стоит ли ему прийти; не обещай оцифровку на месте». В первой просьбе я сам оставил модели всю работу по догадкам: для кого встреча, когда она будет, что там произойдёт. Во второй уже есть границы решения. Если их не дать, гладкий анонс может оказаться анонсом несуществующего события.
В технической статье о ключевых элементах работы нейросетей я разбирал данные, обучение модели и проверку на новых примерах. Здесь вопрос другой. Нас интересует один конкретный ответ уже готового чата: почему он подходит задаче или требует правки? Для ответа я разберу карточку библиотечной встречи от исходных сведений до финальной проверки.
Сначала определите, что считать удачным результатом
У задачи есть два выхода, которые легко спутать. Первый — текст звучит гладко. Второй — читатель анонса получает верные сведения и понимает, зачем приходить. Я бы выбрал второй критерий до отправки запроса. Иначе после ответа легко назвать удачным самый красивый вариант, даже если он придумал лектора, запись или услугу, которых в условии нет.
Для карточки встречи я записал пять проверяемых требований:
Есть аудитория: родители, которые хотят разобраться с семейными фотографиями.
Верно переданы время, бесплатный вход и ограничение по местам.
Не добавлены услуги, которых библиотека не обещала.
Текст короткий, чтобы уместиться в объявлении.
Есть понятный следующий шаг для читателя, но его детали берутся только из подтверждённого источника.
Последний пункт может выявить пробел ещё до генерации. В исходной карточке нет адреса библиотеки и способа записи. Значит, честный ответ не должен сам их сочинять. Я добавил бы к запросу: «Если для анонса не хватает адреса или порядка записи, укажи это отдельно, не заполняй догадкой». Такое уточнение полезнее просьбы «сделай текст убедительным».
Google Cloud в руководстве по проектированию запросов называет цель, контекст, ограничения, формат и примеры компонентами, которые могут менять ответ. Там же важна проверка противоречий: если в инструкции написано «не больше 80 слов», а пример на две страницы, модель получит конфликтующие ориентиры. Я не переношу эти рекомендации как гарантию качества для каждой модели. Они дают способ подготовить вход и проверить выход.
Что именно получает нейросеть на входе?
У второго запроса больше слов, но дело не в длине. В нём есть сведения, которых нельзя вывести из общей фразы «анонс встречи»: для кого событие, что произойдёт, какие ограничения существуют и чего не обещают. Десять лишних прилагательных не заменят один точный факт. Иногда короткая карточка с подтверждёнными данными работает лучше длинной просьбы с противоречивыми пожеланиями.
Я разделяю вход на три части:
Часть запроса · Пример для встречи · Что ломается, если её нет
Задача — «Напиши анонс, по которому родитель решит, приходить ли» — Получается общий рекламный текст без решения читателя
Исходные сведения — Время, тема, свободный вход, число мест — Чат может добавить или спутать факты
Граница — Не обещать оцифровку; неизвестное пометить — Гладкая догадка выглядит как официальное обещание
Контекст — не вся история проекта. Для короткого анонса не нужен внутренний архив переписки команды. Нужны сведения, которые влияют на текст. Если материала много, я бы приложил аккуратный документ или вставил отрывок с пометкой, какие данные уже подтверждены. В LibraChat можно прикрепить текстовые документы и задать вопросы по ним, но это не освобождает от проверки: модель может ошибиться и при пересказе файла.
Есть ещё контекст разговора. В пределах одного чата LibraChat помнит предыдущие сообщения, поэтому просьба «сократи второй абзац» относится к уже обсуждаемому варианту. Но если в чате до этого десять раз менялись время и условия, я бы повторил актуальную карточку целиком. Так проще самому заметить противоречие. Не стоит ждать, что чат угадает, какой из старых вариантов окончательный.
Как выбрать формат и пример, не превращая запрос в инструкцию на страницу
Формат ответа помогает принять или отклонить результат. Для библиотечного анонса я попросил бы: заголовок до семи слов, основной текст до 80 слов, затем отдельная строка «нехватающие сведения». Это редакторские пределы моего примера, а не лимиты продукта. При таком формате сразу видно, придумал ли чат адрес, забыл ли вместимость и прячет ли неопределённость внутри красивого абзаца.
Если у библиотеки уже есть удачный прошлый анонс, можно дать его как образец интонации. Но сначала проверить: не содержатся ли в нём старые дата, место и условия. Иначе модель может перенести их в новый текст. Пример учит форме, а не подтверждает факты нового события. Это важная граница, которую в спешке забывают даже опытные редакторы.
Google в руководствах для разработчиков описывает ясные инструкции и примеры как способы направить форму ответа. Там же подчёркивается итеративная проверка. Поэтому я бы не искал «идеальный промпт навсегда». Я сравнил бы полученный черновик с заранее записанными пятью требованиями и изменил только то место запроса, где обнаружился пробел. Если ответ слишком длинный, уточнить формат. Если он додумал адрес, усилить правило о нехватающих данных. Если неверно понял аудиторию, поставить её в начало.
Не каждую ошибку надо лечить новым промптом. Если исходная карточка сама неверна, аккуратно сформулированная инструкция лишь воспроизведёт её ошибку. Если встреча перенесена, нужно обновить сведения у организатора. Если адреса нет, спросить библиотеку. Генеративная модель может помочь написать текст на основе данных, но не превращает непроверенные данные в правду.
Влияет ли выбранная модель на ответ?
Да, разные модели и режимы могут по-разному справляться с одной задачей. В LibraChat модель выбирается в строке ввода, а доступный список со временем меняется. Поэтому я не составляю здесь рейтинг «самой точной» модели для анонсов. Лучше проверять конкретный результат по одной карточке, особенно если цена ошибки высока. Для короткого текста достаточно сравнить, сохранил ли ответ факты и выполнил ли ограничения.
У модели есть возможности и пределы, которые один запрос не отменит. Она может написать связный текст с неверной деталью, смешать старую дату из образца с новой или пропустить запрет в длинном списке. В справке LibraChat прямо сказано, что ответы бывают неточными. Задача пользователя — строить проверку вокруг существенных фактов. В нашем примере это время, число мест, доступность входа и отсутствие обещанной оцифровки.
Я бы не считал один удачный ответ доказательством, что тот же запрос всегда сработает. Изменится тема, модель или входной документ — проверку придётся повторить. Особенно если текст предназначен для других людей. Проверяйте не впечатление «читалось приятно», а содержание каждого обещания.
Что делать после первого черновика
Представим, что анонс готов. До публикации я бы прошёл по нему карандашом и поставил рядом с каждым фактом пометку: «есть в исходной карточке» или «нужно спросить». Если появилась фраза «запись обязательна», а в карточке этого нет, фраза уходит. Если нет адреса, его нельзя заменить выдумкой модели; редактор спрашивает организатора. Так проверка результата становится частью задачи, а не завершающим пожеланием «ну, перепроверьте».
Для собственных задач можно использовать такую короткую последовательность:
Записать цель ответа одной строкой: какое решение примет его читатель или пользователь?
Дать только подтверждённые исходные сведения и отметить неизвестное.
Назвать формат результата и один-два запрета, которые действительно важны.
Сверить ответ с исходником, затем уточнить запрос в месте обнаруженной ошибки.
В LibraChat это можно сделать обычным диалогом: открыть чат, отправить карточку и следующим сообщением попросить правку конкретной строки. Перед началом работы проверьте текущие условия использования на странице тарифов LibraChat.
Попробуй прямо сейчас взять один свой недавний запрос, на который пришёл неудачный ответ. Выпиши рядом три вещи: что ты хотел получить, какие факты дал модели и по каким признакам проверял бы ответ. Затем открой чат и уточни только недостающую часть. Если ошибка была в исходном факте, сначала исправь его у первоисточника. В этом и заключается практический ответ: результат зависит от постановки задачи, качества сведений, подходящего инструмента и человека, который проверяет готовый текст.
