В последние годы большие языковые модели (LLM) уверенно вошли в сферу программирования, предлагая разработчикам инструменты для автоматического написания и редактирования кода. Однако, несмотря на значительный прогресс, некоторые технические ограничения всё ещё остаются актуальными. Одной из таких проблем является низкое качество кода при его возвращении в структурированном формате JSON, что стало предметом многочисленных исследований и обсуждений в AI-сообществе. Эта особенность затрагивает многие современные модели, включая самые продвинутые, поддерживающие строгую генерацию JSON-сообщений. Погружение в суть проблемы поможет понять, почему разработчики и организации продолжают отдавать предпочтение простому текстовому формату кода, несмотря на возрастающие возможности по работе с JSON форматом в LLM.
Большая часть критики связана с тем, что, когда модели просят представить код в рамках JSON-структуры, они демонстрируют значительное снижение качества результата. Проблемы возникают не только на уровне синтаксиса, но и на этапе общей логики решения задачи. Важно отметить, что синтаксическая корректность собственного JSON не гарантирует высокого качества вложенного кода. Несмотря на совершенствование инструментов, позволяющих строго контролировать соответствие формата JSON заданным схемам, модели по-прежнему испытывают сложности с правильной обработкой кавычек, экранированием символов и общим форматированием внутри кода. Принципиальная сложность состоит в том, что код, особенно на языках вроде Python, часто содержит строки с вложенными кавычками, что требует точного и корректного соблюдения правил экранирования при упаковке в JSON.
Для искусственного интеллекта подобное двойное экранирование становится источником ошибок — нарушается структура строки, что приводит к синтаксическим ошибкам и, как следствие, к невозможности корректно запустить сгенерированный фрагмент. Например, одна из типичных ошибок — некорректно закрытая строка из-за неверной интерпретации внутренних апострофов, а также смешение обратных и прямых слэшей. Эти проблемы еще больше усложняют генерацию работоспособного кода при разметке JSON. Результаты последних исследований и бенчмарков на основе большого количества упражнений по программированию и редактированию кода подчеркивают эту тенденцию. Модели, такие как gpt-4o и другие сильнейшие код-ориентированные ядра, тестировались с использованием различных стратегий возвращения кода: простой текст в markdown, JSON и строгое JSON.
Анализ показывает, что модели стабильно демонстрируют лучшие результаты при генерации кода в markdown формате, где отсутствуют ограничения по экранированию и структурированию данных. В свою очередь, формат JSON, даже с включением новых строгих режимов проверки, неизменно снижал точность и качество решения, иногда существенно. К сожалению, внедрение строгости в форматировании не исправляло проблему, а лишь подтверждало, что техническая реализуемость формата не означает улучшения с точки зрения генерации кода. Особенно интересен эффект на разные модели. Некоторые из них, например gpt-4o-2024-05-13, показывают лишь незначительное снижение результативности при использовании JSON, что может говорить о разнице в архитектуре и подходах к обучению.
Вместе с тем модели Sonnet и DeepSeek Coder ощущали серьезное падение качества, несмотря на надёжное формирование синтаксиса JSON — ключевым фактором оказалась именно сложность синтаксиса внутри кода, что нарушало логику и композицию конечного результата. Необходимо также учесть, что помимо очевидных синтаксических ошибок, JSON-формат ввода накладывает ментальную и технологическую нагрузку на модели. Это проявляется в ухудшении их способности к решению прикладных задач, снижении эффективности внутреннего «мышления» модели — как если бы блоки кода программно «запечатываются» в жесткую структуру, ограничивая свободу творческого и логического подхода модели к проблематике. В конечном итоге страдают не только отдельные строчки находящихся внутри JSON «полей», но и общая способность модели предлагать оптимальные, работающие решения. Для понимания степени влияния этого феномена были проведены комплексные замеры, в которых модели подвергались серии из 133 разноплановых упражнений без возможности повторных попыток корректировки кода.
Это позволило объективно отследить эффективность каждой стратегии генерации, особенно в сравнении с markdown, где код возвращается в привычном для разработчика формате с визуальным разделением и минимальными искажениями. Результаты убедительно показали, что LLM, хотя и способны создавать валидный JSON, не достигают высокого качества генерации кода в этом формате, в отличие от простого текстового вывода. Важно подчеркнуть, что проблема не столько в JSON как формате, а в сути задачи — дисциплинировать сложные языковые модели так, чтобы они могли одинаково эффективно «думать» о проблеме и одновременно точно конвертировать технически сложные структуры кода в JSON без потери качества. Современные технологии только начинают подходить к это точке. Улучшения алгоритмов, например введение механизмов строгой проверки, начинают давать первые плоды, но это далеко от идеала.
В практическом плане разработчики и инженеры, использующие LLM для автоматизации кодирования, вынуждены делать выбор в пользу простого текстового формата. Этот подход более привычен и минимизирует ошибки, связанные с экранированием и форматированием, что особенно важно в многопользовательской, быстрой среде разработки. Хотя JSON предоставляет явные преимущества для интеграции в инструменты и системы с автоматической проверкой, пока его использование оставляет желать лучшего с точки зрения конечной надежности и качества кода. Перспективы дальнейших исследований и разработок, однако, вдохновляют на оптимизм. Разработчики LLM, включая OpenAI и других крупных игроков, активно работают над улучшением внутренней архитектуры моделей и механизмов генерации JSON для кода.
Внедрение новых функций, таких как настройка «strict JSON», расширенные схемы верификации, а также обучение на более сложных и разнообразных данных, постепенно сокращают разрыв в качестве между двумя форматами respuesta. Больше внимания уделяется также контекстному пониманию кода и правильному применению экранирования, что позволит в будущем не только генерировать синтаксически корректный JSON, но и поддерживать высокий уровень решения поставленных задач. Выводы ясно указывают, что на данный момент применение LLM для генерации кода в JSON формате остается ограниченным и сопряжено с существенными рисками снижения качества результата. Переход на структурированные форматы данных в автоматизации программирования требует аккуратного баланса между технологическими возможностями и особенностями моделей. Пока что практическая реализация чаще ориентируется на максимально понятные и простые для моделей варианты — в первую очередь markdown и plain text.
Тем не менее, по мере развития технологий и повышения качества моделей возможно создание новых стандартов взаимодействия, где JSON станет полноценным и надежным форматом для передачи кода. Важно, чтобы заказчики и пользователи LLM понимали эти ограничения и вводили подходящие механизмы контроля качества, тестирования и дописывания кода после автоматической генерации, особенно в критичных для бизнеса или безопасности проектах. Интеграция моделей с CI/CD процессами, статическим анализом и ручной проверкой остается необходимой для обеспечения стабильности и надежности создаваемых программных продуктов. Таким образом, проблема плохого качества кода, возвращаемого в формате JSON большими языковыми моделями, — это вызов, лежащий на стыке лингвистики, программирования и инженерии ИИ. Ее решение потребует междисциплинарного подхода, объединяющего лучшие практики в области машинного обучения, обработки естественного языка и разработки ПО.
Только такое скоординированное движение позволит превзойти существующие ограничения и полноценно раскрыть потенциал автоматизированного программирования в будущем.
