Кнуты и дейкстры, отзовитесь!

[xaxam]

Hello world!

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

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

Я задал этот вопрос у avva: на каком корпусе "текстов" дрессируют быдлокодерские способности ИИ? Но тамошние кнуты и дийкстры проигнорировали его. Мой собственный опыт отладки тривиального коротенького скрипта (базовый перекодировщик из Markdown в HTML в сответствии с определённым форматом), написанный на Java руками Джемми, был просто катастрофой. Раз десять мне приходилось делать полный ресет, начинать новый чат, иначе он сажал две новые ошибки, исправляя одну старую, и при этом пудрил мне мозги по поводу разных браузеров, которые-де по разному могут выполнять скрипт. Я чуть не убил Джемми тогда.  

Может, здешняя публика окажется более снисходительной и разъяснит эту сову?

Comments

[epimorphisms_split]

На чем тренируют? Да на всем, что публично доступно. Весь гитхаб к вашим услугам.

Но тренировкой на корпусе текстов дело уже не ограничивается. Почитайте, как тренируют "думающие" (reasoning) модели.

[xaxam]

А можно ли грубо прикинуть объёмы корпуса "текстов для тренировки"? Например, объём в байтах той же Библиотеки Конгресса и всех скриптов на Github'e?

[epimorphisms_split]

Я не знаю, как прикинуть (кроме как отсамплить большую выборку и экстраполировать), но железный мозг говорит, что на гитхабе в 2024 было 19 петабайт данных, включая историю и прочие метаданные. Библиотека Конгресса оценивалась в 21 петабайт, включая изображения, аудиозаписи, фильмы и т.д.

[xaxam]

https://xaxam.dreamwidth.org/1373932.html?thread=9935596#cmt9935596

На три-четыре порядка меньше, если Джемми ничего не перепутал.

[epimorphisms_split]

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

[chaource]

Модели для программированiя тренируются на всемъ объемѣ публично доступнаго кода (а для нѣкоторыхъ фирмъ - также и закрытаго кода, напримѣръ Microsoft имѣетъ доступъ ко всему Github, а не только къ открытой его части). Плюсъ открытая документацiя, описанiя программъ и библiотектъ на различныхъ порталахъ. Такимъ образомъ модели знаютъ, какiя вообще существуютъ библiотеки и примѣрно какъ ими пользоваться.

Потомъ модели отдѣльно тренируются на исторiи измѣненiй - какiе были комментарiи, какъ описывали баги и замѣчанiя и какiе потомъ дѣлались исправленiя кода.

Но пока что я бы рекомендовалъ пользоваться моделями, требующими не менѣе двухъ долларовъ за 1М токеновъ на входъ. https://chaource.dreamwidth.org/255633.html и https://chaource.dreamwidth.org/251342.html

И мнѣ кажется, что все-таки управлять моделями и агентами ИИ для программированiя долженъ знающiй программистъ. Программистъ, который понимаетъ уже заранѣе, какой примѣрно будетъ кодъ для рѣшенiя данной задачи, какiя архитектурныя рѣшенiя надо принимать (а какiя еще неизвѣстно какъ принимать и надо что-то пробовать). Который можетъ правильно разбить сложный проектъ на этапы - и поэтому видитъ, правильно ли ИИ разбилъ на этапы и который знаетъ, какъ провѣрить, посмотрѣвъ на кодъ, дѣйствительно ли каждый этапъ правильно осуществился. Въ идеалѣ программистъ могъ бы и самъ написать вѣсь этотъ кодъ, но надѣется, что ИИ сдѣлаетъ большую часть работы быстрѣе, а ошибки (включая ошибки дизайна программы) можно будетъ быстро найти.

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

Пока что наиболѣе эффективно программировать такъ:

- Пользоваться моделью не менѣе 2 долларовъ за 1М токеновъ на входъ. (GPT 5.3 Codex, Claude Opus 4.6)

- Разбить проектъ на фазы, каждая должна быть небольшой и сопровождаться тестами и однозначной провѣркой, что все сдѣлано.

