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

Почему одним промптом миллионы записей не нормализовать

Коротко: один промпт смешивает исследование данных, создание правил, исправление значений и проверку результата. Ошибка на любом этапе незаметно переезжает во все следующие.

Задача кажется простой: убрать разный регистр, исправить сокращения, привести единицы измерения и объединить дубли. Но внутри неё скрыты разные решения:

Универсальный промпт не знает цену конкретной ошибки. Для него неверно объединённые позиции и лишний пробел отличаются только текстом. Для владельца базы последствия могут быть совершенно разными.

В своих разработках я использую тот же принцип, что и в НЕВОДе (мой контент-завод: из одной темы пишет статью и посты под каждую площадку и публикует после моей кнопки): модель создаёт кандидат, а переход к следующему состоянию контролирует код. Правило, которое существует только в промпте, остаётся просьбой.

Шаг 0. Зафиксировать, что модели запрещено менять

Коротко: до первого запуска нужен контракт данных. Без него нельзя отличить полезную нормализацию от повреждения исходника.

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

Ты проектируешь безопасную нормализацию номенклатуры.

Контекст:
- тип данных: [ЧТО ХРАНИТСЯ В БАЗЕ]
- объём: [КОЛИЧЕСТВО ЗАПИСЕЙ ИЛИ ДИАПАЗОН]
- поля одной записи: [СПИСОК ПОЛЕЙ]
- обязательные поля: [СПИСОК]
- поля, которые запрещено менять: [СПИСОК]
- допустимые преобразования: [СПИСОК]
- недопустимые последствия ошибки: [СПИСОК]
- примеры исходных записей: [ПРИМЕРЫ]
- примеры ожидаемого результата: [ПРИМЕРЫ]

Составь контракт нормализации.

Для каждого поля укажи:
1. можно ли его менять;
2. какие преобразования допустимы;
3. какие преобразования запрещены;
4. какие проверки выполняются до изменения;
5. какие проверки выполняются после изменения;
6. при каком условии запись отправляется на ручную проверку;
7. какие исходные данные нужно сохранить для отката.

Не придумывай значения, справочники и бизнес-правила, которых нет во входных данных.
Если правила не хватает, пометь его как НЕИЗВЕСТНО и сформулируй один вопрос владельцу.
Не предлагай обработку всей базы.

Выведи результат таблицей:
ПОЛЕ | МОЖНО МЕНЯТЬ | ДОПУСТИМО | ЗАПРЕЩЕНО | ПРОВЕРКА ДО | ПРОВЕРКА ПОСЛЕ | УСЛОВИЕ РУЧНОЙ ПРОВЕРКИ | ДАННЫЕ ДЛЯ ОТКАТА.

После таблицы выведи список блокирующих неизвестных.

Что даёт: границу полномочий модели и перечень неизвестного до запуска.

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

Шаг 1. Отделить правила кода от смысловых решений

Коротко: регистр, пробелы и известные словари должен обрабатывать код. Модель нужна только там, где решение зависит от смысла.

Следующий промпт раскладывает будущий конвейер по исполнителям.

Перед тобой контракт нормализации и примеры данных.

Контракт:
[ВСТАВИТЬ УТВЕРЖДЁННЫЙ КОНТРАКТ]

Примеры:
[ВСТАВИТЬ РЕАЛЬНЫЕ ПРИМЕРЫ]

Раздели преобразования на четыре группы.

Группа А. Детерминированные:
результат однозначно вычисляется кодом, регулярным выражением, словарём или таблицей соответствий.

Группа Б. Справочные:
результат разрешён только при точном совпадении с утверждённым справочником.

Группа В. Смысловые:
нужно понять значение текста, но результат можно проверить ограниченным набором условий.

Группа Г. Неразрешимые автоматически:
не хватает данных, есть несколько допустимых вариантов или цена ошибки требует решения человека.

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

Не переноси задачу в группу модели только потому, что правило сложно сформулировать.
Если результат можно получить однозначным алгоритмом, назначь код.
Модель не имеет права изменять запись напрямую. Она возвращает только предложение, причину и уровень уверенности.
Выведи результат таблицей.

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

