Как организовать датасет для разных workflow
Если хранить фото, видео, подписи и готовые наборы для обучения в одной общей папке, путаница появляется очень быстро: captioning пишет txt не туда, одинаковые имена файлов конфликтуют, а один и тот же материал случайно уходит сразу в несколько пайплайнов.
Если хранить фото, видео, подписи и готовые наборы для обучения в одной общей папке, путаница появляется очень быстро: captioning пишет txt не туда, одинаковые имена файлов конфликтуют, а один и тот же материал случайно уходит сразу в несколько пайплайнов. Рабочий подход другой: разделить исходники, отобранные материалы и workflow-ready версии, а внутри развести фото, видео и производные файлы по понятным зонам.
Ниже — схема папок, пример структуры датасета для LoRA, правила именования, подход к captions и чек-лист перед запуском. Отдельно покажем, как не смешивать наборы под фото, видео и разные workflow, если вы работаете через ComfyUI, captioner или внешние тренеры.
Что даст такая структура: быстрее находить нужные файлы, повторять удачные сборки, не терять captions, не путать raw и processed версии, проще переносить датасет между машинами и серверами.
Содержание
- Почему общий каталог почти всегда ломает процесс
- Базовая схема папок: от сырья к рабочим наборам
- Как разделить датасет под фото, видео и разные пайплайны
- Что хранить в captions, manifests и служебных файлах
- Частые ошибки при подготовке датасета
- Чек-лист перед captioning и обучением
Почему общий каталог почти всегда ломает процесс
На практике проблемы начинаются не на этапе тренировки, а раньше — когда в одной папке лежат исходные фото, кадры из видео, обрезанные версии, upscale, txt-описания, промежуточные результаты captioning и готовые наборы под разные workflow. Визуально всё кажется удобным, но через пару итераций уже непонятно, какой файл исходный, какой обрабатывался, где лежит финальный caption и что именно пошло в тренировку.
Для LoRA это особенно критично. Многие инструменты ожидают простую логику: изображение и txt с одинаковым именем лежат рядом. Часть тренеров дополнительно читает название папки, repeats или служебные metadata-файлы. Если в каталоге образуется смесь из разных форматов и версий, ошибки начинаются почти незаметно: дубли в обучении, конфликт имен, устаревшие подписи, потерянные trigger-слова, неверные captions после перезаписи.
Из практики подготовки датасетов полезно держать в голове три правила. Первое: исходники не редактируются и не переименовываются после фиксации в raw. Второе: всё, что прошло отбор или ресайз, уходит в отдельную производную папку. Третье: каждый workflow получает свой собственный ready-набор, даже если часть исходных файлов совпадает.
Именно поэтому удобнее мыслить не одной папкой, а конвейером: raw → review → processed → captions → ready. Такой подход заметно упрощает и captioning, и обучение, и повторный запуск через несколько дней, когда детали уже успели забыться.
Базовая схема папок: от сырья к рабочим наборам
Ниже — базовая структура, которую легко адаптировать под фото, видео и несколько разных пайплайнов:
dataset/ ├── 00_inbox/ │ ├── photo_drop/ │ └── video_drop/ ├── 01_raw/ │ ├── photos/ │ └── videos/ ├── 02_review/ │ ├── keep/ │ ├── reject/ │ └── near_duplicates/ ├── 03_processed/ │ ├── photos_1024/ │ ├── photos_bucketed/ │ ├── video_clips/ │ └── extracted_frames/ ├── 04_captions/ │ ├── auto/ │ ├── edited/ │ └── exports/ ├── 05_ready/ │ ├── lora_photo/ │ ├── lora_video_frames/ │ ├── captioning_batch/ │ └── workflow_specific/ ├── 06_metadata/ │ ├── manifest.csv │ ├── manifest.jsonl │ └── notes.md └── 99_archive/
Логика здесь простая. В 00_inbox попадает всё новое, что ещё не разобрано. В 01_raw лежат исходники в том виде, в котором вы их приняли в работу. В 02_review вы решаете, что оставить, а что убрать из дальнейшей подготовки. В 03_processed появляются уже технические версии: квадратные изображения, bucketed-версии, клипы нужной длины, кадры из видео.
Папка 04_captions нужна, чтобы не смешивать автоописания, ручную редактуру и экспорт под конкретный инструмент. Это особенно полезно, если вы уже сталкивались с ситуацией, когда captioner что-то сохранил, но через день уже непонятно, где искать финальные txt. Кстати, для смежных задач пригодятся материалы про готовые описания после captioning, единое разрешение перед captioning и случаи, когда captioner не видит папки с фото.
Самая важная зона — 05_ready. Здесь лежат уже не исходники и не промежуточные файлы, а конкретные наборы под конкретную задачу. Это и есть главный ответ на вопрос, как организовать датасет так, чтобы он пережил несколько workflow и не превратился в хаос.
Как разделить датасет под фото, видео и разные пайплайны
Удобнее всего делить датасет сразу по двум осям: тип медиа и цель использования. Фото для LoRA, кадры из видео для дообучения, клипы для video workflow и набор для captioning — это разные сущности, даже если они собраны из одного источника.
Для фото-датасета под LoRA рабочая структура обычно выглядит так:
05_ready/lora_photo/ ├── subject-a/ │ ├── 0001.jpg │ ├── 0001.txt │ ├── 0002.jpg │ ├── 0002.txt │ └── ... └── subject-b/
Такой формат понятен почти любому инструменту: рядом с каждым изображением лежит одноимённый txt. Если вы используете тренеры, которые ориентируются на имя папки, repeats или concept folder naming, лучше держать отдельный ready-набор именно под них, а не переиспользовать общий каталог. Это особенно актуально для тех сценариев, где содержимое txt приоритетнее названия папки.
Для видео лучше держать другую схему:
05_ready/workflow_specific/video_pipeline/ ├── videos/ │ ├── clip_001.mp4 │ ├── clip_002.mp4 │ └── ... ├── captions/ │ ├── clip_001.txt │ ├── clip_002.txt │ └── ... └── metadata.jsonl
Если потом из видео извлекаются кадры для фотообучения, не подмешивайте их обратно к видеоклипам. Выделите отдельный набор вроде lora_video_frames. Это помогает избежать ситуации, когда в одном каталоге лежат и mp4, и png, и txt, и непонятно, что должен читать конкретный workflow.
Ещё один важный слой — разделение по версии пайплайна. Например:
05_ready/workflow_specific/ ├── zimage_photo_v1/ ├── flux_lora_v2/ ├── wan_video_v1/ └── captioner_runpod_v1/
Такой нейминг кажется избыточным только в начале. Но когда вы тестируете разные инструменты, быстро выясняется, что у каждого свои ожидания к разрешению, кадрированию, captions и расположению файлов. В одной из практических связок хорошо работает квадратный набор для фотообучения, в другой — bucketed-версии, в третьей — отдельно подготовленные клипы с captions через metadata.jsonl.
Если в наборе есть человек или персонаж, следите не только за количеством файлов, но и за разнообразием. В реальных сборках устойчиво работают датасеты, где есть крупные планы, поясные кадры и полный рост, а не тридцать почти одинаковых ракурсов. Монотонные серии дают иллюзию объёма, но учат модель слабее, чем аккуратно отобранный набор с разным светом, позами и дистанцией до камеры. По этой причине полезно заранее чистить near-duplicates и держать отдельную папку для спорных файлов.
Если вы работаете через Runpod или переносите проект между локальной машиной и сервером, помогает ещё один уровень порядка: все пути, manifests и готовые пакеты складывать отдельно от workflow JSON. Для этого полезны материалы про поиск датасета и временных файлов в Runpod / ComfyUI, workflow JSON в ComfyUI и перенос workflow между локальным ПК и облаком.
Что хранить в captions, manifests и служебных файлах
Для маленьких датасетов хватает пары image + txt. Но как только появляется несколько workflow, лучше ввести ещё и служебный слой. Минимальный набор — это manifest.csv или manifest.jsonl, где для каждого файла записаны ID, источник, статус отбора, версия ресайза, путь к caption и целевой pipeline.
Пример полей для manifest:
| id | media_type | source_path | processed_path | caption_path | pipeline | status |
|---|---|---|---|---|---|---|
| 0001 | photo | 01_raw/photos/0001.jpg | 03_processed/photos_1024/0001.jpg | 04_captions/edited/0001.txt | lora_photo | ready |
| v014 | video | 01_raw/videos/v014.mp4 | 03_processed/video_clips/v014.mp4 | 04_captions/edited/v014.txt | wan_video_v1 | ready |
Такой манифест решает сразу несколько задач. Он даёт вам один источник правды по файлам, помогает быстро собрать новый ready-набор и снижает риск случайно обучить модель на устаревших версиях изображений.
В captions удобно хранить три состояния: auto, edited и exports. Автоописания остаются как черновик. Отредактированные тексты становятся основной рабочей версией. А в exports можно держать конкретный формат выгрузки под инструмент, если ему нужен отдельный тип имени файла, расширение или порядок полей.
Отдельное внимание стоит уделить trigger-словам и именованию. Если название субъекта меняется по ходу работы, лучше обновить это в служебных файлах и в ready-наборе, а raw не трогать. Смешанная нейминг-схема вроде girl-final-new-2, mymodel-fixed и subject-last-real очень быстро ломает читаемость проекта.
Частые ошибки при подготовке датасета
1. Один каталог на всё. Кажется удобным, пока не начинается второй workflow.
2. Перезапись исходников. После этого уже нельзя понять, что именно было в raw и чем отличалась обработанная версия.
3. Смешивание фото и кадров из видео. Такие наборы трудно контролировать по качеству и дубликатам.
4. Хранение captions только в output конкретного инструмента. После смены сервера или шаблона найти финальные тексты становится сложнее.
5. Случайные имена файлов. Лучше использовать стабильный ID: 0001, 0002, 0003 или subjecta_0001.
6. Слишком много похожих кадров. Десять почти одинаковых файлов хуже, чем два действительно отличающихся по позе, свету или дистанции.
7. Нет разделения по ready-наборам. Именно это чаще всего ломает датасет для workflow, когда один и тот же каталог начинают кормить и captioner, и тренеру, и видеоузлам.
Если вы только входите в тему, дополнительно стоит посмотреть материалы про 25 качественных фото против 50 средних, кадры, которые вредят обучению LoRA и подготовку txt-описаний для датасета.
Чек-лист перед captioning и обучением
- Есть отдельные папки для raw, processed, captions и ready.
- Фото и видео разведены по разным веткам.
- У каждого ready-набора понятна цель: photo LoRA, video workflow, captioning batch.
- Имена файлов стабильные и не меняются от запуска к запуску.
- Каждому изображению в ready-папке соответствует txt с тем же именем.
- Дубликаты и почти одинаковые кадры отчищены или вынесены в отдельную папку.
- Разрешение и формат подогнаны под нужный pipeline, а не под все сразу.
- Есть manifest или хотя бы notes.md с правилами текущей сборки.
- Trigger-слова и названия наборов приведены к одной логике.
Итоговый принцип простой: не пытайтесь сделать один универсальный каталог, который понравится всем инструментам сразу. Гораздо надёжнее собрать один аккуратный архив исходников и несколько ясных ready-наборов под конкретные задачи. Именно так структура датасета LoRA остаётся управляемой, а разные workflow не мешают друг другу.
Если держать эту дисциплину с первого дня, вы быстрее повторяете удачные сборки, легче переносите проект между окружениями и намного спокойнее тестируете новые пайплайны — от captioning до обучения и дальнейшей генерации.