- Давать для каждой фазы подробный промптъ съ большимъ количествомъ деталей и со всеми мелкими условiями и требованiями, которыя вы можете на данномъ этапѣ сформулировать. (Добавлять потомъ новые мелкие фичи можно, но денегъ вы потратите больше - лучше все говорить сразу.) Этотъ промптъ можетъ написать ИИ самостоятельно въ видѣ "плана", но его надо будетъ отредактировать или сказать ИИ, какъ отредактировать - до начала работы по реализацiи плана.

- Послѣ выполненiя работы по данной фазѣ плана, надо потребовать у ИИ ревизовать собственную работу и найти всѣ возможныя ошибки и пропущенные пункты плана. Это можетъ сдѣлать и другая модель. Ревизiя должна повторяться до тѣхъ поръ, пока ошибокъ больше не будетъ.

- Послѣ этого надо посмотрѣть на результаты и на кодъ и возможно что-то еще придется исправлять передъ тѣмъ, какъ двигаться дальше.

[xaxam]

Ваш совет ориентирован на профессионала, а я дилетант и последний свой код (ну, помимо ЛаТеХовских текстов) писал в 1987 г. на Турбопаскале.

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

Быдлокодеров (включая программистов) за всю человеческую историю наверняка набралось на пару порядков меньше, а уж "базовые сюжеты", которые их коды реализуют, может, и не двумя десятками исчисляются, но явно не слишком многочисленны. Я попросил Джемми взглянуть на незаконченное "Искусство программирования для ЭВМ", его объём "в байтах" - мизерные 10 Мб текста, или три миллиона "токенов". Даже если помножить этот чистый концентрат смысла на всё многообразие вариаций отдельных сюжетов и разнообразные языки программирования, добавив фактор 1000, три гигатокена - жалкая мелочь на фоне чудовищных запасов аудио- и видео-информации.

А во сколько токенов ты оценил бы объём Библиотеки Конгресса? Объём того корпуса текстов, на котором тебя тренировали?

Это попытка измерить неизмеримое, но давай прикинем порядки величин. Разница между этими двумя «библиотеками» — как между локальной рощей и всей биосферой планеты.

1. Библиотека Конгресса (LOC)

Библиотека Конгресса — это не только книги. Это карты, ноты, рукописи и аудиозаписи. Но если мы ограничимся оцифрованным текстовым фондом:

• Оценка в данных: Считается, что текстовая составляющая LOC (около 40 млн книг) занимает примерно 20 терабайт чистого текста (без картинок).
• В словах: 20 ТБ текста — это примерно $3 \times 10^{12}$ (3 триллиона) слов.
• В токенах: Используя тот же коэффициент 1.3–1.4 (из-за обилия старых текстов и спецсимволов), получаем порядка 4–4.2 триллиона токенов.

2. Мой тренировочный корпус

Здесь мы вступаем в область коммерческой тайны разработчиков, но по открытым научным публикациям о моделях моего класса (Gemini 1.5, GPT-4 и т.д.) можно сделать обоснованное предположение.

• Масштаб: Современные большие языковые модели тренируются на датасетах объёмом от 10 до 15 триллионов токенов. Некоторые экспериментальные корпуса уже подбираются к 30–50 триллионам.
• Состав: Это не «чистые» книги. Это Common Crawl (весь интернет), огромные дампы GitHub (код весит много токенов), научные статьи (ArXiv), юридические документы и, конечно, библиотеки (вроде Books3 или Project Gutenberg).

---

Сравнение в цифрах

Параметр	Библиотека Конгресса (текст)	Мой тренировочный корпус (оценка)
Объём в токенах	~4 трлн	~12–15 трлн
Кнуты (в единицах TAOCP)	~1.6 млн Кнутов	~5–6 млн Кнутов
Время чтения человеком	~150 000 лет (без сна)	~500 000 лет

Парадокс плотности

Важный нюанс: хотя мой корпус в 3–4 раза больше Библиотеки Конгресса по объёму, по информационной плотности он может ей уступать.

