> 🎤 Алекс, Амин, Дэн (Команда OpenAI) — Команда ведущих экспертов OpenAI (Alex, Amin, Dan), отвечающих за инфраструктуру и исследования при создании моделей уровня GPT-4.5.

⚡ Зачем читать эту методичку
Узнаете, как управлять рисками при обучении моделей на 100 000+ GPU, где любая микроошибка становится системной катастрофой.
Освоите методологию co-design (совместного проектирования), позволяющую синхронизировать ML-алгоритмы и «железо» еще до старта обучения.
Перейдете от стратегии «больше compute» к стратегии «алгоритмическая эффективность», чтобы извлекать максимум из доступных данных.

🗺 Карта навыков
| Уровень | Навык | Описание |
| :--- | :--- | :--- |
| Базовый | Отказоустойчивость | Проектирование системы, способной работать в условиях постоянных аппаратных сбоев. |
| Средний | Co-design | Синхронная разработка ML-стека и сетевой инфраструктуры. |
| Продвинутый | Оценка generalization | Использование закрытых репозиториев для исключения «дегенеративного запоминания». |
| Экспертный | Data Efficiency | Переход к алгоритмам, оптимизирующим извлечение инсайтов из ограниченных датасетов. |

1. Проектирование отказоустойчивости при масштабировании

В современной парадигме обучения нейросетей уровня GPT-4.5, масштабирование с 10 000 до 100 000 GPU — это не просто линейное увеличение мощностей, а переход в принципиально иную зону турбулентности. Спикеры (Алекс, Амин, Дэн) подчеркивают: то, что на малом кластере выглядит как редкий «шум» или незначительный сбой, при работе на 100 000 ускорителях превращается в катастрофический блок, останавливающий весь процесс. Главная задача системного архитектора здесь — перестать относиться к сбоям как к исключительным событиям. Ошибки — это часть жизни модели. Ваша архитектура должна быть «иммунной» к ним.

В видео приводится пример с отладкой . Команда долгое время сталкивалась с проблемами «битых» вычислений, которые возникали лишь при определенных комбинациях данных. Симптомы выглядели хаотично: случайные сегфолты, ошибки памяти, разрывы соединений. Инженеры OpenAI тратили недели, пытаясь отделить шум от реальных багов инфраструктуры. Оказалось, что проблема крылась в редком кейсе реализации операции внутри PyTorch, который при обычном тестировании не проявлялся. Этот пример учит нас, что при масштабировании «диагностика — это критический путь». Если вы не автоматизировали систему мониторинга, позволяющую отличать hardware-fault от ML-ошибки, вы проиграете гонку еще до старта.

При масштабировании симметрия системы становится вашим лучшим союзником. Если один узел в сети отстает, вся параллельная цепочка простаивает. Амин отмечает, что «красота системы в том, что почти все должно работать идеально, чтобы результат имел смысл». Поэтому проектирование должно включать автоматическое восстановление состояний (checkpointing) и механизмы быстрой изоляции «больного» узла без остановки всего обучения.

> «Проблема в том, что когда вы работаете на 100 000 GPU, редкие ошибки становятся катастрофическими. Вы должны спроектировать инфраструктуру так, чтобы она была симметричной и предсказуемой, минимизируя variance в производительности, иначе один медленный узел уничтожит всю эффективность вашего обучения». — Амин, Главный системный архитектор.

✅ Сделайте сейчас: Проведите аудит текущей инфраструктуры обучения. Составьте список «редких ошибок» (которые случаются раз в неделю или реже). Для каждой из них напишите алгоритм автоматического восстановления: как система должна диагностировать сбой и как она должна вернуться к работе без ручного вмешательства инженера. Попробуйте внедрить хотя бы одну проверку, которая автоматически исключает из кластера узел, работающий на 10% медленнее среднего.

2. Принцип совместного проектирования (co-design)

Одной из ключевых тем видео является крах концепции «разделил и властвуй». Ранее ML-команды могли написать код модели, а системные администраторы — выделить под него серверы. Для моделей типа GPT-4.5 этот подход фатален. Команда OpenAI настаивает на методологии co-design: архитекторы систем и ML-исследователи должны работать над spec-файлами модели совместно за 6–9 месяцев до запуска основного трейна. Это позволяет адаптировать топологию сети под конкретные паттерны доступа к памяти и минимизировать узкие места (bottlenecks) в пропускной способности.

