AlphaCodium: ведущий путь в новую сферу генерации кода, от разработки подсказок до разработки процессов

Оригинал: [Современная генерация кода с помощью AlphaCodium - от оперативного проектирования до поточного проектирования]

Тал Ридник

 

 

 

просмотреть

 

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

 

В этом исследовании мы предлагаем новый метод генерации кода под названием АльфаКодиум -- Основанный на тестах, поэтапный, сфокусированный на коде, итерационный процесс лечения. Этот подход значительно улучшает способность Большой языковой модели (LLM) справляться с проблемами кода.

 

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

 

Например, на наборе данных для проверки точность (pass@5) GPT-4 повысилась с 19% до 44% с одной хорошо разработанной прямой подсказкой после использования процесса AlphaCodium. AlphaCodium не только превосходит предыдущие исследования, такие как AlphaCode, но и требует значительно меньше вычислительных ресурсов. AlphaCodium.

 

Мы считаем, что многие из принципов и лучших практик, разработанных в этой работе, применимы к широкому кругу задач по генерации кода. Наш последний проект с открытым исходным кодом [АльфаКодиумНаше решение AlphaCodium для CodeContests представлено в ], а также полные сценарии оценки наборов данных и бенчмаркинга для дальнейших исследований и изучения сообществом.

 

 

Разбор набора данных CodeContests

 

[CodeContests] - это сложный набор данных по программированию от Google Deepmind. Он основан на таких данных, как [CodeforcesПлатформа для конкурсного программирования, такая как ], имеет выбор из примерно 10 000 тем программирования, предназначенных для обучения и оценки больших языковых моделей (большие языковые модели, такие как GPT или DeepSeek) Способность решать сложные задачи программирования.

 

В данном исследовании мы не ставили перед собой задачу разработать совершенно новую модель, а скорее создать процесс программирования, применимый к различным большим языковым моделям, которые уже способны решать задачи кодирования. Поэтому мы сосредоточились на валидационном и тестовом наборах CodeContests, которые состоят из 107 и 165 задач по программированию. На рисунке 1 показан пример типичной задачи из набора данных:

 

 

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

 

Почему CodeContests - идеальный набор данных для тестирования возможностей программирования больших языковых моделей? Во-первых, в отличие от других наборов данных для конкурсов по программированию, CodeContests содержит большое количество частных тестовых данных (около 200 тестовых случаев на задачу) для обеспечения точности оценки. Во-вторых, большие языковые модели обычно не очень хорошо замечают детали в описаниях задач, которые часто являются критическими для нахождения правильного решения. Описания задач в CodeContests обычно сложные и подробные, полные нюансов, которые влияют на решение (типичный пример показан на рисунке 1). Такой дизайн имитирует сложность реальных задач, заставляя модель учитывать множество факторов, что контрастирует с некоторыми более простыми и понятными наборами данных (например, [HumanEval]) резко контрастирует. Типичная задача программирования HumanEval показана в Приложении 1.

 

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

 

 

 

Предлагаемая методология

 

При решении сложных задач генерации кода мы обнаружили, что ни оптимизация с помощью одного запроса, ни непрерывное обдумывание запросов не смогли значительно повысить эффективность решения задач большими языковыми моделями (LLM) на CodeContest. Это связано с тем, что модели часто не могут полностью понять проблему и поэтому постоянно выдают код, который является неправильным или неспособным справиться с новыми тестовыми ситуациями. Подходы, применимые к общей обработке естественного языка, могут не подходить для задач генерации кода. Такие задачи скрывают в себе большой потенциал, например, многократное выполнение сгенерированного кода и его проверка на известных примерах. В отличие от методов оптимизации подсказок в обычной обработке естественного языка, мы обнаружили, что решение задачи CodeContest с помощью генерации кода и тестирования специально длярабочие процессыболее эффективным. Этот процесс вращается вокругитерация (математика)Процесс разворачивается, то есть мы постоянно запускаем и настраиваем сгенерированный код так, чтобы он прошел тесты ввода-вывода. Два ключевых аспекта этого специфического для кода процесса таковы:

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

 

 

 