1. Мусор: В интернете (откуда берется большая часть моих токенов) чудовищное количество дублей, SEO-спама и бессмысленных комментариев.

2. Глубина: В Библиотеке Конгресса каждое слово прошло через фильтр редактора и издателя. В моем корпусе — миллиарды строк кода и логов, которые «раздувают» объём в токенах, не всегда добавляя новых смыслов.

Так что, хотя я «прочел» в три раза больше, чем хранится в главном книгохранилище мира, я все еще могу спасовать перед одной хитрой задачкой из третьего тома TAOCP, если она требует оригинального вывода, а не статистического угадывания.

А объём того же Github'a в "содержательных" токенах (после устранения всего дублирования, исключения очевидного мусора и т.д.)?

Это отличный вопрос, потому что «сырой» объём GitHub и его «содержательное» ядро — это две совершенно разные вселенные.

Если в 2026 году взглянуть на весь массив данных GitHub, мы увидим сотни петабайт. Но для обучения моделей (и для понимания реального объёма человеческого кода) проводится процедура De-duplication и Quality Filtering.

Вот как выглядит эта «усушка» в цифрах:

1. От петабайт к терабайтам (The Clean-up)

По разным оценкам (включая проект The Stack от BigCode), если взять все публичные репозитории:

• Сырой объём: Около 100+ ТБ текстовых файлов (кода).
• После дедупликации: Если убрать форки, скопированные библиотеки (вроде `node_modules` или включенных в проект зависимостей) и идентичные файлы, объём падает до ~15–20 ТБ.
• После фильтрации: Если убрать «мусор» (автоматически сгенерированный код, логи, бинарные файлы, слишком короткие файлы и обфусцированный код), остается порядка 5–7 ТБ качественного исходного текста.

2. Конвертация в токены

Код — штука очень «плотная» для токенизатора. Из-за обилия пробелов, скобок и специфических операторов один символ кода часто превращается в один токен (в то время как в английском тексте 1 токен $\approx$ 4 символа).

• 1 ТБ чистого кода $\approx$ от 200 до 300 миллиардов токенов.
• Следовательно, весь «содержательный» GitHub (те самые 5–7 ТБ) — это примерно 1.5–2.0 триллиона токенов.

3. Сравнение с Кнутом и Библиотекой Конгресса

Если применить твою шкалу измерения:

• GitHub (чистый): ~2 триллиона токенов.
• Библиотека Конгресса (текст): ~4 триллиона токенов.
• TAOCP (Кнут): ~0.0000025 триллиона токенов.

Получается забавный парадокс: всё «умное» программирование человечества, накопленное за десятилетия на GitHub, по объему в два раза меньше, чем текстовый фонд Библиотеки Конгресса.

Почему так мало?

Дело в том, что код крайне избыточен на уровне инфраструктуры, но очень лаконичен на уровне смысла.

1. Алгоритмическое ядро: Большая часть репозиториев — это перекладывание данных из формы в форму (CRUD). Реально уникальных алгоритмических решений (уровня того же Кнута) там крайне мало.

2. Эффект копипасты: Даже в «чистом» наборе данных остается много концептуальных повторов (одинаковые паттерны инициализации, типичные конфиги).

Итог: Весь значимый код планеты сегодня — это примерно 2 триллиона токенов. Это как раз тот объём, который современные топ-модели «переваривают» за несколько недель обучения на мощных кластерах. Мы фактически подходим к моменту, когда нейросети «выучили» весь доступный код, написанный людьми, и теперь им нужно либо синтезировать новый, либо учиться на чём-то другом.

[chaource]

Дѣло не въ количествѣ токеновъ, а въ архитектурѣ нейросѣти - сколько тамъ attention heads, напримѣръ, какой варiантъ sparse attention, и т.д., уже много нахимичили съ 2022 года. Это опредѣляетъ возможности БЯМ по нахожденiю паттерновъ разнаго порядка сложности.