Где ломается: модель может назвать смысловой задачей то, что решается обычным словарём. Поэтому каждое назначение модели нужно проверить вопросом: может ли один и тот же вход законно получить разные выходы?

Этот принцип я применяю и при проверке новинок на своих задачах. Описание модели или инструмента показывает заявленные возможности, но решение о внедрении принимается только после собственного прогона. Подробно этот подход разобран в материале о проверке новинок.

Шаг 2. Собрать правила на выборке, не трогая базу

Коротко: правила сначала строятся на копии выборки. Исходные записи остаются неизменными, а каждое предложение получает объяснение.

Ты анализируешь выборку номенклатуры для подготовки правил нормализации.

Контракт:
[ВСТАВИТЬ КОНТРАКТ]

Разделение задач:
[ВСТАВИТЬ ТАБЛИЦУ ИСПОЛНИТЕЛЕЙ]

Выборка:
[ВСТАВИТЬ ВЫБОРКУ С УСТОЙЧИВЫМИ ИДЕНТИФИКАТОРАМИ]

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

Ограничения:
- не объединяй записи;
- не удаляй значения;
- не исправляй поля вне контракта;
- не подставляй неизвестные характеристики;
- не считай похожее написание доказательством тождества;
- при нескольких допустимых вариантах выбирай отправку человеку;
- сохраняй исходный идентификатор и исходное значение дословно.

После записей выведи:
1. повторяющиеся правила, которые можно перенести в код;
2. неоднозначные классы;
3. неизвестные значения;
4. предполагаемые дубли без решения об объединении.

Что даёт: материал для правил без необратимого воздействия на данные.

Где ломается: однородная выборка скрывает редкие форматы и исключения. Нужны разные источники, пустые поля, длинные значения, редкие категории и записи с конфликтами.

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

Шаг 3. Превратить предложения в исполнимую спецификацию

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

Преобразуй подтверждённые правила нормализации в техническую спецификацию.

Входные материалы:
- контракт: [КОНТРАКТ]
- подтверждённые правила: [ПРАВИЛА]
- отклонённые предложения: [ОТКЛОНЁННЫЕ ПРЕДЛОЖЕНИЯ]
- примеры до и после: [ПРИМЕРЫ]

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

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

Формат результата для каждого правила:
ИМЯ
ВЕРСИЯ
ВХОДНОЕ УСЛОВИЕ
ПРЕОБРАЗОВАНИЕ
РАЗРЕШЁННЫЕ ПОЛЯ
ПРЕДУСЛОВИЯ
ПОСТУСЛОВИЯ
НЕГАТИВНЫЕ ПРИМЕРЫ
ДЕЙСТВИЕ ПРИ ОТКАЗЕ
ЖУРНАЛ
ОТКАТ
ПРИЁМОЧНЫЕ ПРИМЕРЫ

Что даёт: промежуточный контракт между исследованием и реализацией.

Где ломается: два по отдельности правильных правила могут конфликтовать при последовательном применении. Поэтому порядок выполнения и повторный прогон одной записи проверяются отдельно.

Шаг 4. Спроектировать пилот и раннюю остановку

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

Спроектируй пилотный прогон нормализации.

Дано:
- контракт данных: [КОНТРАКТ]
- технические правила: [СПЕЦИФИКАЦИЯ]
- структура базы: [ПОЛЯ И ТИПЫ]
- доступные категории записей: [КАТЕГОРИИ]
- критические ошибки: [СПИСОК]
- допустимые действия при ошибке: [ОСТАНОВИТЬ ПАЧКУ, ПРОПУСТИТЬ ЗАПИСЬ, ОТПРАВИТЬ ЧЕЛОВЕКУ]

Составь план пилота, включающий:
1. состав выборки;
2. обязательные крайние случаи;
3. размер одной пачки как настраиваемый параметр [РАЗМЕР ПАЧКИ];
4. проверки до записи;
5. проверки после записи;
6. инварианты, нарушение которых останавливает прогон;
7. правила перехода к следующей пачке;
8. журнал изменений;
9. отчёт о пропусках и отказах;
10. процедуру отката пилота;
11. условия, при которых масштабирование запрещено.

Не выбирай числовые пороги без входных данных.
Не считай отсутствие технической ошибки доказательством качества нормализации.
Каждый критерий сформулируй как проверяемое логическое условие.
Отдельно перечисли проверки, которые нельзя автоматизировать по имеющимся данным.

Что даёт: управляемый эксперимент вместо запуска на всей базе.

Где ломается: зелёный статус процесса легко принять за правильный результат. Сервер мог обработать все записи без падения и при этом аккуратно сохранить неверные значения.

Как сцепить промпты в один конвейер

Коротко: выход каждого шага становится входом следующего только после проверки. Неизвестное и неоднозначное не должны путешествовать дальше как утверждённые правила.

Рабочая цепочка выглядит так:

  1. Контракт фиксирует границы.
  2. Классификатор выбирает исполнителя.
  3. Анализ выборки предлагает правила.
  4. Спецификация переводит подтверждённое в проверяемую форму.
  5. План пилота задаёт остановку, журнал и откат.
  6. Код исполняет только утверждённые детерминированные правила.
  7. Модель возвращает предложения для ограниченного класса записей.
  8. Проверяющий слой принимает, отклоняет или отправляет запись человеку.

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

Так я удерживаю ИИ-джинна в лампе. Он видит только нужный фрагмент данных, возвращает ответ по строгому формату и не получает права самостоятельно переписывать источник истины.

Похожая логика действует в Джарвисе (главный агент-оркестратор: живёт на сервере, управляется из Telegram и руководит остальными моими системами). Модель помогает разобрать задачу, а внешние действия требуют отдельного разрешения. Чем дороже ошибка, тем меньше итоговых решений остаётся за моделью.

Что подставлять в квадратные скобки

Коротко: качество цепочки зависит от конкретных ограничений базы. Название отрасли не заменяет примеры, запрещённые изменения и критерии отказа.

Минимальный комплект входных данных:

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

Если справочника нет, его отсутствие тоже является входным фактом. Модель не должна собирать его из собственных догадок.

Где нормализация ломается чаще всего

Коротко: самые дорогие ошибки выглядят правдоподобно. Они проходят синтаксическую проверку и обнаруживаются только после сравнения смысла и бизнес-инвариантов.

Первое место - ложные дубли. Похожие названия могут относиться к разным позициям. Коэффициент похожести помогает найти кандидатов, но сам по себе не разрешает объединение.

Второе - потеря исходника. Если система хранит только исправленное значение, спорную замену уже не с чем сравнивать. Исходное значение, правило и версия обработчика должны оставаться в журнале.

Третье - скрытая неоднозначность. Модель выбирает один из нескольких вариантов и пишет уверенное объяснение. Правильное действие в такой ситуации - отказ от автоматического изменения.

Четвёртое - смешение неизвестного и пустого. Пустое поле может означать отсутствие данных, неприменимость или ошибку загрузки. Превращать все варианты в одно значение опасно.

Пятое - повторный прогон. Нормализованная запись после второй обработки не должна неожиданно измениться ещё раз. Это проверяется повторным применением того же набора правил.

Шестое - молчаливый пропуск. У каждого отказа должен быть след: идентификатор записи, правило, причина и принятое действие.

Цена повторных попыток хорошо видна в разборе работы ИИ-агентов. Для данных вывод ещё жёстче: количество обработанных записей ничего не говорит о пользе, пока неизвестна цена исправления результата.

Чем проверить результат до масштабирования

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

Проверочный набор:

Отдельно нужно смотреть распределение изменений. Если одно правило внезапно затронуло несоразмерно большую часть пилота, это повод остановиться и проверить условие. Точный порог зависит от данных, поэтому его нельзя честно придумать заранее.

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

Коротко: этот промпт собирает план целиком, но не выдаёт модели право изменять данные. Его результатом должна стать спецификация для кода и проверки.

Ты проектируешь безопасный конвейер нормализации большого массива номенклатуры.

Цель:
[КАКОЙ РЕЗУЛЬТАТ НУЖЕН]

Данные:
- назначение базы: [НАЗНАЧЕНИЕ]
- объём: [ОБЪЁМ ИЛИ ДИАПАЗОН]
- поля записи: [СПИСОК ПОЛЕЙ]
- обязательные поля: [СПИСОК]
- устойчивый идентификатор: [ПОЛЕ]
- разрешённые к изменению поля: [СПИСОК]
- запрещённые к изменению поля: [СПИСОК]
- утверждённые справочники: [СПИСОК ИЛИ НЕТ]
- примеры исходных записей: [ПРИМЕРЫ]
- примеры правильного результата: [ПРИМЕРЫ]
- примеры недопустимого результата: [ПРИМЕРЫ]
- критические последствия ошибки: [СПИСОК]
- доступный способ отката: [ОПИСАНИЕ]
- формат журнала: [ПОЛЯ ЖУРНАЛА]

Спроектируй конвейер по этапам.

1. Контракт данных.

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

2. Граница между кодом, справочником, моделью и человеком.

Каждое преобразование назначь самому простому исполнителю, который способен дать проверяемый результат.
Детерминированные операции назначай коду.
Точные соответствия назначай утверждённому справочнику.
Модель используй только для смысловых кандидатов.
Неоднозначные и критические случаи назначай человеку.

3. Формат ответа модели.

Модель может вернуть только:
- идентификатор;
- исходное значение;
- предлагаемое значение;
- имя правила;
- основание;
- уверенность;
- решение: предложить, пропустить или отправить человеку.

Модель не изменяет источник данных напрямую.

4. Технические правила.

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

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

5. Пилот.

Сформируй состав выборки из обычных, редких, пустых, конфликтных и крайних записей.
Размер пачки оставь параметром [РАЗМЕР ПАЧКИ].
Определи проверки до записи и после записи.
Не назначай числовые пороги без предоставленных данных.

6. Инварианты.

Обязательно включи:
- количество записей не теряется;
- запрещённые поля не меняются;
- исходное значение сохраняется;
- каждое изменение имеет правило и версию;
- неизвестное не заменяется догадкой;
- повторный прогон не меняет результат;
- любой отказ попадает в журнал.

7. Ранняя остановка.

Опиши условия, при которых:
- текущая пачка останавливается;
- следующая пачка не запускается;
- запись пропускается;
- запись отправляется человеку;
- весь пилот откатывается.

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

8. Приёмка.

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

9. Масштабирование.

Разреши переход к следующему объёму только после прохождения всех проверок пилота.
Укажи, какое доказательство требуется для каждого условия перехода.
Не считай зелёный статус процесса доказательством правильности данных.

Запреты:
- не придумывай справочники и бизнес-правила;
- не объединяй похожие записи без подтверждения;
- не удаляй исходные значения;
- не скрывай неизвестное;
- не заменяй проверяемые условия субъективной оценкой;
- не предлагай запуск на всей базе до пилота и проверки отката;
- не разрешай модели записывать результат напрямую в источник истины;
- не используй отсутствующие во входных данных сроки, пороги и допустимые проценты ошибок.

Формат ответа:
А. Блокирующие неизвестные.
Б. Контракт полей.
В. Матрица исполнителей.
Г. Спецификация правил.
Д. Формат ответа модели.
Е. План пилота.
Ж. Инварианты и условия остановки.
З. Чек-лист приёмки.
И. Условия масштабирования.
К. Риски, которые остаются и требуют решения владельца.

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

Что ты уносишь

Коротко: готовая цепочка отделяет исследование, правила, пилот и приёмку. Её можно забрать целиком и адаптировать под собственную базу.

Главный результат здесь не формулировка для модели, а архитектура ограничений:

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

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

Если нужно собрать такой контур под вашу базу

Коротко: я могу собрать архитектуру нормализации, границы для модели, пилот и проверяемую схему приёмки под ваши данные.

Напишите мне в личку кодовое слово «ИИ-ДЖИНН ЛАМПЕ».