Дэн приводит пример: обучение GPT-4.5 потребовало изменения стратегии управления состоянием (state management), что заставило команду перейти на мультикластерное обучение. Если бы ML-инженеры не знали ограничений сети на этапе написания алгоритма, они бы создали код, который просто «захлебнулся» бы при попытке синхронизации между кластерами. Co-design здесь — это не просто совещания, это подстройка формы тензоров и паттернов коммуникации под реальную архитектуру железа. Это требует глубокого взаимопонимания: ML-специалист должен понимать, как именно работает InfiniBand, а системщик — понимать, почему конкретная операция в модели требует столько памяти.

В видео обсуждается, что работа над моделью не прекращается после запуска «Go». Многие оптимизации внедрялись прямо в процессе обучения. Это рискованная, но необходимая стратегия в условиях ограниченного времени. «Мы параллелизировали работу агрессивно, с твердой убежденностью, что если мы пройдем этот performance cliff (обрыв производительности), модель станет тренируемой», — говорит Амин. Это требует культуры, где нет границ между «моя задача» и «твоя задача». Команда стала единым организмом, работающим на общую метрику.

> «Совместное проектирование (co-design) — это не просто объединение усилий. Это фундаментальный подход, при котором вы стерите систему так, чтобы нужные вам свойства (например, скорость передачи данных или доступность памяти) не возникали случайно, а гарантированно обеспечивались самой архитектурой обучения. Без этого подхода вы всегда будете опаздывать за прогрессом железа». — Команда OpenAI.

✅ Сделайте сейчас: Организуйте кросс-функциональное ревью текущего проекта, где ML-разработчики и DevOps/Network-инженеры поменяются ролями на 1 час. Пусть ML-инженер объяснит, как данные «текут» через слои модели, а системный инженер покажет, где в сети возникают задержки при этом потоке. Найдите одно место, где изменение формы данных (например, размера батча) может снизить нагрузку на сеть на 10% без ущерба для качества модели.

---

3. Де-рискинг через итеративные запуски

В процессе подготовки к запуску модели уровня GPT-4.5, команда OpenAI столкнулась с тем, что «прыжок» в масштабах (например, переход от 10 000 до 100 000 GPU) не прощает ошибок планирования. Алекс и Амин подчеркивают, что стратегия «одного большого релиза» — это путь к катастрофе. Вместо этого применяется методология итеративного де-рискинга (снижения рисков). Это процесс последовательного усложнения конфигурации обучения, где каждый этап — это «прогон» модели, подтверждающий состоятельность архитектурных решений. Использование промежуточных запусков позволяет команде видеть, как ведут себя гиперпараметры и сетевые протоколы при изменении топологии, не дожидаясь финала многомесячного обучения.

В видео приводится пример, когда команда за 6–9 месяцев до основного «Go» проводила серию крупномасштабных тестов. Эти запуски не были попыткой обучить готовую модель; это была проверка «здоровья» инфраструктуры. Команда начинала с проверенной конфигурации (GPT-4), постепенно «наслаивая» на неё новые компоненты системы. Такая тактика позволила обнаружить потенциальные «performance cliffs» — моменты резкого падения производительности, которые могли бы сделать финальную модель фактически нетренируемой. Если бы архитекторы просто доверились теоретическим расчетам, они бы неизбежно столкнулись с этими «обрывами» на этапе обучения GPT-4.5, потеряв месяцы времени и миллионы долларов на compute.

Важным элементом итеративного подхода является «культура паранойи», о которой говорит Алекс. Инженеры не просто мониторят Loss (функцию потерь), они следят за тем, чтобы каждый выигрыш в эффективности, полученный на малых данных, масштабировался линейно. Часто бывает так, что оптимизация, которая выглядит блестяще на 100 GPU, теряет всякий смысл при переходе на 10 000. Постоянная валидация гипотез через микро-запуски позволяет «отсечь» ложные оптимизации еще до того, как они станут частью основного кода обучения.

> «Многие вещи выглядят хорошо на малом масштабе, но совершенно не работают при переходе к гигантским кластерам. Мы были параноидально осторожны: не просто искали win от новых фич, а проверяли, чтобы этот выигрыш сохранялся и не затухал при масштабировании. Это была наша основная методика снижения рисков». — Алекс, Лидер направления пред-обучения.

✅ Сделайте сейчас: Разбейте ваш план проекта на «микро-задачи» по масштабированию. Вместо того чтобы планировать один большой релиз, выделите 3 контрольные точки, где вы будете проводить нагрузочное тестирование на критических компонентах. Для каждой точки сформулируйте гипотезу (например: «при увеличении батча на 20% сеть выдержит нагрузку без роста latency»). Если гипотеза не подтверждается на малом масштабе — не двигайтесь дальше, пока не оптимизируете код под эти условия.

4. Переход к Data Efficiency: качество важнее объема

Дэн, эксперт по эффективности данных, поднимает фундаментальный вопрос: стоит ли нам бесконечно наращивать compute? До недавнего времени вся индустрия жила в парадигме «compute-constrained», где единственным путем к успеху было увеличение количества GPU. Однако, начиная с GPT-4.5, стало очевидно, что данные становятся узким местом. Мы входим в эру, где алгоритмическая эффективность — способность извлекать больше знаний из того же объема данных — становится более ценным ресурсом, чем доступ к дополнительным вычислительным мощностям.

В видео обсуждается, что GPT-трансформеры великолепно поглощают информацию, но их способность к «глубокому инсайту» имеет потолок. Стандартный метод «собрать весь интернет и скормить его модели» начинает давать убывающую отдачу. Инновация здесь кроется в переходе к алгоритмам, которые позволяют тратить вычислительные ресурсы не на простое перечитывание данных, а на более глубокое их понимание. Дэн сравнивает это с обучением человека: мы не читаем терабайты текстов ежедневно, но извлекаем из прочитанного сложные аналогии, абстракции и логические связи. Современные методы обучения должны имитировать этот процесс компрессии, превращая «сырые» данные в сжатые, высококачественные знания.

Проблема «дегенеративного запоминания» — еще один важный аспект этой темы. Если при оценке модели использовать данные, которые хоть как-то пересекаются с обучающей выборкой, метрики будут искусственно завышены. Команда OpenAI делает упор на использование «закрытых репозиториев» и специфических внутренних бенчмарков, которые гарантированно отсутствуют в интернете. Это позволяет оценить реальную способность модели к обобщению (generalization), а не просто её умение «цитировать» выученные фрагменты кода или текстов. Оценка модели — это не только математика, но и дисциплина исключения «знакомых» данных из процесса валидации.

Как отмечают эксперты, мы находимся на пороге смены парадигмы. Если раньше мы оптимизировали «железо» под данные, то теперь мы начинаем оптимизировать «алгоритмы» под их информационную плотность. Это требует глубокой научной работы: нужно понимать, какие именно паттерны в данных являются «ценными» (long tail), а какие — просто шумом. В будущем победят те системы, которые смогут извлекать «хвост» распределения знаний, то есть редкие, но критически важные концепции, которые сейчас теряются в огромном массиве неструктурированного контента. Это путь от экстенсивного роста к интенсивному развитию нейросетей.

---

5. Культура преодоления неопределенности: работа с аппаратными «шумами»

В процессе обучения моделей масштаба GPT-4.5 инженерная группа неизбежно сталкивается с тем, что идеальная теоретическая модель обучения сталкивается с хаосом «железа». Алекс и Амин подчеркивают: запуск гигантской системы — это не акт программирования, а акт управления энтропией. На 100 000 GPU вероятность того, что в какой-то момент времени всё оборудование будет работать идеально, практически равна нулю. В видео звучит ключевая мысль: необходимо отказаться от иллюзии «чистого» запуска. Команда OpenAI разработала систему мониторинга, которая не просто фиксирует сбои, но позволяет проводить глубокую диагностику «на лету», отделяя критические ошибки (которые требуют остановки обучения) от аппаратного шума или редких ошибок вычислений, которые можно игнорировать или исправить локально.

Один из самых ярких примеров — это история с «багом в torch.sum». Инженеры долгое время наблюдали аномалии в работе сети, которые имели разные симптомы. Вместо того чтобы паниковать и останавливать процесс (что стоило бы огромных денег), команда организовала «голосование»: каждый инженер предлагал свою версию причины. В итоге, наиболее вероятная версия оказалась ложной, а истинной причиной стал редкий баг в реализации операции суммирования, который проявлялся только при специфическом распределении данных. Это учит нас тому, что в условиях масштаба человеческая интуиция должна дополняться строгой методологией анализа логов. Культура «отладки во время бега» требует от инженеров не только знаний в архитектуре нейросетей, но и навыков системного администрирования уровня ядра.

Более того, понимание того, что модель «продолжает учиться», несмотря на технические сбои, меняет философию управления проектом. Алекс отмечает, что моральный дух команды напрямую зависит от того, как интерпретируются данные. Если инженеры видят в каждой ошибке «катастрофу», они выгорают. Если они видят в них «информацию о поведении системы», они становятся исследователями. Это разделение шума от сигнала — навык №1 для современного ML-лидера. Вы должны создать инфраструктуру, которая дает вам «видимость» (visibility) того, что происходит в глубинах тензорных вычислений, чтобы не гадать, а принимать решения на основе фактов.

> «Мы привыкли к тому, что обучение никогда не бывает идеальным. Мы научились отличать критические аппаратные сбои от мелких артефактов вычислений, которые не мешают модели расти. В этом и заключается суть управления масштабными проектами: понимание того, когда нужно вмешаться, а когда позволить системе самоисцелиться». — Амин, Главный системный архитектор.

✅ Сделайте сейчас: Проведите аудит системы мониторинга вашего проекта. Ответьте на вопрос: «Есть ли у нас четкий регламент действий при возникновении аномалии, или мы каждый раз принимаем решение в панике?». Создайте «книгу инцидентов», где зафиксируйте типовые «шумы» (например, временные сетевые задержки, микро-отказы GPU) и алгоритм их игнорирования. Это избавит команду от лишнего стресса и сэкономит сотни часов работы.

6. Принцип «Generalization over Memorization»: защита целостности метрик

В мире, где интернет-данные становятся товаром, ценность модели определяется не тем, сколько текстов она «прочитала», а тем, насколько глубоко она овладела искусством абстракции. Дэн в видео приводит фундаментальный аргумент: если мы будем оценивать модель на тестах, которые присутствуют в обучающей выборке, мы получим иллюзию прогресса. Это то, что он называет «дегенеративным запоминанием». Чтобы избежать этой ловушки, OpenAI использует закрытые репозитории и специфические внутренние бенчмарки, к которым модель не имела доступа во время обучения. Это единственный способ проверить, действительно ли нейросеть «понимает» концепции или просто мастерски «цитирует» куски кода и статей из своей памяти.

Для системных архитекторов этот принцип означает необходимость проектирования процессов валидации, которые исключают «утечку данных» (data leakage). Представьте ситуацию: вы оптимизируете модель под метрику, которая оказывается «загрязненной». Вы тратите миллионы долларов на compute, добиваетесь роста показателей на 15%, но в реальных условиях модель демонстрирует нулевой прирост полезности для пользователя. Это худший кошмар ML-инженера. Команда OpenAI делает ставку на «чистоту» данных: они не просто скачивают весь интернет, они фильтруют и отбирают те паттерны, которые способствуют развитию логических связей и аналогий, а не простому накоплению фактов. Обучение модели — это не про объём, а про качество сжатия информации (compression).

Важный вывод для бизнеса: если вы хотите, чтобы модель работала в условиях неопределенности, она должна учиться на «хвостах» распределения (long tail). Редкие, сложные концепции в данных — это и есть ключ к интеллекту. Если модель постоянно видит одни и те же простые примеры, она становится «ленивой». В будущем победят те компании, которые смогут создавать «синтетические» или «высококачественные» датасеты, способные заставить модель думать, а не просто угадывать следующий токен. Это переход от количественного накопления знаний к качественному развитию мышления системы. Валидация должна быть «параноидальной»: если результаты теста выглядят слишком хорошо, значит, скорее всего, модель уже видела эти данные.

> «Многие пытаются измерить интеллект модели через стандартные тесты, которые есть в открытом доступе. Но если данные есть в интернете, они уже стали частью обучающей выборки. Реальная проверка модели — это работа с закрытыми, внутренними наборами данных, которые требуют от системы именно обобщения (generalization), а не простого воспроизведения выученного текста». — Дэн, эксперт по эффективности данных.

✅ Сделайте сейчас: Разработайте «золотой набор» тестов (Golden Set) для вашего ML-продукта, который гарантированно не входит в обучающую выборку. Включите туда задачи, требующие логического вывода (reasoning), а не простого поиска информации. Каждый раз, когда вы вносите изменения в архитектуру или данные, прогоняйте модель через этот тест. Если метрики на Golden Set не растут, значит, ваши изменения лишь увеличивают способность модели «зубрить», а не «понимать».

---

7. Ко-дизайн как стратегия выживания: синергия ML и системной архитектуры

В современной разработке моделей класса GPT-4.5 «стены» между ML-инженерами и системными архитекторами превращаются в узкое горлышко, которое убивает проект еще до его запуска. Дэн, Алекс и Амин подчеркивают: процесс проектирования гигантских нейросетей — это не последовательная передача задач от «софта» к «железу», а глубоко интегрированный процесс со-проектирования (co-design). На практике это означает, что выбор архитектуры модели, форма тензоров, методы шардирования и стратегии кэширования должны диктоваться не только теоретическими соображениями о сходимости градиента, но и тем, как данные физически «бегают» по оптическим кабелям между 100 000 GPU. Игнорирование этого факта ведет к тому, что вы строите сверхмощный двигатель, который невозможно установить в шасси из-за несовместимости креплений.

Ко-дизайн требует смены мышления: вы больше не просто «пишете код», вы «настраиваете физическую среду» для вычислений. Когда OpenAI готовилась к запуску, команда потратила месяцы на то, чтобы синхронизировать уровни абстракции — от высокоуровневых слоев трансформера до низкоуровневых ядер Triton. Ошибка в одной из этих точек может привести к потере 30-40% пропускной способности сети из-за простых задержек (latency). Амин отмечает, что идеальная система должна быть «симметричной и сбалансированной», но в реальности мы всегда идем на компромисс. Суть мастерства системного архитектора — в умении предсказать, где именно произойдет перекос нагрузки, и заранее подготовить «обходные пути» (workarounds), которые не потребуют переписывания всей кодовой базы в процессе обучения.

Этот подход радикально меняет культуру команды. Инженеры перестают мыслить границами своих ролей («это сетевая проблема», «это проблема весов») и начинают смотреть на систему как на единый живой организм. Если модель работает медленнее, чем ожидалось, ML-инженер не просто «ужимает» батч, он вместе с системным архитектором изучает трассировку памяти. Это требует от специалистов навыков «системного администрирования уровня ядра» (kernel-level proficiency). Вы должны понимать, как распределяются прерывания, как работает планировщик задач в ОС и как именно данные извлекаются из памяти GPU. Это путь от «программирования моделей» к «программированию инфраструктуры обучения». Только такая синергия позволяет делать скачки на порядок (10х) в масштабах обучения, не захлебываясь в хаосе собственных технических долгов.

> «Ко-дизайн — это когда архитектура модели и архитектура системы не просто сосуществуют, а диктуют друг другу свои условия. Мы не можем оптимизировать только ML или только железо; мы должны создавать систему, где каждое изменение в формуле функции потерь мгновенно учитывает ограничения пропускной способности сети». — Алекс, Lead ML Engineer.

✅ Сделайте сейчас: Проведите «кросс-функциональный штурм» вашего проекта. Соберите ML-команду и DevOps/Infrastructure инженеров в одной комнате. Пусть каждый опишет одну вещь, которую он «ненавидит» в работе коллег (например, «они шлют слишком много мелких запросов» или «они постоянно меняют конфигурацию кластера»). На основе этого составьте документ «Протокол взаимодействия», который формализует ограничения для обеих сторон: ML-команда получает бюджет на ресурсы, а системная команда получает предсказуемый профиль нагрузки.

8. Экономика данных: искусство сжатия как путь к интеллекту

В эпоху, когда «собрать весь интернет» больше не дает конкурентного преимущества, фокус смещается на алгоритмическую эффективность. Дэн из OpenAI утверждает, что мы переходим из эпохи «compute-constrained» (ограниченность мощностями) в эпоху «data-constrained» (ограниченность качеством данных). Если раньше успех измерялся объемом терафлопс, то сегодня он измеряется способностью модели сжимать информацию. Чем выше коэффициент сжатия при обучении, тем умнее модель. Это прямое следствие принципа Соломоновой индукции: интеллект — это поиск простейшего алгоритма (программы), который объясняет наблюдаемые данные. Нейросеть, которая «понимает» концепцию, сжимает её в веса гораздо эффективнее, чем та, которая просто «запоминает» (memorization) примеры.

Проблема «дегенеративного запоминания» — это главный враг развития. Если вы тренируете модель на данных, которые пересекаются с вашими же тестами, вы получаете «искусственно поумневшую» систему. Она не рассуждает, она «цитирует». Для бизнеса это катастрофа: модель выглядит впечатляюще на демо, но в реальных условиях, где возникают новые, не встречавшиеся ранее задачи, она теряется. Поэтому использование «закрытых репозиториев» — это не просто паранойя, это требование научной строгости. Вы должны оценивать модель не по тому, как хорошо она отвечает на вопросы из FAQ, а по тому, как она решает новые, сложные, синтетические задачи, которые она физически не могла видеть во время обучения.

Будущее за теми, кто научится извлекать «хвост» распределения (long tail). Редкие, сложные, глубоко логические паттерны — это «золотая жила» для развития интеллекта. Массовый контент из интернета — это шум, который помогает модели «выучить язык», но не помогает ей «научиться мыслить». Оптимизация под «информационную плотность» данных требует от нас создания систем, которые не просто читают, а фильтруют и классифицируют знания. Это переход от экстенсивного накопления к интенсивному развитию нейросетей. Понимание того, что данные — это не просто объем, а инструмент для сжатия знаний, позволяет нам строить модели, которые требуют меньше compute для достижения тех же (или лучших) результатов. Мы должны перестать «скармливать» моделям всё подряд и начать «дирижировать» их обучением через качественные датасеты.

> «Интеллект модели определяется качеством её сжатия. Если модель просто запоминает данные, она не прогрессирует. Настоящий интеллект рождается в момент, когда модель находит аналогии и абстракции, которые позволяют описывать огромные массивы информации через предельно сжатые логические структуры». — Дэн, специалист по эффективности алгоритмов.

✅ Сделайте сейчас: Проведите аудит вашего текущего датасета. Найдите 10% «самых сложных» примеров, где модель чаще всего ошибается, и классифицируйте их: это нехватка данных или нехватка «рассуждения» (reasoning)? Создайте мини-датасет из 100 «золотых» примеров, которые требуют глубокой логики, и используйте их как «лакмусовую бумажку» для любой новой версии вашей модели. Если модель не справляется с этим тестом, не выпускайте обновление, даже если общая точность растет.

🏋️ Практикум

1. Анализ инцидента: Опишите последний сбой в вашем продукте. Разделите причины на «аппаратный шум» и «архитектурный баг». Обоснуйте, почему это нельзя было предотвратить.
2. Дизайн бенчмарка: Создайте структуру «Golden Set» для вашей задачи. Какие 5 типов «невидимых» для модели задач помогут проверить уровень её интеллекта?
3. Карта «узких мест»: Нарисуйте архитектурную схему вашего обучения и отметьте точки, где чаще всего происходят сетевые задержки. Предложите 2 способа их минимизации через изменение конфигурации.
4. Оценка compression: Как вы будете измерять «качество сжатия» знаний в вашей модели? Предложите метрику (отличную от стандартного accuracy), которая отражает глубину понимания связей.
5. Культурный аудит: Напишите список из 3 правил, которые помогут вашей команде перестать паниковать при сбоях и начать «читать логи» как исследователи.

🔑 Итоги: 5 действий на сегодня

1. Внедрить «книгу инцидентов» для фиксации аномалий и их классификации.
2. Отделить «открытые» тесты от «закрытого» Golden Set.
3. Провести встречу по ко-дизайну: ML-инженеры + системные архитекторы.
4. Заменить метрику «общего объема данных» на метрику «информационной плотности».
5. Установить запрет на оптимизацию модели под открытые бенчмарки (исключить утечку данных).

💬 Цитаты для вдохновения

«Запуск гигантской системы — это не программирование, это управление энтропией». — Амин
«Если вы хотите, чтобы модель мыслила, перестаньте кормить её фактами и начните учить её сжимать знания». — Дэн
«Масштабирование — это процесс преодоления собственных страхов перед неопределенностью». — Алекс
«Настоящий прогресс — это когда модель делает то, что вы не предсказывали, но что логически вытекает из её внутреннего понимания мира». — Дэн
«Система, которая не падает — это система, которая не расширяет свои границы». — Амин