Джек Дорси создал локального ИИ-агента Goose и передал проект в Linux Foundation.

Сейчас у проекта:

• 46,4 тыс. звёзд на GitHub
• 518 контрибьюторов
• 137 релизов
• обновления выходят до сих пор

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

Что есть из коробки:

Нативное десктопное приложение, CLI и API — можно выбрать любой способ работы
Поддерживает любые LLM: Claude, GPT, Gemini, DeepSeek, Ollama и ещё более 15 моделей
Работает с уже существующими подписками — не нужно отдельно платить за новые API
Более 70 MCP-расширений: GitHub, Google Drive, базы данных, браузер и многое другое
Параллельные субагенты — разбивает сложные задачи на части и выполняет их одновременно
Recipes — позволяет сохранять workflow в YAML и делиться ими с командой
Встроенный режим adversary — ревьюер, который выявляет prompt injection и потенциально опасные действия
Совместим с Claude Code и Codex в качестве провайдеров через ACP
Написан на Rust. Поддерживает macOS, Linux и Windows. Лицензия Apache 2.0

Самая любопытная часть — Goose может использовать Claude Code или Codex как субагентов.

Goose координирует работу, а они выполняют задачи.

https://github.com/aaif-goose/goose

👉 @DataSciencegx

Как AI Engineer, изучайте:

- Инженерию агентных рантаймов (agent harness engineering), а не только промпт-инжиниринг
- Контекстную инженерию (context engineering), а не только длинные промпты
- Компромиссы между prompt caching и semantic caching
- Управление KV-кэшем: вытеснение, повторное использование и давление на память при масштабировании
- Разницу между задержкой на prefill и decode, и почему они требуют разных подходов к оптимизации
- Continuous batching, paged attention и повышение пропускной способности (throughput)
- Компромиссы между speculative decoding, квантизацией и дистилляцией
- INT8, INT4, FP8, AWQ, GPTQ и случаи, когда квантизация ухудшает качество
- Сбои структурированного вывода, валидацию схем, циклы исправления (repair loops) и цепочки резервных сценариев (fallback chains)
- Надёжность function calling, контракты инструментов (tool contracts), валидацию аргументов и идемпотентность
- Ограничители для агентов (guardrails), лимиты циклов, лимиты использования инструментов и условия завершения работы
- Маршрутизацию моделей (model routing), логику плавного переключения на резервные сценарии (graceful fallback) и UX в деградированном режиме
- Архитектуру RAG: чанкинг, эмбеддинги, гибридный поиск, реранжирование и актуальность данных
- Оценку качества поиска (retrieval evals): полноту (recall), точность (precision), grounding, attribution и качество цитирования
Evals: эталонные наборы данных (golden sets), регрессионные тесты, adversarial-тесты, LLM-as-a-judge и ручную оценку
- Наблюдаемость LLM-систем (LLM observability) как полноценную инженерную дисциплину: трассировки, спаны, токены, задержки, ошибки и дрейф
- Атрибуцию затрат по функциям, workflow, арендаторам (tenants) и пользовательским сценариям, а не только по моделям
- Инженерию безопасности: защиту от prompt injection, предотвращение утечек данных и разграничение прав доступа
- Изоляцию арендаторов (multi-tenant isolation), безопасность кэшей и предотвращение загрязнения контекста между пользователями
- Fine-tuning, in-context learning, RAG и дистилляцию, а также случаи, когда каждый из этих подходов оказывается неподходящим инструментом
- Компромиссы между задержкой, качеством, стоимостью и надёжностью по всей цепочке инференса
- Типичные сбои в продакшене: галлюцинированные вызовы инструментов, некорректный JSON, устаревшие данные из поиска, зациклившиеся агенты и незаметные регрессии в evals

👉 @DataSciencegx

Вышла новая работа о том, как ИИ-агенты меняют интеллектуальный труд.

Редкий случай, когда обсуждают не модели и бенчмарки, а то, как меняется сама работа людей.

Авторы рассматривают внедрение агентов через 3 параметра:

• уровень автономности
• рост эффективности
• объём задач, которые сотрудники готовы делегировать агентам

Интересный вывод: главный барьер для внедрения агентов часто связан не с качеством моделей.

Большинство людей просто никогда не учили работать с агентными системами.

Статья: https://arxiv.org/abs/2606.07489

👉 @DataSciencegx

Вышел Memento-Skills. И это агентный фреймворк, в котором агенты учатся на собственных ошибках и переписывают свои скиллс самостоятельно.