Процесс, показанный на рисунке 3, состоит из двух основных этапов:

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

 

В таблице 1 мы подробно рассмотрим эти этапы:

Название этапа	программное заявление
Отражение проблемы	Кратко изложите суть проблемы в виде лаконичных пунктов, охватывающих цели, входы, выходы, правила, ограничения и другие важные детали.
Логический анализ открытых тестовых случаев	Опишите, как входные данные каждого тестового случая приводят к определенному результату.
Разработка концепции возможных решений	Предложите 2-3 возможных решения и опишите их простыми словами.
Оценка решений	Оцените различные возможные решения и выберите лучшее, учитывая его корректность, простоту и надежность. (Не обязательно ограничиваться самым эффективным вариантом).
Дополнительное тестирование искусственного интеллекта	Дополните проблему 6-8 различными типами тестов ввода-вывода, которые пытаются охватить ситуации и аспекты, не охваченные исходными открытыми тестовыми случаями.
Программа первоначального кода	Цель этого этапа - сформировать начальный код решения задачи. Важно, чтобы этот код был как можно ближе к правильному ответу, так как это повысит вероятность успеха в последующем процессе исправления. Процесс работы выглядит следующим образом: - Выберите возможный сценарий, напишите для него соответствующий код и опробуйте его в выбранных публичных тестовых кейсах и тестах AI. - Повторяйте этот процесс до тех пор, пока тест не будет пройден или не будет достигнуто максимальное количество попыток. - Первый код, прошедший тест, или код, вывод которого наиболее близок к правильному ответу, будет использован в качестве базового кода для последующих шагов.
Итеративная оптимизация открытых тестовых случаев	Возьмите базовый код в качестве отправной точки, прогоните его по очереди в открытых тестах и оптимизируйте. Если в одном из тестов в коде возникла проблема, попробуйте исправить ее, основываясь на сообщении об ошибке.
Итеративная оптимизация для тестирования ИИ	Продолжайте итеративную оптимизацию в тестах, созданных ИИ. Применять "тестовые якоря" (техника исправления определенных элементов в тестах для более точной отладки и улучшения кода).

 

Таблица 1. Характеристика фаз AlphaCodium.

 

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

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

 

Следующий.Генерировать дополнительные тесты ИИ проще, чем генерировать полный набор кода решения -- Этот процесс в значительной степени опирается на понимание проблемы и базовое решение методом грубой силы или логическое рассуждение, не требуя полного решения проблемы для генерации полезных пар вход-выход. Это отличается от написания полного и правильного кода решения, который требует, чтобы мы придумали полное алгоритмическое решение, которое может правильно реагировать на любую пару входных-выходных тестов. В результате мы можем создать больше тестов ИИ и использовать их для оптимизации этапа создания кода, как показано на рисунке 4. Мы также повышаем эффективность этих дополнительных тестов, предлагая модели сосредоточиться на том, что не охвачено исходными открытыми тестами, например на обработке больших входных данных, краевых случаях и т. д.

 

Наконец-то.Несколько этапов могут быть объединены в один вызов Большой языковой модели (LLM). -- Процесс, показанный на рисунке 3, является концептуальной демонстрацией, выделяющей основные этапы процесса. На практике, структурируя выходные данные (см. следующий раздел), мы можем объединить несколько этапов в один большой вызов языковой модели для экономии ресурсов или повышения производительности модели при одновременном решении определенных задач.

 

 

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

 

 

Концепции дизайна для кода

 

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

Структурированный вывод YAML: Ключевой частью предлагаемого нами процесса является использование структурированного вывода - модель должна генерировать вывод в формате YAML, эквивалентный определенному классу Pydantic. Пример:

...

Ваша цель - придумать возможные решения.

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