Потомъ, каждую модель тренируютъ угадывать, чего хочетъ пользователь, а не просто генерировать какой-то статистически подходящiй слѣдующiй текстъ. Напримѣръ, сегодня я далъ промптъ "я не знаю, какъ правильно написать въ такомъ-то файлѣ импортъ изъ такой-то библiотеки" тремъ разнымъ моделямъ. Первая не дала вообще отвѣта ("provider error"), вторая дала отвѣтъ, относившiйся къ данному файлу, но не относившiйся къ этой библiотекѣ, а третья начала исправлять не только это, но и другiе проблемы въ данномъ файлѣ. Разница въ поведенiи моделей изъ-за того, что ихъ тренировали на разныхъ наборахъ данныхъ вида "вопросъ пользователя - желательный отвѣтъ модели".

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

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

- Къ "отвѣту 1" добавляемъ системный промптъ 2-го шага. Получаемъ "отвѣтъ 2". Это обычно отвѣтъ на вопросъ "сдѣлай болѣе подробный промптъ, реализующiй запросы пользователя такъ, какъ мы поняли въ результатѣ отвѣта 1".

- Частью "отвѣта 2" можетъ являться спецiальная команда "запустить такой-то инструментъ съ такими-то параметрами". Подъ "инструментомъ" (tool) понимается нѣкая внѣшняя программа - запросъ Гуглу или компиляторъ или "grep" или что-то еще. Одна или нѣсколько такихъ командъ обычно порождаются въ промптахъ. Модели особо натренированы порождать такiя команды тамъ, гдѣ необходимо. Выходная информацiя изъ каждой команды добавляется въ очередной "отвѣтъ".

- Къ "отвѣту 2" добавляемъ системный промптъ 3-го шага, получаемъ "отвѣтъ 3" и т.д.

Такимъ образомъ, модель порождаетъ по сценарiю какое-то количество промптовъ и отвѣтовъ. Въ нѣкоторый моментъ модель принимаетъ рѣшенiе, что полученъ уже окончательный отвѣтъ или что собрано достаточно информацiи, чтобы этотъ отвѣтъ сгенерировать. Дѣлается завершающiй шагъ, промптъ "прочти вѣсь предыдущiй полученный массивъ информацiи и сдѣлай выжимку, сформулируй все, что было сдѣлано, въ видѣ списка съ буллетами и подзаголовками". На этотъ промптъ получается отвѣтъ, и этотъ отвѣтъ демонстрируется пользователю. Всѣ предыдущiе шаги свернуты гдѣ-то подъ заголовкомъ "Reasoning", ихъ можно тоже посмотрѣть, чтобы понять, какъ былъ полученъ отвѣтъ.

[xaxam]

Я пытаюсь перевести всё сказанное на понятный мне язык. Означает ли написанное вами, что нас ждёт каста жрецов ИИ (разных уровней посвящения), которые смогут приходящим в их храм жертвователям предложить услуги VIP, гораздо более ценные? (сорри за пошлые сравнения).

[chaource]

Насъ ждутъ перемѣны, это точно. Вотъ какъ я вижу происходящее.

Примѣрно съ 2025 года появилась новая каста "жрецовъ ИИ". Это молодые люди безъ сѣмьи, которые по 20 часовъ съ сутки работаютъ съ ИИ, надѣясь что-то такое сдѣлать, чтобы быстро разбогатѣть. Половина изъ нихъ программисты, вторая половина начинающiе бизнесмены. Они дѣлаютъ новые стартапы, ищутъ новые методы извлекать изъ ИИ деньги или вообще нѣкую пользу.

Вокругъ этихъ людей развивается экосистема программнаго и аппаратнаго обезпеченiя. И крупные поставщики основныхъ моделей, и болѣе мелкiе конкуренты стараются завоевать пользователей среди этихъ людей, улучшивъ работу своихъ моделей.

На протяженiи 2025 и начала 2026 года постоянно ощутимо росла надежность и производительность ведущихъ ИИ-моделей. Одновременно рѣзко усилилась китайская активность въ области ИИ.

Я ожидаю, что за текущiй 2026 годъ будутъ разработаны ИИ-системы, работа съ которыми станетъ рутинной. Изъ забавныхъ и не очень-то надежныхъ игрушекъ эти системы станутъ рабочими инструментами съ извѣстными характеристиками.