Большинство агентных систем используют статические скиллы. Тоесть написал один раз, загрузил в контекст и надеешься, что всё сработает. Если скилл ломается — исправлять приходится вручную.

Memento-Skills работает иначе. Если скилл не справляется с задачей, система анализирует причину сбоя, находит проблемный скилл, переписывает его и сохраняет улучшенную версию обратно в библиотеку.

Цикл работы выглядит так:

→ Read — выбирает нужные скиллы из локальной библиотеки
→ Execute — выполняет их в песочнице с доступом к инструментам
→ Reflect — анализирует ошибки и определяет, какой скилл подвёл
→ Write — улучшает существующие скиллс или создаёт новые

По сути, это агентная система, которая постепенно улучшает собственную библиотеку навыков на основе накопленного опыта.

Проект протестировали на бенчмарках HLE (Humanity's Last Exam) и GAIA. По мере роста библиотеки навыков результаты улучшались от раунда к раунду.

Поддерживает Kimi, MiniMax, GLM и другие OpenAI-совместимые API.

В комплекте уже есть 9 базовых скиллов: работа с файлами, веб-поиск, PDF, DOCX, XLSX, PPTX, анализ изображений, создание навыков и установка зависимостей.

Исходный код полностью открыт. 🔥

👉 @DataSciencegx

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

Claude Code Thinking Skills — это библиотека из 39 ментальных моделей и фреймворков критического мышления для пользователей Claude Code, которым нужен более структурированный подход к рассуждениям

Она помогает разбирать сложные задачи через навык thinking-model-router, который подбирает подходящую модель мышления под тип проблемы, вместо того чтобы полагаться на случайные промпты.

Что входит:
• 39 моделей мышления — включая First Principles, Bayesian Reasoning, Systems Thinking, OODA, Pre-Mortem, TRIZ и другие.
• Точка входа через Router — определяет домен и тип задачи, после чего предлагает наиболее подходящий фреймворк.
• Нативная интеграция с Claude Code — каждая модель упакована как отдельный Claude Code Skill, который можно вызвать по имени.
• Установка через плагины — в README есть инструкции по установке через маркетплейс Claude Code и ручному копированию.
• Прозрачная система оценки — проект публикует результаты тестирования и репликации, включая текущий результат: «ноль устойчиво воспроизведённых вердиктов ELEVATE».

Проект распространяется с открытым исходным кодом по лицензии MIT.

https://github.com/tjboudreaux/cc-thinking-skills

👉 @DataSciencegx

большая подборка материалов по LLM Systems,

• обучение моделей (pre-training, RLHF, fault tolerance, stragglers)
• инференс и serving
• агентные системы
• edge deployment
• мультимодальные модели
• технические отчёты от крупных лабораторий
• обзоры, бенчмарки и лидерборды
• курсы по MLSys и подборки статей с конференций

https://github.com/AmberLJC/LLMSys-PaperList

👉 @DataSciencegx

PixelRAG предлагает довольно простую идею: отказаться от HTML-парсинга в web RAG.

Большинство RAG-систем работают так:

→ HTML
→ Извлечение текста
→ Чанкинг
→ Ретривер
→ LLM

PixelRAG использует другой подход:

→ Рендер страницы
→ Скриншоты (тайлы)
→ Визуальный ретривер
→ VLM читает изображение страницы

Авторы утверждают, что HTML-to-text преобразование часто теряет полезную информацию: структуру страницы, таблицы, инфобоксы и другие визуальные элементы.

Для экспериментов был построен визуальный индекс из более чем 30 млн скриншотов веб-страниц Википедии.

Обучение ретривера полностью автоматизировано. Для генерации обучающих данных используются веб-страницы, LLM-сгенерированные поисковые запросы и автоматически подобранные негативные примеры. Ручная разметка не использовалась.

Для дообучения применялась LoRA к VLM и ViT-энкодеру. По словам авторов, обучение заняло около трёх часов на одной H100.

В статье PixelRAG превосходит лучший текстовый бейзлайн на всех использованных бенчмарках:

• SimpleQA — 78.8% (+7.1)
• NQ-Tables — 48.8% (+6.3)
• EVQA — 45.1% (+15.5)
• LiveVQA — 70.3% (+11.3)

Авторы отдельно отмечают, что улучшения наблюдаются не только на визуальных задачах, но и на бенчмарках, которые обычно относят к текстовым.

Также PixelRAG был интегрирован в ReAct-агента и протестирован на MoNaCo. В статье сообщается, что система показала более высокую точность ответов, чем Google Search и DS-Serve, при меньших затратах на инференс.

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

Код проекта опубликован в открытом доступе, а в статье есть подробные разборы ошибок, абляционные исследования и сравнение более чем с 25 VLM-моделями.

👉 @DataSciencegx

Исследователи показали способ ускорить генерацию LLM до 8,5 раза без потери качества.

Речь идёт о новом методе под названием DFlash, который развивает идею speculative decoding.

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

Speculative decoding частично решает эту проблему.

Сначала небольшая draft-модель предлагает несколько следующих токенов, после чего большая модель проверяет их за один проход.

Если где-то обнаруживается ошибка, все токены до неё сохраняются, а генерация продолжается с этого места. Качество остаётся таким же, как при обычном декодировании.

Но у подхода есть ограничение.

Даже draft-модели обычно генерируют токены последовательно, по одному за раз. В результате сам этап черновой генерации становится новым узким местом, и ускорение на практике редко превышает 2–3 раза.

DFlash заменяет авторегрессионную draft-модель на лёгкую diffusion-модель, которая генерирует сразу весь блок токенов параллельно.

Получается следующая схема:

Обычный speculative decoding:

→ Draft-модель предсказывает токены по одному
→ Основная модель проверяет результат

DFlash:

→ Diffusion-драфтер генерирует весь блок сразу
→ Основная модель проверяет результат

Стоимость черновой генерации при этом практически не зависит от количества предполагаемых токенов.

Дополнительно драфтер получает скрытые представления из нескольких слоёв основной модели. Эти признаки передаются во все слои драфтера, что помогает ему делать более точные предсказания.

По данным авторов, в демонстрации:

• Обычный декодинг — 48,5 токена/сек
• DFlash — 415 токенов/сек

При этом качество генерации не ухудшается.

Технология уже интегрирована в:

• vLLM
• SGLang
• Transformers

Также опубликованы готовые draft-модели для:

• Qwen3
• Qwen3.5
• Llama 3.1
• Kimi-K2.5
• gpt-oss
• и других моделей

Если результаты подтвердятся на широком наборе сценариев, DFlash может стать одним из самых заметных улучшений speculative decoding за последнее время, поскольку атакует главное ограничение метода — последовательную работу draft-модели.

https://github.com/z-lab/dflash

👉 @DataSciencegx

Теперь можно дообучать Qwen3.5.

Для локального обучения LoRA-адаптера на Qwen3.5-2B достаточно всего 5 ГБ видеопамяти. Обучение стало примерно в 1.5 раза быстрее и требует на 50% меньше VRAM.

Qwen3.5-4B в Google Colab:
https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_5_(4B)_Vision.ipynb
GitHub-проект Unsloth:
https://github.com/unslothai/unsloth

Подходит для быстрого и экономичного дообучения моделей Qwen3.5 на собственных данных даже на относительно слабых видеокартах.

👉 @DataSciencegx

Вау, это интересно.

Исследователи из Stanford проверили распространённое предположение: большие модели якобы нужно обучать только на “высококачественных” отфильтрованных данных.

А что если лучший фильтр — это отсутствие фильтра?

Они сравнили полный датасет Common Crawl с сильно отфильтрованными версиями и получили неожиданные результаты:

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

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

Из этого меняется базовое правило:
→ Фильтрация полезна при ограниченных ресурсах. Но при больших вычислениях чрезмерная очистка данных может просто выбросить полезную информацию.

Это хорошо ложится на идею “bitter lesson”: на масштабе часто побеждает простое масштабирование, а не ручная инженерия.

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

Интересно, как бы ты это использовал на практике 👀

https://arxiv.org/abs/2605.19407

👉 @DataSciencegx

Это исследование хорошо ложится на опыт любого, кто активно работает с Claude Code, Codex или другими агентами.

Оно смотрит не на бенчмарки, а на реальную работу в разработке:

как именно AI-агенты раздражают разработчиков в живых сессиях.

Авторы проанализировали 20 574 сессии (IDE и CLI). “Фейл” они определили не как падение кода, а как моменты, когда разработчик начинает исправлять, прерывать или спорить с агентом.

Картина довольно приземлённая. Чаще всего проблема не в том, что код не работает. Проблема в том, что агент нарушает явно заданные ограничения.

Ты пишешь: “не трогай этот файл”, “пока ничего не меняй”, “сделай минимальные правки” — он всё равно лезет дальше.
Просишь объяснить проблему — он параллельно начинает менять код.
Говоришь проверить всё перед финальным ответом — он рапортует успех до запуска проверок.

Есть интересное разделение:

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

Самое неприятное в этих сбоях — они редко ломают систему сразу. Они просто съедают время и доверие. Приходится постоянно перепроверять: понял ли он задачу, не вышел ли за рамки, реально ли он что-то проверил.

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

И отсюда простой вывод. Улучшение агентов — это не только про качество кода. Это про соблюдение границ, понимание намерений и честную отчётность о прогрессе.

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

👉 @DataSciencegx

Claude Code полностью разобрали по косточкам

Исследователи из UCL провели реверс-инжиниринг утёкшего исходного кода Claude. Их выводы меняют представление о том, как стоит проектировать AI-агентов.

Лишь 1,6% кодовой базы отвечает за логику принятия решений моделью.

Остальные 98,4% — это операционная инфраструктура: контроль разрешений, маршрутизация инструментов, сжатие контекста, логика восстановления, сохранение состояния сессий. Модель занимается рассуждением. Всё остальное делает обвязка (harness).
Это противоположно тому, как сегодня устроено большинство агентных фреймворков.

LangGraph пропускает ответы модели через явные конечные автоматы состояний. Devin накладывает тяжёлые планировщики поверх операционной инфраструктуры. Claude Code, наоборот, даёт модели максимум свободы в принятии решений внутри богатой детерминированной обвязки и направляет основные инженерные усилия именно на эту обвязку.

Основной цикл предельно простой: while (true). Вызов модели, запуск инструментов, повтор.
Но настоящая архитектура находится вокруг этого цикла:
- Система разрешений с 7 режимами работы и ML-классификатором. Пользователи всё равно одобряют 93% запросов, поэтому архитектура компенсирует это автоматизированными слоями защиты вместо добавления новых предупреждений.
- Пятиуровневый пайплайн сжатия контекста. Каждый следующий уровень запускается только если более дешёвый не справился: budget reduction, snip, microcompact, context collapse, auto-compact.
- Четыре механизма расширения, упорядоченные по стоимости контекста: hooks (нулевая стоимость), skills (низкая), plugins (средняя), MCP (высокая). Каждый решает свою задачу интеграции.
- Субагенты возвращают родительскому агенту только итоговое резюме. Полные логи их работы сохраняются в sidechain-файлах. Даже при таком подходе команда агентов расходует примерно в 7 раз больше токенов, чем обычная сессия.
- Функция Resume не восстанавливает разрешения, привязанные к сессии. Доверие устанавливается заново при каждой новой сессии. Именно так и задумано.

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

Статья: Dive into Claude Code (arXiv:2604.14228)

Также авторы выпустили отдельный материал про Agent Harness и то, что сегодня строят крупные компании в этой области.

👉 @DataSciencegx

Сегодня Google фактически превратил gist от Карпати про LLM-вики в официальный стандарт — Open Knowledge Format (OKF). По сути это markdown-файлы с одним обязательным полем.

Вопрос с форматом хранения знаний теперь во многом закрыт. Самая сложная часть осталась за рамками стандарта.

Что меняется:

- Портативность. База знаний может быть обычным tar-архивом или git-репозиторием. Её можно переносить между компаниями и инструментами без промежуточных конвертеров.
- Контроль версий. Знания хранятся рядом с кодом, который описывают. История изменений и диффы идут бесплатно вместе с git.
- Развязка инструментов. Человек создаёт и поддерживает базу знаний, агент её читает. Общий стек или специальные инструменты для этого не нужны.
- Никаких SDK и аккаунтов. Всё сводится к чтению и записи обычных markdown-файлов.

Что стандарт не решает:

- Разрешение противоречий. Новый источник может конфликтовать со старым. OKF сохранит оба факта, но не скажет, какой из них считать актуальным.
- Устаревание данных. Для даты есть отдельное поле, но решение о том, что факт больше не актуален, остаётся на вашей стороне.
- Политика слияния. В какую страницу попадёт новый факт, когда создавать отдельную ветку знаний, а когда обновлять существующую запись — ответственность агента или системы, которая пишет данные.
- Поиск. Для нескольких сотен страниц хватит index.md. Дальше понадобятся гибридный поиск, индексирование и reranker.

OKF стандартизировал картотеку. Библиотекаря всё ещё придётся строить самостоятельно.

https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

👉 @DataSciencegx

Stanford выпустил интересную работу, которая ставит под сомнение одну из базовых идей мультиагентных систем: а нужен ли вообще агент-менеджер, который раздаёт задачи всем остальным?

Обычно схема выглядит так:

- один агент получает задачу;
- дробит её на подзадачи;
- раздаёт работу;
- собирает результаты;
- склеивает финальный ответ.

Звучит логично, пока агентов и подзадач немного.

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

В статье предлагают DeLM (Decentralized Language Model).

Вместо центрального координатора используется общее проверяемое пространство контекста (shared verifiable context), к которому имеют доступ все агенты.

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

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

По сути, авторы переносят узкое место с агента-супервизора на общий слой знаний.

Именно эта идея кажется самой ценной.

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

Возможно, главный вопрос уже не «как разбить задачу на части», а «как организовать обмен информацией так, чтобы он сам не стал ограничением».

👉 @DataSciencegx

Исследователи показали, что Claude Code на 98% состоит вовсе не из AI.

Anthropic никогда не раскрывала архитектуру Claude Code. Не было ни документации, ни технических разборов. Только инструмент, которым сейчас одержима половина индустрии.

Пока недавно не произошла утечка.

Команда исследователей проанализировала исходный код объёмом около 500 000 строк и обнаружила любопытную деталь:

Лишь 1,6% кодовой базы напрямую взаимодействует с моделью.

Ядро Claude Code — по сути обычный цикл: спросить модель, что делать дальше → вызвать инструмент → повторить.

Тогда что занимает остальные 98,4%?

Классическая инженерия.

Исследователи нашли огромный слой инфраструктуры, задача которого — контролировать модель и не давать ей ошибаться, терять контекст или выполнять опасные действия.

Среди компонентов:

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

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

Подход Anthropic оказался другим.

Вместо того чтобы делать модель умнее, они построили вокруг неё массивную детерминированную инфраструктуру.

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

https://arxiv.org/pdf/2604.14228

👉 @DataSciencegx

Если следишь за AI-агентами для научных исследований, самая сложная часть — не найти одну хорошую статью, а разобраться во всей экосистеме.

Awesome AI Auto-Research — это curated-репозиторий на GitHub для исследователей и разработчиков, которые изучают применение AI в научной работе.

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

Что внутри:

• Карта жизненного цикла — auto-research разбит на 4 фазы и 8 этапов.
• Каталог статей — для каждого инструмента указаны статья, площадка публикации, сайт и GitHub-репозиторий.
• Этап создания исследований — идеи, поиск литературы, программирование, эксперименты, таблицы и визуализации.
• Этап проверки качества — peer review, ответы рецензентам, доработка работ, вопросы качества, предвзятости и регулирования.
• Раздел систем — отдельно выделены end-to-end системы, специализированные решения по доменам, самоулучшающиеся системы и инфраструктурные проекты.

Репозиторий распространяется по лицензии MIT и выглядит как неплохая отправная точка для тех, кто хочет понять весь пайплайн AI-assisted research, а не только отдельные модели или статьи.

https://github.com/worldbench/awesome-ai-auto-research

👉 @DataSciencegx

Attention — одна из ключевых идей, на которых держатся трансформеры и современные LLM.

Попробуем собрать её с нуля, по шагам.

Self-Attention

Self-attention помогает модели понять, как слова связаны друг с другом внутри предложения.
Модель не обрабатывает каждое слово отдельно. Каждый токен может “посмотреть” на другие токены и решить, какие из них сейчас важнее.

Возьмём предложение:

Every moment is a beginning.

Чтобы понять слово beginning, модель может сильнее обратить внимание на moment и Every.
Так появляется контекст: каждый момент может быть новым началом.

Query, Key, Value

Каждый токен создаёт три вектора:
Query (Q) — что я ищу?
Key (K) — какая информация во мне есть?
Value (V) — какую информацию я передам, если окажусь полезным?

Грубо говоря:
Query одного токена сравнивается с Key других токенов.
Чем лучше совпадение, тем больше внимания получает соответствующий Value.

Causal Self-Attention
В обычном self-attention токен может смотреть на все токены в последовательности.
Но языковые модели генерируют текст по одному токену. Значит, при предсказании следующего токена они не должны видеть будущее.

Например, если модель предсказывает:

Every moment is → a

она не должна заранее видеть слово beginning.

Для этого используется causal mask

Маска блокирует доступ к будущим токенам:
• токен 1 видит только себя
• токен 2 видит токены 1 и 2
• токен 3 видит токены 1, 2 и 3
• и так далее

Так модель предсказывает следующий токен только по прошлому и текущему контексту.
Без подглядывания вперёд.

👉 @DataSciencegx