Когда вы переходите от “написать текст” к “разобраться в тексте”, модель становится уже не копирайтером, а аналитиком. Здесь от промта зависит, увидит ли она паттерны, которые вам важны, или утонет в пересказах. В аналитике ваша задача – превратить сырые данные (отзывы, транскрипты, открытые ответы в опросах) в структурированную картину: темы, боли, идеи улучшений. Без кода это делается через продуманные текстовые промты, с кодом – через связку с Python/SQL и жёстко заданные форматы ответов.

Начнём с работы “без кода”, когда у вас есть только вы, модель и массив текстов. Типичный исходник – 20–50 отзывов о продукте, сервисе, курсе. Если просто попросить “проанализируй отзывы и сделай выводы”, вы получите общие слова: “клиенты довольны качеством, но есть проблемы с поддержкой и ценой”. Это мало полезно. Настоящая ценность – в структурировании: сгруппировать отзывы по темам, вытащить повторяющиеся боли, увидеть слова и формулировки, которые клиенты используют сами, и переводить их в понятные предложения по улучшению продукта.

Подход к промтам здесь должен быть многоступенчатым. Вы не просите модель “сделать всё сразу”, а ведёте её по шагам: сначала группировка по темам, потом извлечение болей, потом генерация инсайтов и предложений. По сути, вы строите аналитический пайплайн поверх LLM.

Для анализа текстовых данных удобнее всего использовать несколько типов промтов.

Первый тип – промт для группировки/кластеризации. Вы даёте набор отзывов и просите модель:

выделить основные темы, вокруг которых крутятся комментарии;

отнести каждый отзыв к одной или нескольким темам;

дать этим темам ясные, человекопонятные названия.

Важно явно задать ограничения: разумное количество тем (например, 5–10), отсутствие пересекающихся дубликатов, требование, чтобы названия были короткими и говорящими (“скорость поддержки”, “удобство интерфейса”, “стабильность работы”, а не “разные проблемы, связанные с тем, что пользователи иногда недовольны тем или иным аспектом сервиса”). Вы как бы просите модель “сфасетировать” хаос на несколько стабильных категорий.

Второй тип – промт для поиска болей и паттернов. Здесь вы просите модель, уже опираясь на темы, выписать типичные боли: что именно людей раздражает, пугает, тормозит; какие негативные сценарии повторяются. Важно, чтобы модель не просто говорила “есть жалобы на поддержку”, а приводила типовые формулировки и примеры из отзывов: “поддержка отвечает долго, приходится ждать больше суток”, “приходится общаться с ботом, живого человека не дождаться”. Это даёт вам не только аналитическую выжимку, но и язык, которым сами пользователи описывают проблему.

Третий тип – промт для генерации инсайтов и предложений по улучшению продукта. На этом шаге вы просите модель перевести боли и темы в управляемые гипотезы: что можно изменить в продукте, процессе, коммуникации, чтобы эти боли уменьшить. Здесь важно указать, что вам нужны конкретные, реализуемые шаги, а не общие рекомендации вроде “улучшить сервис”. Сильный приём – привязать предложения к каждой теме и ранжировать их по ожидаемому влиянию на удовлетворённость клиента.

Чтобы вся эта аналитика была не “разовым озарением”, а воспроизводимым процессом, вам нужны структурированные ответы. Структурирование – это ваша защита от размытых рассуждений. Когда вы просите “ответь в виде JSON по такой‑то схеме” или “сделай Markdown‑таблицу с такими‑то колонками”, вы задаёте модели чёткую форму. Это особенно важно, если вы планируете дальше подхватывать результат кодом (Python, SQL) или использовать в BI‑инструментах.

Например, для кластеризации отзывов вы можете задать JSON‑схему с полями: id_отзыва, текст, тема, под‑тема, список_болей. Модель будет вынуждена укладывать данные в эти ячейки. Да, она не идеальный парсер, и будут ошибки, но зато вы сможете автоматически обрабатывать и агрегировать результаты.

Markdown‑таблицы полезны, если вы работаете глазами. Вы просите модель сделать таблицу:

| id | Тема | Краткое описание боли | Цитата из отзыва | Предложение по улучшению |

Так вы сразу видите, где накопление жалоб, где у вас “провал” в продукте. Табличный формат дисциплинирует модель: вместо того чтобы размазывать текст по абзацам, она должна чётко ответить по колонкам.

