8 ноября 2026 года пользователь Reddit под ником -MaskNinja- выложил в r/LocalLLaMA пост «GPT-5.5 dataset across my used 25 billion tokens!» с описанием собственного датасета. Набор собран из личных сессий работы с GPT-5.5. Заявленный объём: около 25 млрд токенов, внутри 12 121 вызов инструментов (tool calls). Очистку данных выполнил u/New_Comfortable7240, автор поста благодарит его отдельной строкой.
Воспринимать релиз стоит как логи одного рабочего процесса. Подтверждается источником немногое: ник автора, площадка, модель, число tool calls и сам факт санитизации. Объём в 25 млрд токенов взят из заголовка и независимо не проверен; лицензия, формат файлов, схема полей и способ доступа в тексте поста не раскрыты. Для практики эти четыре пробела важнее заявленного объёма: именно они решают, можно ли данные использовать, а не только скачать.
Что известно о датасете из сессий GPT-5.5
Подтверждённые факты и заявленные цифры
| Утверждение | Статус | Комментарий |
|---|---|---|
| Автор публикации -MaskNinja- | Подтверждено | Указан как отправитель поста на Reddit |
| Площадка: Reddit, r/LocalLLaMA | Подтверждено | Пост с описанием набора |
| Модель: GPT-5.5 | Подтверждено | Модель, сессии с которой легли в основу |
| 12 121 tool call | Заявлено автором | Число названо в посте, проверяется только подсчётом по файлам |
| Около 25 млрд токенов | Заявлено, независимо не подтверждено | Цифра из заголовка поста |
| Санитизация силами u/New_Comfortable7240 | Подтверждено | Методика и критерии очистки не описаны |
| Лицензия, формат, структура полей, способ доступа | Нет данных | В исходном материале отсутствуют |
Разделение в таблице простое: всё, что можно проверить по самим данным, проверяется за полчаса работы с файлами. Всё, что относится к праву и происхождению, проверяется только у автора набора или по приложенной документации, которой в посте нет.
Почему это пользовательский, а не официальный релиз
Набор собрал энтузиаст из собственных сессий. В исходном материале нет ни слова об участии разработчика модели: ни о подготовке выгрузки, ни о проверке содержимого, ни о лицензировании. Это принципиально меняет набор гарантий. Официальный релиз обычно сопровождается карточкой с описанием полей, условиями использования и хотя бы кратким описанием фильтрации; здесь всё держится на репутации автора поста и на тексте, который он написал сам.
Отсюда практическое следствие: сравнивать такой набор с вендорскими каталогами бессмысленно, а ждать поддержки и обновлений не стоит. Пользовательские выгрузки логов появляются волнами, и каждый релиз приходится оценивать заново, даже если он выглядит похоже на предыдущий.
Что обычно содержит датасет из сессий LLM
Детальной схемы именно этого набора в источнике нет, поэтому речь дальше о типовой практике выгрузок из чатов и агентных клиентов. Такие логи обычно пишут построчно: одна запись равна сообщению или одному ходу диалога, реже вся сессия лежит единым объектом в JSON.
Диалоги, промпты и метаданные
Минимальный набор полей, который встречается в подобных выгрузках:
- идентификатор сессии и номер хода, чтобы восстановить порядок реплик;
- роль: system, user, assistant, tool;
- содержимое сообщения;
- метка времени;
- версия или имя модели;
- параметры генерации, если клиент пишет их в лог;
- счётчик токенов и причина остановки ответа.
Имена полей в разных выгрузках не совпадают: встречаются messages, conversation, turns, segments. Форматы тоже расходятся: JSONL, JSON, Parquet, SQLite. Что лежит в наборе -MaskNinja-, из поста неизвестно, поэтому первым делом стоит открыть файл и посмотреть реальную схему. Ожидания, построенные на чужом опыте, здесь чаще мешают, чем помогают.
Блок tool calls: что в нём фиксируется
Вызов инструмента в логах обычно выглядит как отдельный объект из четырёх элементов: имя инструмента, аргументы в JSON, результат выполнения и статус (успех или ошибка). Добавляются служебные поля: идентификатор вызова, связывающий его с сообщением ассистента, задержка, иногда текст ошибки и номер попытки. Условная схема, показывающая типовую структуру, а не конкретный файл из набора:
{"call_id": "...", "tool": "search", "arguments": {"query": "..."}, "status": "ok", "result": "..."}
Такие блоки превращают обычный чат-лог в данные об агентном поведении: видно, какой инструмент выбран, какие аргументы собраны, что вернулось и чем всё закончилось. В наборе -MaskNinja- заявлен 12 121 вызов. Сколько среди них уникальных инструментов, какая доля завершилась ошибкой и как вызовы распределены по сессиям, автор поста не сообщает: это считается по файлам.
Зачем в датасете фиксируются tool calls
Вызовы инструментов показывают решение модели в момент действия, а не только текст ответа. По ним разбирают четыре вещи.
- Выбор инструмента. Какие задачи модель закрывает поиском, какие выполнением кода, где обходится без инструментов вовсе.
- Сборку аргументов. Корректен ли JSON, попадают ли в запрос лишние поля, как формулируются параметры и насколько они стабильны от вызова к вызову.
- Реакцию на ошибку. Повторяет ли модель тот же вызов, меняет аргументы, переключается на другой инструмент или сдаётся.
- Структуру цепочек. Сколько шагов занимает задача до результата, где появляются лишние итерации и повторные чтения одного и того же.
Это сырьё для отладки промптов, описаний инструментов и проверки надёжности агента. Категории инструментов в агентных сборках обычно повторяются: веб-поиск, исполнение кода, чтение и запись файлов, вызовы внешних API, поиск по базе знаний в RAG-сценариях. Наличие конкретных инструментов в этом наборе источник не подтверждает, перечисление описывает распространённые группы.
Ограничение заложено в природе данных. 12 121 вызов из сессий одного человека отражают его стиль: его формулировки, его стек, его типовые задачи. Это не выборка по пользователям и не срез по индустрии, и переносить закономерности на чужой рабочий процесс без проверки нельзя.
Кому и для каких задач нужен такой датасет
Набор закрывает несколько задач, но у каждой есть условие, при котором она имеет смысл.
Анализ паттернов использования. Логи отвечают на вопрос, как один опытный пользователь делит работу между чатом и инструментами, сколько шагов тратит на задачи, как часто возвращается к одной теме. Выводы ограничены этим профилем: для сравнения с другими пользователями нужен второй источник.
Дообучение и файнтюнинг: где польза, а где риск
Для файнтюнинга такие данные годятся как узкий профиль. Они показывают конкретный стиль вызовов, формат аргументов и последовательности действий, которые можно воспроизвести в своей модели. Риски тоже конкретные: смещение к задачам одного человека, персональные данные в промптах, неясная лицензия. Тренировка на наборе без явных условий использования создаёт юридический риск, который не снимается технической чистотой файлов. Результатов файнтюнинга на этом наборе никто публично не приводил, поэтому обещаний по приросту качества быть не может.
Оценка и отладка агентных сценариев
Практичнее всего использовать tool calls как материал для разбора: восстановить последовательность вызовов в сложной сессии, найти шаг, где агент ушёл не туда, сравнить свою реализацию с чужой. Для честной оценки нужен контроль состава: какие сценарии представлены, сколько их, есть ли повторяемые задачи с известным правильным ответом. Распределение по доменам в этом наборе неизвестно, поэтому строить на нём бенчмарк можно только после ручной разметки.
Если цель в том, чтобы оценивать агентов системно, полезнее посмотреть на подходы с заранее заданным протоколом: разбор идеи прикладного бенчмарка и The Struggle Bench. Разница принципиальная: там условия и метрики зафиксированы до прогона, здесь вы получаете сырой лог и сами решаете, что в нём считать.
Исследования и поиск альтернатив. Если нужен набор пошире или свежие материалы по теме, Daily Papers на Hugging Face даёт рабочий способ выходить на статьи, датасеты и обсуждения без ручного перебора.
Кому набор не нужен: тем, кто ищет сбалансированный корпус от множества авторов, и тем, кому нужен готовый бенчмарк с фиксированными метриками. В обоих случаях придётся искать другой источник.
Ограничения: почему один пользователь - это мало
Главное ограничение названо в самом источнике: данные получены из сессий одного пользователя, поэтому репрезентативность и применимость к другим рабочим процессам требуют проверки. Дальше это разворачивается в конкретные риски, которые видно на этапе чтения файлов.
Смещение и узкий профиль данных
Если автор большую часть времени работал с кодом, набор перекосит в сторону кода: в tool calls доминируют запуск кода и работа с файлами, а задачи вроде работы с документами или аналитики окажутся редкими. Если основная работа была текстовой, получится обратная картина. Редкие сценарии почти всегда недопредставлены: их просто мало в жизни одного человека.
Объём в токенах не равен числу примеров. Несколько длинных сессий с большим контекстом могут дать заметную долю заявленных 25 млрд, а количество независимых случаев окажется скромным. Поэтому до любого использования стоит посчитать распределение по типам задач, по инструментам и по длине сессий.
Санитизация: что проверить, раз методика неизвестна
u/New_Comfortable7240 выполнил очистку, но критерии в посте не описаны: неизвестно, что именно вырезалось, какими правилами и был ли ручной просмотр. Искать самостоятельно стоит как минимум адреса email, ключи доступа (строки вида sk-, AKIA, ghp_), приватные ключи, локальные пути вида /Users/ и C:\Users\, внутренние URL и имена хостов, имена людей и клиентов, номера телефонов, содержимое конфигов.
Отдельно проверьте системные промпты и первые сообщения сессий: там чаще оседают внутренние инструкции, названия проектов и правила доступа. Ещё один маркер утечки: длинные фрагменты логов сборки, дампов и сообщений об ошибках с реальными путями и версиями внутренних сервисов.
Как самостоятельно оценить подобный датасет: чек-лист
Список ниже подходит для любого пользовательского набора с логами LLM, не только для этого.
- Лицензия. Что разрешено: обучение, коммерческое использование, перепубликация. Без лицензии набор годится для чтения и экспериментов, но не для тренировки продукта.
- Формат и размер. JSONL, Parquet, архив? Сколько файлов и записей, сходится ли заявленный объём токенов с подсчётом по файлам.
- Схема полей. Есть ли id сессии, роль, временные метки, версия модели, статус tool call. Совпадают ли типы между файлами.
- Методика очистки. Что вырезали, чем проверяли, был ли повторный прогон после правок.
- Состав. Распределение по типам задач, по инструментам, по длине сессий и числу ходов.
- Доля ошибок. Сколько tool calls завершилось неуспехом, как часто модель повторяла один и тот же вызов.
- Воспроизводимость. Понятно ли, каким клиентом и с какими настройками логирования собирались данные, можно ли повторить сбор.
Что смотреть в первые 15 минут после скачивания
Быстрый прогон, который отсеивает проблемные наборы до того, как вы потратите на них день:
- Открыть 5-10 случайных записей и прочитать их целиком, а не только первое поле.
- Вывести список ключей по всем записям: реальная схема часто шире заявленной.
- Прогнать регулярки по PII и секретам: email, телефоны, ключи доступа, приватные ключи, локальные пути.
- Посчитать долю tool calls со статусом ошибки и число уникальных инструментов.
- Построить гистограмму длины сессий и числа ходов: перекос покажет, что большая часть объёма приходится на несколько разговоров.
- Проверить дубликаты записей и пустые сообщения, которые ломают подсчёт токенов.
Если на первые четыре пункта большого чек-листа ответов нет, дальше можно не идти: без лицензии, формата, схемы и описания очистки набор остаётся материалом для личного разбора.
Практический вывод: брать или нет
Для анализа агентного поведения набор интересен. 12 121 вызов инструментов из живых сессий собрать самому трудно, а такие логи редко появляются публично. Для тренировки универсальной модели он слаб как единственный источник: один пользователь, неизвестная лицензия, неописанная очистка, неподтверждённый объём.
Решение зависит от задачи. Нужен материал для разбора вызовов, отладки описаний инструментов и проверки гипотез о поведении агента: скачивайте и прогоняйте по чек-листу, начиная со схемы полей и PII. Нужен корпус для файнтюнинга продукта: сначала лицензия и распределение по доменам, потом данные. Если ответов по лицензии, формату, схеме и очистке нет, набор остаётся исследовательским материалом, а не производственным.