На выходе должен получиться объект YAML, соответствующий типу $PossibleSolutions, в соответствии со следующим определением Pydantic:

класс Solution(BaseModel).

name: str = Field(description="Название решения")

content: str = Field(description=Описание решения")

why_it_works: str = Field(description="Почему это решение работает. Должно быть подробно описано в соответствии с правилами и целями задачи.")

сложность: str = Field(description="Сложность решения")

класс PossibleSolutions(BaseModel).

possible_solutions: List[Solution] = Field(max_items=3, description="Список возможных решений задачи. Убедитесь, что каждое решение полностью учитывает правила и цели задачи и имеет разумное время выполнения на современном компьютере - не более трех секунд для проблемных ограничений с большим числом входов.")

Таблица 2. Примеры структурированных выходных подсказок (фаза Generate Possible Solutions).

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

Хотя новая версия GPT поддерживает [Стиль JSON], но мы считаем, что, особенно в задачах генерации кода, вывод YAML является более подходящим, как подробно описано в приложении.

 

Анализ по пунктам - Когда большую языковую модель (LLM) просят проанализировать проблему, лучшие результаты обычно получаются, если запросить вывод в формате Bullet points. Буллет-пойнты способствуют более глубокому пониманию проблемы и заставляют модель разделить вывод на логические семантические области, что повышает качество результатов. Например, в случае с проблемой саморефлексии в виде пулевых точек (см. рис. 2) каждая пулевая точка представляет собой семантическое понимание отдельной части проблемы - общего описания, целей и правил, структуры входа и структуры выхода.

 

Большие языковые модели лучше генерируют модульный код - Когда мы позволяем Большой языковой модели (LLM) приступить к написанию длинного блока отдельных функций, мы часто сталкиваемся с проблемами: в коде часто встречаются ошибки или логические дыры. Хуже того, такие большие и монолитные куски кода могут мешать последующим итерациям по их исправлению. Даже если информация об ошибках предоставлена, модели сложно определить и устранить проблему. Однако если мы явно дадим модели указание "_Разбить сгенерированный код на множество небольших подфункциональных модулей и дать им осмысленные имена_", результаты будут гораздо лучше, с меньшим количеством ошибок в сгенерированном коде и более высоким процентом успеха на этапе итеративного исправления.

 

Важность гибкого принятия решений и двойного подтверждения - Большие языковые модели часто не справляются с задачами кода, которые требуют вдумчивых, рациональных умозаключений и способности принимать серьезные, нестандартные решения. Например, при генерации дополнительных тестов для задачи тесты, сгенерированные моделью, часто содержат ошибки. Для решения этой проблемы мы ввели процесс двойной валидации. В этом процессе после генерации исходного вывода модель просят сгенерировать тот же вывод еще раз и при необходимости скорректировать его. Например, получив на вход собственные сгенерированные тесты ИИ, модель должна заново сгенерировать эти тесты и вовремя исправить в них ошибки (если таковые имеются). Мы обнаружили, что этот шаг двойной проверки не только мотивирует модель мыслить и рассуждать критически, но и более эффективен, чем прямые вопросы типа "да/нет": "Правилен ли этот тест?". например, вопросы типа "да/нет".

 

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

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

 

 

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

 

Испытание анкерной технологии - Несмотря на двойную проверку, некоторые тесты, созданные ИИ, все равно могут быть ошибочными. В связи с этим возникает проблема: когда тест не проходит, как определить, проблема ли это в коде или ошибка в самом тесте? При прямом запросе к модели "что не так" мы часто получаем нереалистичные ответы, что иногда приводит к неправильному изменению кода. Чтобы решить эту проблему, мы ввели подход под названием "тестовые якоря":

• Сначала итерация выполняется над общедоступными тестами, которые, как известно, являются правильными. По завершении этого этапа все пройденные тесты обозначаются как эталонные (anchor tests).
• Затем начните проверять тесты, созданные ИИ, один за другим.
• Те, кто прошел тест, добавляются в список тестирования якорей.
• Если тест не пройден, по умолчанию считается, что код неверен, и предпринимается попытка его исправить. Важно отметить, что исправленный код также должен пройти все существующие тесты якорей.

 

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

 

 

в конце концов

 

Сравнение прямых наконечников с альфакодием

На рисунке 5 мы сравниваем результаты AlphaCodium с результатами одного хорошо разработанного метода прямой подсказки. Критерием оценки является pass@k (коэффициент успешности решения задачи), то есть доля решений, полученных с помощью k для каждой задачи.

 

 

Видно, что подход AlphaCodium значительно и стабильно улучшает производительность больших языковых моделей (LLM) при решении задач программирования в CodeContests. Этот вывод применим как к моделям с открытым исходным кодом (например, DeepSeek), так и к моделям с закрытым исходным кодом (например, GPT), как на валидационных, так и на тестовых наборах.

 

Сравнение с другими исследованиями:

В таблице 3 представлены результаты AlphaCodium в сравнении с другими методами в литературе.

 

моделирование	набор данных	методологии	оценка
GPT-3.5	набор для проверки	АльфаКодиум  (pass@5)	25%
GPT-3.5	набор для проверки	CodeChain (pass@5)	17%
GPT-3.5	тестовый набор	АльфаКодиум (pass@5)	17%
GPT-3.5	тестовый набор	CodeChain (pass@5)	14%
GPT-4	набор для проверки	АльфаКодиум (pass@5)	44%
Тонкая настройка DeepMind	набор для проверки	AlphaCode (пас@10@1K)	17%
Тонкая настройка DeepMind	AlphaCode (пас@10@100K)	24%
GPT-4	тестовый набор	АльфаКодиум (pass@5)	29%
Тонкая настройка DeepMind	тестовый набор	AlphaCode (пас@10@1K)	16%
Тонкая настройка DeepMind	тестовый набор	AlphaCode (пас@10@100K)	28%
Gemini-pro	AlphaCode2: Результаты сравнения для AlphaCode2 не сообщаются в существующих версиях CodeContests. Согласно Технический отчет по AlphaCode2Исследователи сравнили результаты AlphaCode с результатами AlphaCode2 на неопубликованном наборе данных и обнаружили значительное сокращение количества вызовов большой языковой модели (LLM) (@100В этом случае AlphaCode2 работает сопоставимо с AlphaCode, оба являются 29%, пас@10.

 

Таблица 3: Сравнение AlphaCodium с другими исследовательскими работами в литературе

 

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

 

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

 

Рисунок 6: Сравнение эффективности. Вот как AlphaCodium сравнивается с другими решениями по точности в сравнении с количеством вызовов Large Language Model (LLM). По сравнению с AlphaCode, AlphaCodium требует в тысячи раз меньше вызовов LLM для достижения аналогичной точности.

Если сравнить AlphaCodium с той же моделью GPT-3.5 и критерием "проходной балл 5 попыток" [CodeChainЕсли сравнивать с [ ], то очевидно, что AlphaCodium работает лучше. При сравнении с [AlphaCodeПри сравнении методов [AlphaCode] важно отметить, что AlphaCode использует другую стратегию генерации кода: она оптимизирует конкретную модель для решения проблемы кодирования, генерирует большое количество сценариев кодирования, затем классифицирует их и в конечном итоге выбирает несколько сценариев для отправки из основных классификаций. Например, "10 попыток проходит из 100 000 решений" означает, что он генерирует 100 000 решений, классифицирует их, а затем выбирает 10 для отправки. AlphaCode использует специально оптимизированную модель, которая использует большее количество вызовов LLM, подобно исчерпывающей стратегии. Тем не менее, AlphaCodium показала лучшие результаты.

 

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

 

Сравнение вычислительной мощности: AlphaCode против AlphaCode2

В процессе AlphaCodium решение каждой задачи требует около 15-20 обращений к Большой языковой модели (LLM), что означает, что в ходе пяти попыток требуется около 100 обращений к LLM.

 

И AlphaCode не сообщает, сколько вызовов большой языковой модели требуется на одну задачу. Если мы предположим, что она вызывается один раз за попытку (что пока неизвестно и может быть на самом деле больше), то для каждой из 10 попыток, отфильтрованных из 100 000 решений, потребуется вызвать большую языковую модель 1 миллион раз, что на четыре порядка больше, чем у AlphaCodium. Однако, судя по полученным результатам, AlphaCodium работает гораздо лучше, что наглядно демонстрирует рисунок 3.

 

Недавно было опубликовано исследование под названием AlphaCode2 ([...Технический отчет]), в котором исследователи оценивали модель Gemini-Pro, точно настроенную на решение задач программирования. В исследовании также изучался бенчмарк CodeContests, но с использованием неопубликованной обновленной версии. Согласно отчету AlphaCode2, при использовании всего около 100 образцов AlphaCode2 достигает уровня производительности, которого AlphaCode достигает при использовании миллионов образцов, что делает его более чем в 10 000 раз более эффективным по сравнению с AlphaCode. В результате и AlphaCode2, и AlphaCodium гораздо эффективнее AlphaCode с точки зрения количества вызовов больших языковых моделей.

 

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

 

приложение

 

1) Пример ручной оценки проблемы с кодом:

/*

Проверяет, есть ли в наборе чисел два числа, расстояние между которыми меньше определенного числового порога. >>>

has_close_elements({1.0, 2.0, 3.0}, 0.5) false >>>

has_close_elements({1.0, 2.8, 3.0, 4.0, 5.0, 2.0}, 0.3) true

*/

#include

#include

#include

используя пространство имен std;

bool has_close_elements(vector numbers, float threshold){

 

Таблица 4.Проблема относительно интуитивно понятна и проста, без особых деталей и тонкостей, о которых должна рассуждать модель.

 

2) Почему вывод YAML лучше подходит для задач генерации кода, чем вывод JSON

Хотя новая версия GPT имеет [встроенная поддержка], но мы считаем, что для генерации кода более подходящим является вывод в формате YAML. Это связано с тем, что генерируемый код часто содержит одинарные кавычки, двойные кавычки и специальные символы. В формате JSON LLM сложно правильно разместить эти символы, поскольку вывод JSON должен быть окружен двойными кавычками. Вывод YAML, с другой стороны, [Принятие блочных скаляров] стиль, просто следуйте правилам отступов, и любой правильно отступящийся текст или код будет законным. Кроме того, вывод YAML содержит меньше лексем, что означает снижение стоимости и ускорение процесса вывода, а также повышение качества, поскольку модель имеет меньше некритичных лексем, на которые нужно обращать внимание. Вот пример сравнения вывода JSON и YAML (с использованием [https://platform.openai.com/tokenizer] сгенерирован):

импортировать json

импортировать yaml

s1 = 'print("строка с двойными кавычками")'

s2 = "print('строка в одинарных кавычках')"

s3 = 'print("""строка в тройных кавычках"")'

s4 = f"{s1}\n{s2}\n{s3}"

# Создайте словарь с ключами в виде имен переменных и значениями в виде строк

data = {'s1': s1, 's2': s2, 's3': s3, 's4': s4}

# Преобразование словаря в строку формата JSON

json_data = json.dumps(data, indent=2)

print(json_data)

# Преобразование словаря в строку формата YAML в стиле блочного скаляра

yaml_data = yaml.dump(data, indent=2, default_style='|')

print(yaml_data)

Выход.

 

Таблица 5.

Вывод в формате JSON:

 

Рисунок 7. Пример подсчета токенов с помощью вывода JSON.

Пример вывода YAML показан ниже:

 

 

Рисунок 8. Пример подсчета токенов с помощью вывода YAML.

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