Тендеры и лиды
Информация
Со стороны продукт для создания персональных детских книг выглядит почти слишком просто. Пользователь загружает фотографию ребёнка, указывает имя и интересы, выбирает тему — и через некоторое время получает сказку с иллюстрациями. Кажется, что внутри должна находиться примерно такая конструкция: анкета → большой промпт → текст → картинки → PDF.
На уровне демо этого действительно может быть достаточно. Но между красивым AI-демо и продуктом, за который человек готов платить, довольно быстро появляется целый дополнительный слой: драматургия, состояние персонажей, контроль визуальной консистентности, возрастные правила, безопасность, сборка книги, повторяемость результата и уже потом — интерфейс чтения, печать и дополнительные форматы.
Мы довольно хорошо почувствовали эту разницу, когда начали развивать Luseri. Чем дальше двигался продукт, тем меньше задача была похожа на «написать хороший промпт».
Современная генеративная модель вполне способна написать детскую сказку по запросу вроде: «Девочка Маша, 6 лет, любит космос и собак. Напиши приключение на 20 страниц, где она становится главным героем». Отдельно генератор изображений способен нарисовать Машу в космическом корабле. Если задача — показать концепцию инвестору или собрать первый прототип, этого хватает.
Но попробуем сделать из такого результата книгу. На пятой иллюстрации у Маши меняется причёска. На восьмой её собака внезапно становится другой породы. На двенадцатой появляется новый персонаж, о котором история потом забывает. В середине сюжета герой перестаёт принимать решения, потому что всё делает волшебный помощник. А финал заканчивается абзацем: «Так Маша поняла, что важно всегда верить в себя и помогать друзьям». Формально всё сгенерировано. Продуктом это пока назвать трудно.
Первое, что хочется сделать в генеративном продукте, — дать пользователю большое поле: «Расскажите всё, что хотите видеть в истории». Для UX это выглядит удобно. Для производственного пайплайна — гораздо хуже. Одно такое описание может содержать имя ребёнка, внешность, любимую игрушку, сюжетное пожелание, запрет, обращение к модели и случайный кусок текста, который вообще не относится к книге.
Поэтому довольно быстро свободное описание приходится раскладывать на сущности: имя, возраст, пол, интересы, особенности героя, спутник, тема приключения, визуальный стиль, нежелательные элементы. Свободный текст всё ещё может оставаться — именно он часто содержит самые живые детали, — но он перестаёт быть единственным контрактом системы. На этом этапе AI-продукт уже начинает больше напоминать обычный software product: появляется схема данных, валидация и понимание того, какие параметры на что действительно влияют.
Особенно хорошо ограничения генерации становятся заметны на возрасте. Самая очевидная реализация выглядит так: ребёнку 4 года → короткие предложения, ребёнку 9 лет → предложения подлиннее. Но драматургически это почти ничего не решает.
История для ребёнка 3–5 лет может строиться вокруг одной ясной цели, короткой причинно-следственной цепочки и небольшого числа действующих персонажей. В 6–7 лет уже нормально появляется небольшая загадка, первая неидеальная попытка и понятный сюжетный поворот. В 8–10 лет можно использовать несколько связанных наблюдений, ложную догадку и более длинную цепочку причин и последствий. То есть возраст начинает влиять не только на лексику, а на архитектуру истории.
Мы в итоге разделили её на три редакционных профиля — 3–5, 6–7 и 8–10 лет. Это хороший пример того, почему одного системного промпта постепенно перестаёт хватать. Вместо просьбы «пиши с учётом возраста» появляется конкретный контракт: какой уровень сложности допустим, сколько значимых персонажей использовать, какой объём текста держать на развороте и насколько сложной может быть кульминация. Мы отдельно разбирали эту механику в материале о том, как возраст ребёнка влияет на драматургию персональной сказки.
У длинной генерации есть ещё одна проблема. Модель хорошо пишет отдельную сцену. Но книга — это не набор отдельных хороших сцен. Если история состоит из 23 разворотов, между ними должны сохраняться цель героя, найденные предметы, отношения персонажей, логика мира, предыдущие открытия, эмоциональное состояние, причинно-следственная связь.
Можно просто попросить модель «следить за непрерывностью сюжета» — результат иногда будет хорошим, иногда нет. Для повторяемого продукта этого недостаточно. Поэтому появляется слой, который условно можно назвать Story Bible: набор обязательных сюжетных опор, правил мира и ролей персонажей.
При этом здесь легко впасть в другую крайность. Если описать событие каждого разворота заранее, модель перестаёт писать историю и начинает заполнять таблицу. Поэтому полезнее фиксировать только крупные опоры — завязка, первое осложнение, открытие, изменение подхода, кульминация, завершение, — а пространство между ними оставлять генеративной модели. В итоге правила задают форму, но не пишут текст вместо автора.
Для персонального продукта это особенно важно. Очень легко сделать книгу, в которой ребёнок визуально находится в центре каждой иллюстрации, но драматургически не делает практически ничего. Появляется мудрый дракон. Дракон объясняет задачу. Дракон находит подсказку. Дракон сообщает правильный ответ. Ребёнок кивает. Формально это книга про ребёнка. Фактически — история про дракона.
Поэтому агентность героя тоже приходится превращать в правило системы: помощник может подсказать, обратить внимание или задать вопрос, но ключевое решение принимает ребёнок. Это уже не prompt engineering в привычном смысле — это продуктовая политика.
Текст ещё относительно легко проверить глазами. С изображениями проблема проявляется моментально: если главный герой на обложке выглядит одним образом, а на третьем развороте другим, пользователь это замечает сразу.
Поэтому первая важная сущность — master reference героя. Сначала создаётся утверждённый образ ребёнка, и дальше именно он используется как канонический визуальный источник для всех сцен. Это лучше, чем строить последовательную цепочку, где сцена 1 становится референсом для сцены 2, та — для сцены 3 и так далее: при такой схеме ошибки накапливаются. Если во второй сцене немного изменился цвет волос, третья уже наследует изменённый вариант, и через десять итераций от первоначального персонажа может остаться довольно мало. Канонический reference разрывает эту цепочку — каждая сцена снова сверяется с одним исходным образом, а не с предыдущей картинкой.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Как только проблему главного героя удаётся стабилизировать, обнаруживается следующая. Допустим, у ребёнка есть любимая плюшевая игрушка — маленький трицератопс Клёпа, который появляется на 12 разворотах. Если каждый раз просто писать «рядом находится плюшевый трицератопс Клёпа», генератор вполне может нарисовать 12 разных Клёп: где-то он зелёный, где-то синий, в одной сцене у него большие круглые глаза, в другой — маленькие.
Поэтому повторяющихся второстепенных персонажей приходится канонизировать примерно так же, как героя. Система сначала определяет, какие персонажи действительно должны сохранять визуальную идентичность, а затем для каждого фиксируются несколько устойчивых признаков — например: ожившая плюшевая игрушка-трицератопс, мятно-зелёная ткань, два коротких кремовых рога, фиолетовый шарф. После этого создаётся отдельный reference, и на конкретный разворот передаются только те персонажи, которые действительно присутствуют в этой сцене. Получается довольно важный принцип: reference должен принадлежать персонажу, а не предыдущей картинке.
Для детского продукта естественно появляется довольно большой набор ограничений: никакого тяжёлого насилия, никакого хоррора, никаких унижений, никаких ситуаций, где ребёнок оказывается беспомощным и забытым. Но здесь возникает неожиданная проблема. Если просто добавить все эти инструкции в генерацию, модель может начать переносить их прямо в литературу — например, писать что-то вроде «Есения подошла к двери. Она была совершенно безопасной и ничем ей не угрожала». Технически модель прекрасно выполнила правило. Литературно фраза ужасная.
Поэтому одно из полезных правил, к которому мы пришли, звучит примерно так: safety определяет допустимые события, но само по себе не является содержанием сказки. Не нужно сообщать читателю, что мост безопасен, — нужно просто не делать мост опасным. На мой взгляд, это вообще довольно универсальный принцип для генеративных продуктов: внутренние ограничения системы не должны просачиваться в пользовательский контент.
Ещё одна ловушка — формально правильный текст. Модель может написать грамматически допустимое предложение, которое человек в детской книге почти никогда не написал бы. Особенно легко появляются синтетические «красивости» вроде «Луна рассыпала жемчужные ступеньки своего сияния». Одна такая фраза допустима. Когда такими предложениями написано 23 разворота подряд, чтение превращается в соревнование метафор.
Поэтому для production-генерации приходится отдельно фиксировать языковой стандарт: современный естественный русский, текст должен хорошо читаться вслух, конкретная лексика, минимум абстрактных объяснений, эмоции лучше показывать действиями, уже понятное не нужно повторно разжёвывать. И снова это выглядит скорее как работа редактора, чем как настройка температуры модели.
Предположим, всё получилось: есть хороший текст, есть 23 качественные иллюстрации, герой выглядит стабильно, история закончена. Но пользователь покупал не JSON и не директорию с изображениями — дальше начинается уже совершенно обычная продуктовая инфраструктура.
Нужно собрать книгу. У нас одна canonical-редакция становится источником сразу для нескольких представлений: web-reader, где книга читается прямо в браузере — на desktop это книжный разворот, на телефоне композиция перестраивается под небольшой экран; PDF как отдельная цифровая версия, которую можно скачать; печатная книга, для которой тот же контент нужно привести к требованиям физического производства; и дополнительные assets — например, из уже созданного визуального мира можно сделать персональную раскраску по мотивам книги. То есть генеративный pipeline заканчивается заметно раньше самого продукта.
На раннем этапе очень хочется сделать PDF главным артефактом системы: сгенерировали книгу → собрали PDF → дальше показываем его везде. Но со временем это становится неудобно. Для web-reader лучше иметь отдельно текст и иллюстрацию. Для мобильного интерфейса нужен другой layout. Для повторной печати важно точно знать редакцию. Для нового производного asset вроде раскраски нужны исходные сцены, а не растрированный PDF.
Поэтому полезнее иметь canonical book, а PDF рассматривать только как одно из её представлений. Это довольно стандартная software-идея, но в AI-продуктах о ней легко забыть, потому что генерация очень быстро производит красивый конечный файл.
Есть популярное выражение — «обёртка над моделью». В ранней версии почти любой AI-сервис в каком-то смысле такой и есть: есть интерфейс, есть API модели, есть prompt, есть результат. Но по мере развития успешного продукта ценность постепенно смещается. Сама модель продолжает делать тяжёлую интеллектуальную работу, но вокруг неё появляется система — структурированные данные, правила, состояние, canonical entities, валидация, повторяемость, fallback-механики, UX, production pipeline, аналитика, права доступа, дополнительные представления результата. И в какой-то момент заменить модель внутри такого продукта оказывается значительно проще, чем заменить всё, что было построено вокруг неё.
Сегодня качество foundation-моделей меняется очень быстро: модель, которая была лучшей полгода назад, завтра может уступить новой. Поэтому довольно рискованно строить продуктовую ценность вокруг утверждения «мы используем самую умную нейросеть». Гораздо устойчивее становится другой слой — насколько хорошо система превращает вероятностный генеративный результат в предсказуемый пользовательский опыт.
В случае персональной книги это означает: ребёнок действительно остаётся собой, история соответствует возрасту, персонажи не меняются между страницами, сюжет не разваливается, готовую книгу удобно читать, её можно напечатать, а через месяц она всё ещё существует как нормальный объект внутри продукта, а не как когда-то созданный файл.
И, скорее всего, этот принцип применим далеко не только к книгам. По мере взросления генеративных сервисов самое интересное будет происходить не внутри одного гигантского промпта. А вокруг него.
