Журнал · Rit.work

Почему миллион строк не гарантирует качество датасета

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

Rit.work
Студия разработки
30 сентября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

В KinyaMed требование о миллионе примеров оказалось выполнимым без корпуса, пригодного для оценки классификатора срочности. Работа не рецензирована, а все числа получил сам автор: генератор достиг целевого объёма за 130 секунд, хотя проверки качества корпус не прошёл. Для команд это меняет не выбор модели, а требования к данным: считать нужно независимо написанные примеры, а не производные строки.

165 исходных фраз превратились в формально большой корпус

Система должна была определять срочность обращения по тексту пациента на Kinyarwanda. Корпус строился из исходных фраз (seed phrases), которые носитель языка писал от лица пациента или его родственника. Генератор добавлял к ним вступления, контекст и окончания, создавая множество вариантов одной основы.

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

В корпусе было 165 независимо написанных фраз. Отдельное правило ограничивало вклад каждой основы 50 строками, чтобы несколько шаблонов не заняли весь набор. При таком ограничении пройти проверку по разнообразию можно только после добавления ещё 2 835 фраз, а совместить её с требованием о заявленном объёме — после добавления 19 835.

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

Проверка должна считать независимые примеры

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

Проверка KinyaMed учитывала число самостоятельных фраз для каждого языка и класса срочности. Если в ячейке их не хватало, она отказывалась выводить метрику. Это полезнее точного на вид значения полноты: число на зависимых перестановках описывает генератор, а не способность модели работать с новыми обращениями.

Поведение модели подтвердило, что большой объём строк не сделал вход устойчивым. После изменения регистра букв класс срочности менялся у 31,5% текстов, после одной опечатки — у 21%. Работа не связывает эти сбои с одной причиной: повлиять могли однообразный корпус, чувствительная к регистру токенизация и небольшое расстояние до границы между классами.

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

Планы меняются в требованиях к данным, а не в выборе модели

Работа не даёт оснований выбирать конкретную архитектуру или считать медицинский классификатор готовым. Это проект одного автора; существующий корпус охватывает только Kinyarwanda, реальные данные пациентов не использовались, клиницист не проверял метки, а обученная модель служит для аудита конвейера. Её результаты нельзя переносить на клиническое применение.

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

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

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

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

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу