Прямой ответ
ChatGPT и другие general LLM технически не приспособлены для батч-нормализации справочников НСИ — не потому, что «недостаточно умные», а потому, что архитектурно решают другую задачу. Общая модель обучена отвечать связно и правдоподобно на любой текстовый запрос, но у неё нет постоянной памяти между запросами, нет доступа к реальным данным использования записей в учётной системе и нет механизма проверки собственного ответа против фактов. Для разового вопроса это не проблема. Для батч-обработки тысяч однотипных строк справочника — где нужна консистентность решений, знание контекста конкретного бизнеса и проверка последствий каждого действия — это ровно те четыре слабых места, которые ниже разобраны по отдельности.
Специализированный инструмент (НСИ Нормализатор) закрывает эти четыре пробела гибридным RAG с самообучением, предварительной векторизацией на паттернах НСИ и прямой сверкой с индексом реального использования записей в 1С. Дальше — по порядку, зачем каждый из этих механизмов нужен и что случится без него.
Причина 1: галлюцинации на структурированных данных
Общая LLM оптимизирована выдавать связный, уверенно звучащий текст — это то, за что её хвалят в диалоге и ругают при работе со списками. При обработке большого массива однотипных строк (тысячи наименований номенклатуры, контрагентов, складов) у модели нет встроенного механизма, который бы остановил её и сказал «ты не уверена — переспроси» — она с одинаковой уверенностью формулирует и верное, и ошибочное решение. На большом списке визуально похожих записей (например, серия из десятков позиций, отличающихся только числом — диаметром, объёмом, процентом жирности) у модели нет структурного барьера, который помешал бы ей скопировать текст или логику решения с одной записи на визуально похожую соседнюю, если это статистически выглядит правдоподобным продолжением текста.
Ключевая техническая деталь: чем однороднее батч (длинный список товаров одной категории, контрагентов одной отрасли), тем выше риск, что модель начнёт путать конкретные детали между записями — это свойство того, как языковая модель предсказывает следующий токен, а не случайная ошибка. Без отдельного детерминированного слоя проверки после генерации (который сверяет вывод модели с исходными данными построчно) уверенный неверный ответ ничем не отличается от уверенного верного — оба выглядят одинаково гладко.
Причина 2: отсутствие контекста бизнеса
У general LLM нет знания о том, что в конкретной 1С-базе считается дублем, а что — нет, потому что это знание не текстовое, а структурное, специфичное для схемы данных именно этой компании. Простой пример: в справочнике «Единицы измерения» 1С может подчинять запись справочнику «Номенклатура» через служебное поле-владельца — и тогда два одинаковых по названию элемента с разными владельцами вовсе не дубли, а совершенно легитимные разные записи. ChatGPT, которому просто скормили список названий без этого структурного контекста, физически не может знать про это правило — оно не следует из семантики текста, оно следует из схемы конкретной базы данных.
То же самое с принятыми в компании сокращениями, форматом наименований, правилами для конкретного домена НСИ (что означает «филиал» для контрагентов, что считается «эталонным» написанием для номенклатуры). Это не универсальные факты языка, а локальные бизнес-правила, которые нужно либо объяснять модели заново в каждом запросе (что нереалистично на масштабе тысяч записей), либо система должна их помнить и применять сама — а обычный чат-интерфейс такой памяти между независимыми запросами не имеет.
Причина 3: нет проверки реального использования
ChatGPT не подключён к базе 1С и не может проверить, ссылается ли конкретная запись справочника на документы, обороты или остатки. Любое решение «удалить» или «объединить» запись, вынесенное general LLM, — это предположение вслепую относительно реальных последствий: модель не знает, используется ли эта позиция номенклатуры в активных заказах, есть ли движения по контрагенту за последний год, стоит ли склад в остатках прямо сейчас.
Это критично именно для DELETE-решений: запись без оборотов за 12 месяцев может быть неактивной, а может быть сезонной или редко используемой позицией, которая в следующем квартале снова понадобится. Разница видна только при прямой сверке с данными об использовании — документами, регистрами накопления, остатками — а не по одному только тексту наименования. Технически это означает, что перед любым решением нужен отдельный индекс фактического использования каждой записи в учётной системе (какие документы и регистры на неё ссылаются, за какой период), с которым сверяется каждый вердикт. У generic-чата такого индекса нет и не может быть в рамках обычного диалогового запроса.
Причина 4: нет памяти между запросами
Каждый новый батч, отправленный в обычный ChatGPT, — это чистый лист: модель не помнит, что в предыдущем запросе специалист НСИ уже поправил похожее решение или утвердил правило для конкретного случая. Если сегодня специалист скорректировал вердикт по одной записи, а завтра в новом чате встречается почти идентичный случай — модель снова начинает с нуля, без учёта уже принятого решения. На масштабе разового вопроса это не проблема. На масштабе батч-обработки, где решения по похожим записям должны быть согласованы между собой (иначе результат нельзя доверять как систему), отсутствие памяти превращается в системную непоследовательность: одна и та же логическая ситуация в разных частях справочника получает разные, иногда противоречащие друг другу решения.
Как это решено в специализированном инструменте
НСИ Нормализатор устраняет все четыре пробела не переобучением общей модели «на всякий случай», а тремя конкретными архитектурными механизмами.
Гибридный RAG с самообучением и обучением «с учителем»
Система запоминает решения специалиста НСИ и правила компании, накопленные по ходу работы, и применяет их консистентно к новым похожим случаям — а не придумывает решение заново на каждый батч. Правило, один раз согласованное человеком, становится частью контекста для всех последующих похожих ситуаций.
Предварительная векторизация на паттернах НСИ
Модель дополнительно настроена на реальных паттернах справочных данных — она структурно отличает «одна и та же позиция, записанная по-разному» от «действительно разные позиции», в контексте конкретного производства или отрасли, а не только по внешнему сходству текста.
Прямая сверка с индексом реального использования
Перед вынесением вердикта по каждой записи система проверяет её фактическое присутствие в документах, регистрах накопления и остатках 1С — решение принимается не по тексту наименования, а по совокупности текста и реального использования. Именно так закрывается разрыв, описанный в причине 3: DELETE выносится только тогда, когда отсутствие использования подтверждено данными, а не предположено.
На реальном кейсе — производственное предприятие, 130 597 записей по восьми справочникам НСИ, 46% вердиктов MERGE (дубли) — обработка этого объёма вручную заняла бы 8–9 месяцев силами 5–6 сотрудников. Прогнать такой объём через обычный ChatGPT построчно с ручной проверкой каждого решения человеком физически нереалистично в разумные сроки — а без человеческой проверки каждого вердикта риски из причин 1–3 выше не снижаются, а переносятся напрямую в рабочую базу 1С.
Когда generic LLM можно использовать
Честный ответ: не для всего, что связано с текстом, general LLM непригодна. Обычный ChatGPT — рабочий инструмент для разовой, локальной задачи, где нет масштаба и нет прямых последствий для учётной системы:
- Разовая проверка нескольких конкретных записей вручную, когда специалист сам смотрит результат и сам принимает решение;
- Консультация по формулировке правила нормализации — например, обсудить с моделью, как лучше сформулировать критерий «что считать дублем» для конкретного домена, прежде чем зафиксировать это правило в реальном процессе;
- Черновая генерация текста регламента или инструкции для сотрудников, где ошибка не критична и результат в любом случае проверяется человеком.
Граница простая: как только речь идёт о батч-обработке сотен или тысяч записей без построчной проверки человеком, или о решениях, которые напрямую попадут в рабочую базу 1С (объединение, удаление, переименование), — риски галлюцинации, отсутствия бизнес-контекста, отсутствия проверки использования и отсутствия памяти между запросами становятся не гипотетическими, а системными. Для этого масштаба нужен специализированный инструмент с перечисленными выше механизмами, а не разовый диалог с чат-ботом.
Частые вопросы
Чем ChatGPT технически отличается от специализированного ИИ для нормализации НСИ?
ChatGPT — это general-purpose модель без памяти между запросами, без доступа к данным использования записей в 1С и без специальной настройки под структуру НСИ. Специализированный инструмент использует гибридный RAG с самообучением, предобучен на паттернах НСИ и напрямую сверяется с индексом реального использования каждой записи в учётной системе перед вынесением вердикта.
Может ли ChatGPT случайно удалить нужную запись из справочника?
Сам ChatGPT ничего не удаляет — он только предлагает текст решения, применение остаётся за человеком. Но если довериться его рекомендации без проверки реального использования записи в документах и остатках, риск ошибочного DELETE высокий: модель не видит, ссылается ли запись на активные документы.
Почему LLM путает похожие записи в одном батче?
Это свойство того, как языковая модель генерирует текст — она предсказывает наиболее вероятное продолжение, и на визуально однородном списке (например, серия товаров, отличающихся числом) вероятным продолжением иногда оказывается копирование текста или логики соседней записи. Без отдельного детерминированного слоя проверки после генерации это не отлавливается автоматически.
Можно ли научить ChatGPT правилам конкретной компании через длинный промт?
Частично и ненадолго — в рамках одного диалога модель удержит правила, изложенные в системном промте, но эта память не переносится на следующий независимый запрос или новую сессию. Для батч-обработки тысяч записей с сохранением консистентности решений нужен механизм, который запоминает и применяет накопленные правила системно, а не повторяет промт каждый раз заново.
Значит ли это, что ИИ вообще нельзя использовать для нормализации НСИ?
Нет — ИИ вполне применим для этой задачи, но специализированный, а не общего назначения. Разница не в том, «ИИ или не ИИ», а в архитектуре: наличие RAG с памятью решений, предобучение на паттернах НСИ и прямая сверка с реальными данными использования вместо генерации ответа вслепую по одному тексту наименования.
Как проверить, что вердикты нормализации действительно основаны на реальном использовании записи, а не придуманы моделью?
В специализированном инструменте каждый вердикт сопровождается обоснованием и данными о фактическом использовании записи (документы, обороты, остатки за определённый период), которые специалист НСИ может проверить перед утверждением. Решения не применяются в рабочую базу автоматически — только после проверки человеком.
Стоит ли использовать ChatGPT хотя бы для предварительной оценки масштаба проблемы в справочниках?
Для грубой прикидки на небольшой выборке — да, это разумный способ понять, что проблема существует. Для точной оценки масштаба (сколько реальных дублей, какая доля справочника затронута) нужна сверка с полным списком записей и данными использования — это уже задача для экспресс-аудита НСИ, а не для чат-бота.