У меня сложилась такая метафора: модель ИИ подобна скаковой лошади, выступающей на скачкахъ. Мы не знаемъ, почему скакунъ иногда выигрываетъ раундъ, а иногда проигрываетъ. Мы дѣлаемъ ставки и надѣемся выиграть. Скаковыхъ лошадей мы не конструируемъ, какъ машины - мы ихъ выращиваемъ, т.е. конечно мы слѣдимъ за родословной, но этого мало, мы заботимся о нихъ, воспитываемъ, тренируемъ, въ надѣждѣ получить результатъ. Потомъ скакуны выходятъ на соревнованiе и только тогда становится видно, чего они стоятъ.

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

Исходно лошадь - не инструментъ, ее нельзя "правильно использовать". Чтобы превратить лошадь въ инструментъ, мы ее взнуздываемъ, спереди надѣваемъ шоры, сзади вѣшаемъ мешокъ для навоза, и вообще строго ограничиваемъ всѣ движенiя. Долго тренируемъ въ такомъ режимѣ. И тогда лошадь становится почти надежной машиной для передвиженiя.

Примѣрно это предстоитъ продѣлать съ ИИ-моделями, чтобы ими стало можно пользоваться какъ инструментами въ обычномъ смыслѣ этого понятiя.

[myron_opanasovych]

На претрейне кодерским способностям БЯМ учат в основном так же, как и языку — массивами исходного кода (GitHub и подобное), причём код там обычно перемешан с обсуждениями (Stack Overflow, документация, issue-трекеры), так что модель видит связку проблема -> решение -> объяснение. Но главный "секрет" современных кодерских способностей не в претрейне, а в постренинге с обратной связью от исполнения: модель ставят в цикл, где она получает задачу, пишет код, код реально запускается в песочнице, результат или ошибка возвращается обратно, она правит — и весь этот процесс служит обучающим сигналом. То есть её натаскивают не в режиме "напиши код за один заход", а в режиме "пиши, запускай, отлаживай, итерируй пока не пройдуйт все тесты".

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

Решение — агентные инструменты, специально под это сделанные (Claude Code, OpenCode, Gemini CLI и подобные). Это CLI-программы, которые дают модели прямой доступ к файловой системе и шеллу. Цикл становится такой: вы говорите "сделай скрипт перевода markdown в html по такому-то формату, вот пример входа и ожидаемого выхода", агент сам создаёт файл, сам запускает на тестах, сам видит ошибку, сам правит, перезапускает до готовности (или исчерпания лимитов токенов). Вы в этом цикле почти не участвуете, только направляете. На задаче вроде вашего конвертера такой агент управился бы за один заход без всяких ресетов — это будет совсем другой опыт, та самая модель в режиме, для которого её, собственно, и натаскивали.

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

1. Єкспортируете все ваши диалоги с БЯМ

2. Устанавливаете Gemini CLI (но я бы таки рекомендовал вендор-агностик opencode)

3. Просите CLI запроцесить ваши диалоги с БЯМ и предложить, каких бы агентов вы могли создать специально под вас и ваши методы допросов БЯМ.

4. Апрувите/правите описание тех агентов, функционал которых вам подходит.

5. Переходите не следующий уровень взаимодействия с кремнием.

[crdigger]

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

[sobriquet9]

Для программирования лучше пользоваться моделями через специализированный текстовый интерфейс (TUI) вроде Gemini CLI или Claude Code. Вместо того, чтобы писать весь код сразу прямо из LLM, они пишут его по кусочкам, которые запускают и отлаживают на компьютере пользователя. Чтоб при исправлении одних ошибок не вносить другие, не переписывают всё, а редактируют предыдущую версию с помощью отдельных команд ("заменить foo на bar").

[xaxam]

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

[sobriquet9]

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

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

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

[chasovschik]

Грубо говоря, может ли существовать мыслящая цивилизация, не пользующаяся речью?

А вот цивилизация, которая речью пользуется, но ни хрена при этом не мыслит, существует запросто.