Когда вы подключаете Python или SQL, всё это превращается в ещё более мощный инструмент. Сценарий такой: вы выгружаете из базы данных отзывы, подаёте их батчами в модель с требованием структурированного JSON, затем парсите этот JSON в DataFrame и дальше работаете: считаете частоты, строите дашборды, проверяете гипотезы. SQL остаётся основным способом выбирать данные: по периоду, по продукту, по сегменту клиентов. LLM‑слой – это семантическая “надстройка”: выделить тему, тон, боль, предложение, уровень критичности.

Например, вы можете:

через SQL выбрать все отзывы за последний месяц по конкретному тарифу;

через LLM разметить каждый отзыв по теме, тональности и наличию ключевых болей;

через Python посчитать, какие темы стали появляться чаще, какие боли растут, а какие уменьшаются после релиза;

автоматически сформировать отчёт по одному шаблону.

Ключевой момент: для связки с кодом вы обязаны сделать ответы модели максимально предсказуемыми по структуре. Никаких “иногда JSON, иногда комментарии”, никаких лишних фраз до или после JSON. В промтах вы прямо прописываете: “выведите ТОЛЬКО JSON, без пояснений, без текста до и после”. И тестируете, пока не добьётесь стабильности.

Перейдём к практической задаче: взять 20–50 отзывов и через модель пройти полный цикл: сгруппировать по темам, вытащить частые боли, сформулировать предложения по улучшению продукта.

Сначала вы собираете эти отзывы в удобном формате: нумерованный список или массив. Вы даёте модели ясную инструкцию: “вот список отзывов, каждый имеет свой id. На этом шаге вам нужно: выделить 5–10 тем, дать им названия и для каждой темы показать, какие id к ней относятся и почему”. Вы ожидаете в ответе либо таблицу, либо JSON с массивом тем, внутри которых массив id_отзывов и краткое описание.

После того как темы определены, вы используете новый промт, уже с опорой на эти темы. Просите: “для каждой темы выпишите типичные боли, которые повторяются в отзывах, используйте формулировки, максимально близкие к тексту отзывов, и приведите 1–2 характерные цитаты”. Это важно: вы не придумываете боли “с потолка”, а вытаскиваете их из реальных фраз клиентов. Модель хорошо умеет обобщать и переформулировать, главное – заставить её показать вам исходник.

Затем вы берёте список тем и болей и просите модель сформировать предложения по улучшению продукта. Задача: для каждой темы предложить 2–3 конкретных действия: что поменять, добавить, убрать, что изменить в UX, коммуникации, поддержке. Полезно сразу требовать привязку к усилиям и ожидаемому эффекту: “малое усилие – большой эффект”, “значительное усилие – высокий потенциал”. Вы можете получить грубый приоритезационный план, который потом обработаете сами.

Теперь самое важное для воспроизводимости: вы заставляете модель выдавать отчёт в фиксированной JSON‑схеме. Это делает всю процедуру автоматизируемой. Вы описываете схему в промте примерно так:

корневой объект – массив “topics”;

у каждой темы поля:

topic_id (int), topic_name (string), description (string), review_ids (array of int), pains (array of objects с полями pain_description и example_review_ids), improvements (array of objects с полями idea и expected_impact).

Вы просите модель строго следовать этой схеме, без дополнительных полей, без текста вне JSON. Сначала вы тестируете это на одном наборе отзывов, смотрите, где она ломает структуру: пропускает поля, добавляет комментарии, и уточняете инструкцию (“не добавляйте новые поля”, “не используйте комментарии в стиле //”).

Когда формат стабилен, вы повторяете то же самое на новом наборе отзывов. Цель – проверить, насколько одни и те же промты и схема выдерживают другую выборку. Если на новом наборе модель продолжает уверенно выдавать JSON по схеме, вы можете дальше подключать Python/SQL и строить полноценный аналитический конвейер.

Хороший результат этого упражнения – не только готовый отчёт по отзывам, но и набор отлаженных промтов:

для кластеризации отзывов по темам;

для извлечения болей и цитат;

для генерации предложений по улучшению;

для выдачи всего этого в строго определённой структуре (JSON, таблица).

Работая так, вы переводите LLM в режим “полезный аналитический инструмент”, который даёт вам структурированные данные, готовые к дальнейшему анализу. И тогда ваши решения по продукту опираются уже не на ощущение, а на систематизированный голос клиентов, который вы научились извлекать через промты.