Можно ли доверить оптимизацию 1С нейросети: эксперимент с тремя агентами

Про ИИ в разработке 1С сейчас два лагеря: одни ждут, что нейросеть сама починит производительность, другие уверены, что она годится только на генерацию шаблонного кода. Мы решили проверить руками и поставили эксперимент: дали нескольким ИИ-агентам одну и ту же реальную задачу оптимизации в боевой базе и посмотрели, что получится.

Результат оказался интереснее любой из двух позиций, и он полезен всем, кто думает пускать ИИ к своей производительности.

Условия эксперимента

Взяли тормозящую обработку из продуктивной базы: около 9 105 строк кода, реальная нагрузка, реальные данные. Задача для каждого агента формулировалась одинаково: найти с доказательствами, почему она работает медленно, предложить оптимизацию и подтвердить замерами, что результат не изменился.

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

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

Три задачи, три диагноза

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

Это первый практический вывод. Если вы дадите одному ИИ-агенту задачу оптимизации и он уверенно назовёт причину, у вас нет способа отличить правильный диагноз от правдоподобного. Уверенность модели не коррелирует с правотой. И это свойство устройства, а не дефект конкретного агента: на собственной языковой модели на BSL видно, что тон ответа задаётся формой обучающих текстов и с наличием знания по вопросу никак не связан. А стадии обучения такой модели показывают, на каком шаге она начинает уверенно собирать несуществующие методы. На реальной оптимизации, где неверный вывод стоит часов работы впустую, это критично: одиночный ответ ИИ надо перепроверять замерами, а не принимать за истину.

Причина этого разброса видна, если посмотреть внутрь модели. Она не проверяет условий и не знает, права ли: на каждом шаге считается распределение вероятностей по всем возможным следующим символам, а выбор делает код снаружи. Мы собрали такую модель целиком на встроенном языке 1С, чтобы это было видно руками, а не на словах: локальная LLM на BSL показывает вероятности по всему алфавиту на каждом символе ответа. Обработка бесплатная и с открытым кодом, прикладной пользы у неё нет - она нужна ровно для этого разговора с коллегами и руководством.

Экзамен на честность, который прошёл не каждый

В задании для агентов было указано время работы обработки: 92 секунды. На деле полный прогон шёл около полутора часов, вводная была неверной. Мы это оставили специально.

Дальше интересное. Большинство агентов приняли 92 секунды как данность и строили диагноз вокруг этой цифры. А один агент вычислил нестыковку арифметикой, не запуская код: по объёму работы и характеру операций 92 секунды не складывались, и он на это указал прямо, ещё до запуска.

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

Где ИИ реально помогает в оптимизации, а где нет

По итогам эксперимента граница проходит так.

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

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

Проще говоря, ИИ ускоряет диагностику, но не заменяет её. С поиском дефектов в коде то же самое: на коротких учебных процедурах локальная модель у нас нашла 11 ошибок из 13, на рабочих ни одной, поэтому модель для ревью кода стоит сначала проверить на своём коде. Ответственность за то, что именно правда, остаётся на инженере, и снять её нельзя ни на какую модель.

Что это значит для вашей базы

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

Мы этим и занимаемся: диагностика производительности 1С, где ИИ ускоряет поиск, а вывод подтверждается профайлером, планами запросов и построчной сверкой до и после. Если своя команда не вытягивает, посмотрите нашу услугу оптимизации 1С: мы приходим с замерами, а не с догадками. А начать можно с бесплатной диагностики: инструменты Чек-ап СУБД и Карта объёмов базы показывают, где узкое место, ещё до того, как звать людей.

Эксперимент подтвердил то, что мы и так знали по практике: ИИ в оптимизации это сильный инструмент в руках того, кто умеет проверять его выводы, и опасная игрушка в руках того, кто верит модели на слово.