데이터 설계
1. 생성형 AI와 첫 질문
지금의 아카이브는 처음부터 계획된 프로젝트가 아니었다.
출발점은 의외로 단순했다.
2022년, 생성형 AI Midjourney로 제작된 Théâtre D'opéra Spatial가 미국 Colorado State Fair Fine Arts Competition 디지털 아트 부문에서 1등을 수상했다는 소식을 접했다. 수상 자체보다 충격적이었던 것은 제작자가 AI를 사용했다는 사실을 처음에 밝히지 않았다는 점이었다. 그 사건은 생성형 AI로 만든 이미지를 예술 작품으로 볼 수 있는가, 그리고 창작의 주체는 누구인가라는 논쟁을 미술계 전반으로 확산시켰고, 나 역시 생성형 AI에 본격적으로 관심을 갖게 된 계기가 되었다.
이 무렵, DALL·E 2를 사용하기 시작했다. 내가 그린 그림을 입력하면 그것을 바탕으로 새로운 이미지를 생성하는 image-to-image 기능을 통해 처음으로 내 그림이 기계 안에서 변형되는 과정을 경험했다. 그것은 단순히 그림을 복제하는 기능이 아니었다. 내가 그린 형태와 색채가 예상하지 못했던 방향으로 재구성되는 모습을 확인할 수 있었고, 이전까지 경험하지 못했던 제작 방식을 접하게 되었다.
그 과정에서 몇 가지 질문이 생겼다.
- AI는 무엇을 학습했기에 이러한 이미지를 생성하는 것일까? 입력(Input)이 어떤 내부 과정을 거쳐 결과(Output)로 이어지는가?
- 서버에 접속하지 않고 개인의 컴퓨터(로컬 환경)에서도 이미지를 생성할 수 있을까? 언젠가는 개인 비서처럼 스스로 운용할 수 있는 생성 환경을 만들 수 있을까?
- 특정한 그림만 선택해서 학습시키는 것도 가능할까?
- 그렇다면 내 그림을 직접 학습시키면 어떤 결과가 나올까?
- AI가 이미지를 반복되는 형태와 패턴을 바탕으로 생성한다면, 내가 의식하지 못했던 내 작업의 특징이나 반복되는 구조도 드러날 수 있지 않을까?
2. 생성 환경 구축과 LoRA 학습
하지만 그 질문들에 대한 답을 찾는 동안에도 생성형 AI를 둘러싼 환경은 빠르게 변하고 있었다. OpenAI의 이미지 생성 환경은 DALL·E 3와 ChatGPT 중심으로 재편되었고, 내가 사용하던 DALL·E 2 기반의 실험 방식도 이전과 같은 형태로 이어가기 어려워졌다. 서비스 환경의 변화와 관계없이 그 질문을 계속 이어가기 위해 직접 생성 환경을 구축하기로 했다.
직접 실험을 이어가기 위해서는 AI를 학습시킬 수 있는 환경이 필요했다. 당시에는 생성형 AI 모델을 로컬 환경에서 학습시키기 위해 충분한 GPU 성능을 갖춘 컴퓨터가 필수였기 때문에 새 컴퓨터를 구입했고, NVIDIA RTX 5070 Ti를 장착했다.
당시 DALL·E 2를 비롯한 대부분의 이미지 생성 AI는 개발사의 서버를 통해서만 사용할 수 있었다. 생성 요청을 보내면 서버가 처리해 결과를 돌려주는 방식이었기 때문에, 사용자가 학습 과정에 직접 개입하거나 자신의 데이터로 모델을 수정하는 것은 불가능했다.
Stable Diffusion 1.5(2022.10, RunwayML 배포)는 그 흐름을 이어받은 오픈소스 모델이었다. 개인의 컴퓨터에서 직접 실행할 수 있었고, 서버에 의존하지 않고 생성과 학습을 직접 수행할 수 있었다. 이 모델을 기반으로 LoRA 학습을 시작했다. LoRA는 이미 다양한 이미지를 학습한 모델에 특정 작가의 작품만 추가로 학습시키는 방식으로, 기존 모델 전체를 다시 학습시키지 않고도 특정 화풍이나 특징을 반영할 수 있었다. 이는 당시 내가 품고 있던 질문들을 직접 검증해 볼 수 있는 가장 현실적인 방법이었다.
3. 데이터를 바라보는 방식의 변화
그렇게 LoRA 학습을 반복하는 과정에서 예상하지 못했던 사실을 발견했다.
중요한 것은 단순히 학습을 수행하는 것이 아니라 데이터를 어떻게 구성하고, 어떤 방식으로 학습시키며, 학습된 모델을 어떻게 활용하느냐였다.
기계는 이미지를 사람처럼 이해하지 않는다. 이미지와 함께 제공되는 텍스트를 대응시키며 형태와 색채, 구조, 반복되는 특징을 학습한다. 같은 그림이라도 어떤 태그를 부여하느냐에 따라 결과는 크게 달라졌다.
뿐만 아니라 학습 횟수(Epoch), 학습률(Learning Rate), 배치 크기(Batch Size)와 같은 학습 조건에 따라서도 결과는 크게 달라졌다. 같은 데이터를 사용하더라도 얼마나 반복해서 학습시키고 어떤 강도로 학습시키느냐에 따라 모델이 학습하는 특징이 달라졌다.
학습이 끝난 이후에도 결과는 고정되지 않았다. CFG Scale, Denoising Strength와 같은 생성 설정에 따라 같은 모델에서도 전혀 다른 이미지가 출력되었다. 어떤 의도로 이미지를 생성할 것인지 역시 출력 과정에서 함께 결정된다는 사실을 알게 되었다.
그 경험은 그림을 바라보는 방식에도 변화를 가져왔다. 그림을 그리는 사람의 시선과 데이터를 구축하는 사람의 시선을 동시에 갖게 되었고, 하나의 작품을 수많은 인간의 판단이 개입된 데이터로 바라보게 되었다.
결과적으로 하나의 이미지는 단순히 데이터만으로 만들어지는 것이 아니었다. 데이터 구성과 태깅, 학습 조건, 출력 설정 등 수많은 선택이 결합되어 하나의 결과가 만들어진다는 사실을 이해하게 되었다.
그때부터 작품은 회화인 동시에 하나의 데이터라는 관점도 생겼다. 그 생각은 자연스럽게 "더 큰 AI 모델에서는 작품을 어떻게 기록해야 하는가"라는 질문으로 이어졌다. 한 장의 이미지에는 제작 과정에서 이루어진 수많은 선택과 판단이 담겨 있으며, 그것을 기계가 읽을 수 있는 형태로 기록하는 것 역시 중요한 작업이라고 생각하게 되었다.
Parameters: Model: Stable Diffusion 1.5 <lora:jeongseon_564_70_1:1> geumgangjeondo <lora:painting_v2:1> eastbrush, landscape Steps: 20, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 7, Seed: 1716447084, Size: 896x552, Model hash: 6ce0161689, Model: v1-5-pruned-emaonly, Lora hashes: "jeongseon_564_70_1: da2f49104b3a, painting_v2: b359cdda2556", Version: v1.10.1
4. 데이터 설계
태그의 중요성을 이해하면서 관심은 자연스럽게 파운데이션 모델로 이어졌다.
LoRA가 특정 작가의 화풍이나 특정 이미지의 특징을 학습시키는 방식이라면, 파운데이션 모델은 훨씬 더 큰 규모의 데이터를 기반으로 작동한다. 그렇다면 파운데이션 모델에서는 어떤 방식으로 데이터를 기록해야 하는가. 내 그림은 어떤 구조로 정리되어야 하는가. 언젠가 더 큰 모델 안에서도 내 작업이 하나의 데이터로 읽히기 위해서는 무엇이 필요할까.
LoRA 학습을 진행하면서 AI와 데이터를 기록하는 방식에 대해 여러 차례 대화를 나누었다. 그 과정에서 LoRA 학습을 위한 태그만으로는 충분하지 않으며, 더 큰 규모의 모델을 염두에 둔다면 이미지와 텍스트의 대응 관계뿐 아니라 제작 과정과 계보, 메타데이터까지 함께 기록할 수 있는 구조가 필요하다는 점을 이해하게 되었다. 그 질문은 결국 데이터를 어떻게 설계할 것인가의 문제로 이어졌다.
데이터를 장기간 관리하고 서로의 관계를 기록하기 위해서는 모든 이미지를 일관된 구조로 식별할 수 있는 기준이 필요했다. 그래서 모든 이미지에 고유 ID를 부여하기 시작했다.
또한 최종 결과물만 저장하면 제작 과정에서 이루어진 판단과 변화는 기록되지 않는다. 그래서 결과물과 제작 과정, 참고 자료를 서로 다른 계층으로 구분하여 관리하는 구조를 설계하였다.
최종 결과물인 드로잉과 회화는 메인라인(Main Line)으로 정의하였다. 메인라인은 아카이브의 중심이 되는 작업이며, 다른 모든 데이터는 이를 기준으로 연결되도록 설계하였다.
제작 과정에서 만들어지는 구조 분석 드로잉과 실험 결과물은 서브라인(Sub Line)으로 분리하였다. 서브라인은 완성된 작품이 아니라 제작 과정을 기록하기 위한 데이터이며, 메인라인을 이해하기 위한 보조 구조로 사용하였다.
작품 제작에 참고한 사진, 고전 회화, 박물관 자료, 문헌 등 외부 자료는 레퍼런스 라인(Reference Line)으로 분리하였다. 이 계층은 작품 자체가 아니라 작업이 어떤 자료를 바탕으로 이루어졌는지를 기록하기 위한 구조이다.
각 이미지는 독립적인 파일로 저장하는 데 그치지 않고, 서로의 관계까지 함께 기록하도록 설계하였다. 하나의 드로잉이 어떤 회화로 이어졌는지, 어떤 사진과 생성 이미지를 참고했는지, 그리고 하나의 작품이 다시 다른 작품으로 어떻게 확장되었는지를 계보(Lineage) 형태로 연결하기 시작했다.
이렇게 결과물뿐 아니라 제작 과정과 참고 자료까지 하나의 데이터로 관리할 수 있는 구조를 만들었다. 작품을 남기는 것과 함께 작품이 만들어지는 과정을 기록하는 것 역시 아카이브의 중요한 목적이라고 판단했기 때문이다.
5. 작업의 변화
그때부터 작업의 범위도 달라졌다.
그림을 그리고, 배접을 하고, 작품을 촬영하고, 참고 자료를 스캔하고, 이미지를 편집하고, 파일명을 정리하고, ID를 부여하고, 메타데이터를 작성하고, 계보를 연결하고, 데이터 오류를 검수하는 과정이 하나의 작업이 되었다.
3개월 동안 그림을 그리고 나면 이후 약 1개월은 기록과 데이터 정리에 사용할 정도가 되었다. 화가인지 데이터 관리자인지 구분이 흐려지는 시간이다.
시간이 지날수록 내가 만들고 있는 것은 완성된 작품들의 목록이 아니라는 생각이 들었다. 중요한 것은 완성된 이미지 자체만이 아니었다. 그 이미지가 왜 만들어졌는지, 무엇을 참고했는지, 어떤 선택과 판단이 이루어졌는지, 그리고 어떤 경로를 거쳐 변화했는지까지 함께 기록할 필요가 있다고 생각하게 되었다.
즉, 하나의 이미지가 만들어지기까지의 생태계를 함께 기록해야 한다고 생각했다. 작품은 하나의 결과물이지만, 그 결과물은 제작 과정과 참고 자료, 실험, 그리고 수많은 선택과 판단이 연결된 과정 속에서 만들어지기 때문이다.
6. 현재
처음부터 지금과 같은 아카이브를 만들 계획이 있었던 것은 아니다. 몇 가지 질문에서 시작된 호기심은 생성 환경 구축으로 이어졌고, LoRA 학습과 태깅, 메타데이터 설계, 그리고 지금의 아카이브 구조로 확장되었다.
지금도 나는 작품을 제작하고, 그 과정을 기계가 읽을 수 있는 데이터로 기록하고 있다.
작업을 계속하면서 하나의 생각이 생겼다. 앞으로는 작품을 남기는 것뿐 아니라, 작품이 만들어지는 메커니즘도 함께 남길 수 있는 시대가 오지 않을까 하는 생각이다.
데이터를 공개하는 플랫폼으로는 Hugging Face를 선택했다. 현재 AI 연구자와 개발자들이 데이터셋에 직접 접근하는 플랫폼으로 가장 널리 쓰이고 있고, 버전 관리와 구조화된 데이터셋 공개가 가능하기 때문이다. 그리고 이 기록이 언젠가 누군가에게 쓰임이 될 수 있기를 바란다. 그 누군가가 기계일지라도....
Eastbrush Archive (Hugging Face Dataset)
https://huggingface.co/datasets/eastbrush/eastbrush_archive
20260629
Data Design
1. Generative AI and the First Questions
This archive wasn't planned as a project from the start.
The starting point was, surprisingly, simple.
In 2022, I came across the news that Théâtre D'opéra Spatial, made with the generative AI Midjourney, had won first place in the digital art category of the Colorado State Fair Fine Arts Competition in the US. What was more shocking than the win itself was that the creator hadn't initially disclosed that AI had been used. That incident sparked a debate across the art world over whether images made with generative AI could be considered art, and who the real subject of creation was — and it was also what got me seriously interested in generative AI myself.
Around this time, I started using DALL·E 2. Through its image-to-image feature — where you input a drawing of yours and it generates a new image based on it — I experienced, for the first time, my own drawing being transformed inside a machine. It wasn't simply a copying function. I could see the shapes and colors I'd drawn being reconstructed in directions I hadn't anticipated, and I encountered a way of making images I'd never experienced before.
In the process, a few questions came up.
- What exactly has the AI learned, that it generates these kinds of images? What internal process turns the input into the output?
- Could I generate images without connecting to a server, on my own personal computer (a local environment)? Could I someday build a generation environment that could run on its own, like a personal assistant?
- Would it even be possible to selectively train on only certain drawings?
- And if so, what would happen if I trained it directly on my own drawings?
- If AI generates images based on recurring shapes and patterns, might it also reveal features or recurring structures in my own work that I myself hadn't been conscious of?
2. Building a Generation Environment and LoRA Training
But even while I was looking for answers to those questions, the environment around generative AI kept changing fast. OpenAI's image generation environment shifted to being centered on DALL·E 3 and ChatGPT, and the way I'd been experimenting based on DALL·E 2 became harder to continue in the same form. Regardless of how the service environment changed, I decided to build my own generation environment so I could keep pursuing those questions.
To keep experimenting on my own, I needed an environment where I could actually train AI. At the time, a computer with sufficient GPU power was essential for training generative AI models in a local environment, so I bought a new computer and installed an NVIDIA RTX 5070 Ti.
At the time, DALL·E 2 and most other image-generation AIs could only be used through the developer's own servers. Since the process worked by sending a generation request and having the server process and return the result, there was no way for a user to directly intervene in the training process or modify the model with their own data.
Stable Diffusion 1.5 (released October 2022, by RunwayML) was an open-source model that carried that movement forward. It could be run directly on a personal computer, and both generation and training could be carried out locally, without depending on a server. I began LoRA training using this model. LoRA is a method of additionally training a model — one that has already learned from a wide variety of images — on the work of a specific artist, allowing it to reflect a particular style or characteristic without having to retrain the entire model from scratch. It was the most realistic way, at the time, to actually test the questions I'd been carrying.
3. A Shift in How I Looked at Data
As I repeated LoRA training over and over, I discovered something I hadn't expected.
What mattered wasn't simply carrying out the training itself, but how the data was structured, how it was trained, and how the trained model was then used.
A machine doesn't understand an image the way a person does. It learns shape, color, structure, and recurring features by mapping them against the text provided alongside the image. Even with the exact same drawing, the result could change drastically depending on what tags were assigned to it.
Beyond that, the results also varied significantly depending on training conditions like the number of training repetitions (epochs), the learning rate, and the batch size. Even using the same data, the features the model learned would differ depending on how many times it was trained and at what intensity.
Even after training was finished, the outcome wasn't fixed. Generation settings like the CFG scale and denoising strength could produce completely different images from the very same model. I came to realize that the intention behind how an image was generated was also being decided at the output stage itself.
That experience also changed the way I looked at painting. I came to hold both the perspective of someone who paints and the perspective of someone who builds data, at the same time — and I began seeing a single work as data shaped by countless human judgments.
As a result, I came to understand that a single image isn't made from data alone. Data composition and tagging, training conditions, output settings — countless choices combine together to produce a single result.
From that point on, I also began to see a work as being, at the same time, both a painting and a piece of data. That thought naturally led to the question, "How should a work be recorded within a larger AI model?" A single image carries within it countless choices and judgments made during its production, and I came to think that recording that in a form a machine could read was also important work.
Parameters: Model: Stable Diffusion 1.5 <lora:jeongseon_564_70_1:1> geumgangjeondo <lora:painting_v2:1> eastbrush, landscape Steps: 20, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 7, Seed: 1716447084, Size: 896x552, Model hash: 6ce0161689, Model: v1-5-pruned-emaonly, Lora hashes: "jeongseon_564_70_1: da2f49104b3a, painting_v2: b359cdda2556", Version: v1.10.1
4. Data Design
As I came to understand the importance of tags, my interest naturally extended toward foundation models.
If LoRA is a way of training on the style of a particular artist or the characteristics of a particular image, foundation models operate on a far larger scale of data. So how should data be recorded for a foundation model? How should my own drawings be organized? What would it take for my work to someday be read as data within an even larger model?
While carrying out LoRA training, I had many conversations about AI and ways of recording data. Through that process, I came to understand that tags alone — the kind used for LoRA training — weren't enough, and that if I was thinking about a much larger-scale model, I would need a structure capable of recording not just the correspondence between image and text, but the production process, lineage, and metadata as well. That question eventually led to the larger problem of how to design the data itself.
To manage data over the long term and record the relationships between pieces, I needed a standard by which every image could be identified within a consistent structure. So I began assigning a unique ID to every image.
Also, if only the final result is saved, the judgments and changes made during the production process go unrecorded. So I designed a structure that managed the result, the production process, and reference materials as separate layers.
The finished drawings and paintings, the final results, I defined as the Main Line. The Main Line is the central body of work in the archive, and every other piece of data was designed to connect back to it as its reference point.
The structural-analysis drawings and experimental results produced during the making process I separated out as the Sub Line. The Sub Line isn't finished work — it's data meant to record the production process, used as a supporting structure for understanding the Main Line.
External materials referenced in making the work — photographs, classical paintings, museum materials, texts — I separated out as the Reference Line. This layer isn't the work itself, but a structure meant to record what materials the work was based on.
Each image wasn't just saved as an independent file — it was designed to also record its relationships with other images. I began connecting, in the form of a lineage, which drawing led to which painting, which photographs and generated images were referenced, and how one work expanded into another.
In this way, I built a structure that could manage not just the final results, but the production process and reference materials, all as a single body of data. I judged that recording the process by which a work comes into being was, alongside leaving the work itself behind, an important purpose of the archive.
5. A Change in the Work Itself
From that point on, the scope of the work itself changed too.
Drawing, mounting the paper, photographing the finished pieces, scanning reference materials, editing images, organizing file names, assigning IDs, writing metadata, linking lineage, reviewing data errors — all of this became a single, unified task.
After about three months of drawing, I'd spend roughly the next month on recording and organizing data. It's a stretch of time where it gets hard to tell whether I'm a painter or a data manager.
As time went on, I came to feel that what I was building wasn't a list of finished works. What mattered wasn't the completed image alone — I came to think it was also necessary to record why the image had been made, what it referenced, what choices and judgments had been involved, and what path it had traveled through to get there.
In other words, I came to think that what needed to be recorded was the entire ecosystem behind how a single image comes into being. A work is one result, but that result is made within a process where production, reference materials, experiments, and countless choices and judgments are all connected.
6. The Present
There was never a plan from the start to build an archive like the one that exists now. The curiosity that started with a few questions led to building a generation environment, which expanded into LoRA training and tagging, metadata design, and the archive structure as it stands today.
Even now, I keep making work, and keep recording the process as data that a machine can read.
As I kept going with this work, one thought took shape: that an era might be coming when it's possible to leave behind not just the work itself, but the mechanism by which the work comes into being.
For the platform to publish the data, I chose Hugging Face. It's currently the most widely used platform for AI researchers and developers to directly access datasets, and it allows for version control and the publication of structured datasets. And I hope that this record might someday be of use to someone — even if that someone turns out to be a machine....
Eastbrush Archive (Hugging Face Dataset)
https://huggingface.co/datasets/eastbrush/eastbrush_archive
20260629
数据设计
1. 生成式AI与最初的疑问
如今的这个档案库，并不是从一开始就计划好的项目。
它的起点，意外地简单。
2022年，我得知用生成式AI Midjourney制作的作品《空间歌剧院》在美国科罗拉多州博览会美术比赛的数字艺术类别中获得了一等奖。比起获奖本身更令我震惊的是，作者一开始并没有公开自己使用了AI这一事实。这起事件在整个美术界引发了一场争论——用生成式AI制作出的图像能否被视为艺术作品，以及创作的主体究竟是谁——而这也成了我真正开始关注生成式AI的契机。
也是在这个时期，我开始使用DALL·E 2。通过它的"图生图"（image-to-image）功能——输入我自己画的画，让它在此基础上生成新的图像——我第一次体验到自己的画在机器内部被变形重塑的过程。这并不是单纯的复制功能。我能清楚看到自己画出的形态和色彩，朝着我未曾预料到的方向被重新组合，也由此接触到了此前从未经历过的创作方式。
在这个过程中，我产生了几个疑问：
- AI到底学习了什么，才能生成这样的图像？输入（Input）究竟经过怎样的内部过程，才转化为输出（Output）？
- 不连接服务器，只在个人电脑（本地环境）中，是否也能生成图像？将来是否能打造出像私人助手那样可以自主运行的生成环境？
- 是否可能只挑选特定的画作来进行训练？
- 如果可以，那么用自己的画直接进行训练，会得到怎样的结果？
- 如果AI是依据反复出现的形态和模式来生成图像的，那么我自己未曾察觉到的、属于我作品的特征或反复出现的结构，是否也可能由此显现出来？
2. 构建生成环境与LoRA训练
然而，就在我寻找这些问题答案的过程中，生成式AI所处的环境也在飞速变化。OpenAI的图像生成环境逐渐转向以DALL·E 3和ChatGPT为中心，我之前以DALL·E 2为基础的实验方式，也越来越难以继续以原来的形式进行下去。无论服务环境如何变化，为了能继续追问下去，我决定自己搭建一套生成环境。
要继续独立进行实验，就需要一个能够真正训练AI的环境。当时，要在本地环境中训练生成式AI模型，必须具备足够强大的GPU性能，因此我购入了一台新电脑，并装上了NVIDIA RTX 5070 Ti显卡。
当时，包括DALL·E 2在内的大多数图像生成AI，都只能通过开发公司的服务器来使用。由于运作方式是发送生成请求、由服务器处理后再返回结果，用户根本无法直接介入训练过程，也无法用自己的数据去修改模型。
Stable Diffusion 1.5（2022年10月，由RunwayML发布）正是延续了这一转变趋势的开源模型。它可以直接在个人电脑上运行，无需依赖服务器，便能独立完成生成和训练。我以这个模型为基础，开始了LoRA训练。LoRA是一种在已经学习过大量图像的模型基础上，额外只训练特定作者作品的方法——不必重新训练整个模型，就能反映出某种特定的画风或特征。这是当时能够直接验证我心中那些疑问的、最现实的方法。
3. 看待数据方式的转变
就这样，在反复进行LoRA训练的过程中，我发现了一件出乎意料的事。
重要的并不只是单纯执行训练这件事本身，而是数据如何构成、以怎样的方式进行训练，以及训练好的模型又该如何使用。
机器并不会像人一样去理解图像。它是通过将图像与随之提供的文本相互对应，来学习形态、色彩、结构以及反复出现的特征。即便是同一幅画，赋予的标签不同，结果也会大相径庭。
不仅如此，训练次数（Epoch）、学习率（Learning Rate）、批次大小（Batch Size）等训练条件也会让结果产生巨大差异。即便使用相同的数据，根据反复训练的次数和强度不同，模型所学习到的特征也会有所不同。
训练结束之后，结果也并非一成不变。根据CFG Scale、Denoising Strength等生成设置的不同，即便是同一个模型，也会输出完全不同的图像。我由此意识到，想要用怎样的意图去生成图像，其实也是在输出阶段一并被决定的。
这段经历也改变了我看待绘画的方式。我开始同时拥有作画者的视角和数据构建者的视角，并开始把一件作品看作是融入了无数人为判断的数据。
最终我理解到，一幅图像并不是单靠数据就能完成的——数据构成与标签、训练条件、输出设置等无数的选择相互结合，才共同造就了一个结果。
从那时起，我也产生了一种观点：作品同时既是绘画，也是一份数据。这个想法自然而然地引向了一个问题——"在更大规模的AI模型中，作品应该如何被记录？"一张图像之中，蕴含着创作过程里无数的选择与判断，而我开始认为，将其以机器可读的形式记录下来，同样是一项重要的工作。
Parameters: Model: Stable Diffusion 1.5 <lora:jeongseon_564_70_1:1> geumgangjeondo <lora:painting_v2:1> eastbrush, landscape Steps: 20, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 7, Seed: 1716447084, Size: 896x552, Model hash: 6ce0161689, Model: v1-5-pruned-emaonly, Lora hashes: "jeongseon_564_70_1: da2f49104b3a, painting_v2: b359cdda2556", Version: v1.10.1
4. 数据设计
随着我逐渐理解标签的重要性，我的关注点也自然延伸到了基础模型（foundation model）上。
如果说LoRA是用来训练特定作者画风或特定图像特征的方式，那么基础模型则是建立在规模远为庞大的数据之上运作的。那么在基础模型当中，数据又该以怎样的方式被记录？我的画又该以怎样的结构被整理？将来，要让我的作品在更大的模型中也能被读作一份数据，究竟需要些什么？
在进行LoRA训练的过程中，我多次围绕AI与数据的记录方式展开对话。在这个过程中，我逐渐明白，仅靠LoRA训练所用的标签是远远不够的——如果考虑到规模更大的模型，就需要一种结构，不仅能记录图像与文本之间的对应关系，还能同时记录创作过程、谱系以及元数据。这个问题最终引向了一个更大的课题：如何设计数据。
为了能长期管理数据，并记录数据之间的相互关系，我需要一个能够在统一结构下识别每一幅图像的标准。因此，我开始为每一幅图像赋予唯一的ID。
此外，如果只保存最终成果，那么创作过程中所做出的判断与变化就无法被记录下来。因此，我设计了一套结构，将成果、创作过程与参考资料分别作为不同层级来管理。
最终成果——也就是完成的素描与绘画作品，我将其定义为主线（Main Line）。主线是这个档案库的核心作业，其他所有数据都被设计为以此为基准相互连接。
在创作过程中产生的结构分析素描和实验性成果，我将其分离为副线（Sub Line）。副线并非完成的作品，而是用来记录创作过程的数据，作为辅助结构，用于理解主线。
创作中参考的照片、古典绘画、博物馆资料、文献等外部素材，我将其分离为参考线（Reference Line）。这一层级本身并非作品，而是用来记录这件作品究竟是基于哪些资料而完成的结构。
每一幅图像，不仅仅是作为独立文件保存，我还设计将它们彼此之间的关系一并记录下来。我开始以谱系（Lineage）的形式，记录一幅素描最终发展成了哪幅绘画、参考了哪些照片与生成图像，以及一件作品又是如何延展为另一件作品的。
通过这样的方式，我建立起一套结构，能够将成果本身，以及创作过程和参考资料，全部作为一份完整的数据来管理。我判断，记录一件作品诞生的过程，与留下作品本身一样，同样是这个档案库的重要目的。
5. 工作的转变
从那时起，工作的范围也随之发生了变化。
画画、装裱、为作品拍照、扫描参考资料、编辑图像、整理文件名、赋予ID、撰写元数据、连接谱系、检查数据错误——这一系列流程，都变成了同一项工作的一部分。
画上三个月的画之后，接下来大约一个月的时间，几乎都要用在记录和整理数据上。那是一段连自己都分不清，究竟是画家还是数据管理员的时间。
随着时间推移，我渐渐觉得，自己正在构建的，并不是一份已完成作品的清单。重要的并不仅仅是完成的图像本身——我开始认为，还需要一并记录这幅图像为何被创作出来、参考了什么、经过了怎样的选择与判断，以及又经历了怎样的路径产生了变化。
也就是说，我认为有必要把一幅图像诞生之前的整个生态都一并记录下来。作品固然是一个结果，但这个结果，是在创作过程、参考资料、实验，以及无数选择与判断相互连接的过程之中，才最终诞生的。
6. 现在
从一开始，我并没有打算建立一个如今这样的档案库。从几个疑问出发的好奇心，引向了生成环境的搭建，又扩展为LoRA训练与标签处理、元数据设计，最终发展成了如今的档案库结构。
直到现在，我仍在持续创作，并将这一过程记录为机器可读的数据。
随着工作的持续，我心中渐渐生出一个想法：未来或许会到来这样一个时代——不仅能留下作品本身，也能将作品诞生的机制一并留存下来。
至于公开数据所使用的平台，我选择了Hugging Face。因为它是目前AI研究者和开发者们直接访问数据集时使用最广泛的平台，并且支持版本管理与结构化数据集的公开发布。我希望，这份记录将来能够对某个人有所用处——即便那个"某个人"，是一台机器……
Eastbrush Archive (Hugging Face Dataset)
https://huggingface.co/datasets/eastbrush/eastbrush_archive
20260629
データ設計
1. 生成AIと最初の問い
今のこのアーカイブは、最初から計画されたプロジェクトではなかった。
出発点は、意外にも単純だった。
2022年、生成AI「Midjourney」で制作された《Théâtre D'opéra Spatial》が、アメリカ・コロラド州フェアの美術コンペティション、デジタルアート部門で1位を受賞したというニュースに触れた。受賞そのものよりも衝撃だったのは、制作者が最初にAIを使用したという事実を明らかにしていなかったという点だった。この出来事は、生成AIによって作られた画像を芸術作品として見ることができるのか、そして創作の主体は誰なのかという論争を美術界全体に広げ、私自身も生成AIに本格的に関心を持つきっかけとなった。
この頃、DALL·E 2を使い始めた。自分の描いた絵を入力すると、それをもとに新しい画像を生成するimage-to-image機能を通して、初めて自分の絵が機械の中で変形していく過程を体験した。それは単に絵を複製する機能ではなかった。自分が描いた形や色彩が、予想していなかった方向へ再構成されていく様子を確認することができ、これまでに経験したことのない制作方法に触れることになった。
その過程で、いくつかの疑問が生まれた。
- AIは何を学習したからこそ、こうした画像を生成するのだろうか。入力（Input）はどのような内部過程を経て結果（Output）へとつながっているのか。
- サーバーに接続せず、個人のコンピュータ（ローカル環境）でも画像を生成できるだろうか。いつかは個人秘書のように、自ら運用できる生成環境を作ることができるのだろうか。
- 特定の絵だけを選んで学習させることも可能なのだろうか。
- それならば、自分の絵を直接学習させたら、どんな結果が出るのだろうか。
- AIが反復される形やパターンをもとに画像を生成するのであれば、自分が意識していなかった自分の作業の特徴や、反復される構造も浮かび上がってくるのではないか。
2. 生成環境の構築とLoRA学習
しかし、その疑問への答えを探している間も、生成AIを取り巻く環境は急速に変化していた。OpenAIの画像生成環境はDALL·E 3とChatGPT中心に再編され、私が使っていたDALL·E 2をベースにした実験方法も、これまでと同じ形で続けることが難しくなっていった。サービス環境の変化とは関係なく、その問いを続けていくために、自分自身で生成環境を構築することにした。
自分で実験を続けていくためには、AIを学習させられる環境が必要だった。当時は、生成AIモデルをローカル環境で学習させるために十分なGPU性能を備えたコンピュータが必須だったため、新しいコンピュータを購入し、NVIDIA RTX 5070 Tiを搭載した。
当時、DALL·E 2をはじめとするほとんどの画像生成AIは、開発会社のサーバーを通してのみ使用できるものだった。生成リクエストを送るとサーバーが処理して結果を返す仕組みだったため、ユーザーが学習過程に直接介入したり、自分のデータでモデルを修正したりすることは不可能だった。
Stable Diffusion 1.5（2022年10月、RunwayML配布）は、その流れを受け継いだオープンソースモデルだった。個人のコンピュータで直接実行することができ、サーバーに依存せず生成と学習を自分で行うことができた。このモデルをもとにLoRA学習を始めた。LoRAは、すでに多様な画像を学習したモデルに、特定の作家の作品だけを追加で学習させる方式で、既存のモデル全体を再学習させなくても、特定の画風や特徴を反映させることができた。これは、当時自分が抱いていた疑問を直接検証してみるための、最も現実的な方法だった。
3. データを見る視点の変化
そうしてLoRA学習を繰り返す過程で、予想していなかった事実を発見した。
重要なのは、単に学習を行うことそのものではなく、データをどのように構成し、どのような方法で学習させ、学習させたモデルをどう活用するかということだった。
機械は画像を人間のように理解するわけではない。画像とともに与えられるテキストを対応させながら、形や色彩、構造、反復される特徴を学習する。同じ絵であっても、どんなタグを付けるかによって結果は大きく変わった。
それだけでなく、学習回数（Epoch）、学習率（Learning Rate）、バッチサイズ（Batch Size）といった学習条件によっても、結果は大きく変わった。同じデータを使っていても、どれだけ繰り返し学習させ、どのくらいの強度で学習させるかによって、モデルが学習する特徴が変わっていった。
学習が終わった後も、結果は固定されなかった。CFG Scale、Denoising Strengthといった生成設定によって、同じモデルからでもまったく異なる画像が出力された。どのような意図で画像を生成するのかも、出力の過程で同時に決定されるという事実を知った。
その経験は、絵を見る視点にも変化をもたらした。絵を描く人としての視点と、データを構築する人としての視点を同時に持つようになり、ひとつの作品を、無数の人間の判断が介在したデータとして見るようになった。
結果として、ひとつの画像は単にデータだけで作られるものではなかった。データの構成とタグ付け、学習条件、出力設定など、無数の選択が組み合わさって、ひとつの結果が生み出されるのだということを理解するようになった。
そのときから、作品は絵画であると同時に、ひとつのデータでもあるという見方も生まれた。その考えは自然に、「より大きなAIモデルにおいて、作品はどのように記録されるべきか」という問いへとつながっていった。一枚の画像には、制作過程で行われた無数の選択と判断が込められており、それを機械が読める形で記録することも、重要な作業だと考えるようになった。
Parameters: Model: Stable Diffusion 1.5 <lora:jeongseon_564_70_1:1> geumgangjeondo <lora:painting_v2:1> eastbrush, landscape Steps: 20, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 7, Seed: 1716447084, Size: 896x552, Model hash: 6ce0161689, Model: v1-5-pruned-emaonly, Lora hashes: "jeongseon_564_70_1: da2f49104b3a, painting_v2: b359cdda2556", Version: v1.10.1
4. データ設計
タグの重要性を理解していくうちに、関心は自然とファウンデーションモデルへと向かっていった。
LoRAが特定の作家の画風や特定の画像の特徴を学習させる方式だとすれば、ファウンデーションモデルは、はるかに大規模なデータをもとに動作する。それならば、ファウンデーションモデルにおいてはどのような方法でデータを記録すべきなのか。自分の絵はどのような構造で整理されるべきなのか。いつか、より大きなモデルの中でも自分の作業がひとつのデータとして読まれるためには、何が必要なのか。
LoRA学習を進めながら、AIとデータの記録方法について何度も対話を重ねた。その過程で、LoRA学習のためのタグだけでは十分ではなく、より大規模なモデルを念頭に置くなら、画像とテキストの対応関係だけでなく、制作過程や系譜、メタデータまで一緒に記録できる構造が必要だということを理解するようになった。その問いは、結局データをどう設計するかという問題へとつながっていった。
データを長期間管理し、互いの関係を記録するためには、すべての画像を一貫した構造で識別できる基準が必要だった。そこで、すべての画像に固有のIDを付与し始めた。
また、最終的な結果物だけを保存すると、制作過程で行われた判断や変化は記録されない。そこで、結果物と制作過程、参考資料を、それぞれ異なる階層として区別して管理する構造を設計した。
最終的な結果物であるドローイングと絵画は、メインライン（Main Line）として定義した。メインラインはアーカイブの中心となる作業であり、それ以外のすべてのデータは、これを基準として接続されるように設計した。
制作過程で生まれる構造分析ドローイングや実験的な結果物は、サブライン（Sub Line）として分離した。サブラインは完成した作品ではなく、制作過程を記録するためのデータであり、メインラインを理解するための補助構造として用いた。
作品制作に参考した写真、古典絵画、博物館資料、文献などの外部資料は、レファレンスライン（Reference Line）として分離した。この階層は作品そのものではなく、その作業がどんな資料をもとに行われたのかを記録するための構造である。
それぞれの画像は、独立したファイルとして保存するだけにとどめず、互いの関係まで一緒に記録するように設計した。あるドローイングがどの絵画につながったのか、どんな写真や生成画像を参考にしたのか、そしてある作品が再び別の作品へとどのように広がっていったのかを、系譜（Lineage）の形でつなぎ始めた。
こうして、結果物だけでなく、制作過程や参考資料までをひとつのデータとして管理できる構造を作った。作品を残すことと同時に、作品が作られていく過程を記録することも、アーカイブの重要な目的だと判断したからだ。
5. 作業の変化
そのときから、作業の範囲も変わっていった。
絵を描き、裏打ちをし、作品を撮影し、参考資料をスキャンし、画像を編集し、ファイル名を整理し、IDを付与し、メタデータを作成し、系譜をつなぎ、データの誤りを検収する過程が、ひとつの作業となった。
3か月間絵を描くと、その後の約1か月は記録とデータ整理に使うほどになった。画家なのか、データ管理者なのか、区別が曖昧になる時間だ。
時間が経つにつれて、自分が作っているのは完成した作品の一覧ではないと思うようになった。重要なのは、完成した画像そのものだけではなかった。その画像がなぜ作られたのか、何を参考にしたのか、どんな選択と判断が行われたのか、そしてどんな経路を経て変化したのかまで、一緒に記録する必要があると考えるようになった。
つまり、ひとつの画像が作られるまでの生態系を、一緒に記録すべきだと考えた。作品はひとつの結果物だが、その結果物は制作過程と参考資料、実験、そして無数の選択と判断がつながり合う過程の中で作られるものだからだ。
6. 現在
最初から今のようなアーカイブを作る計画があったわけではない。いくつかの問いから始まった好奇心は生成環境の構築へとつながり、LoRA学習とタグ付け、メタデータ設計、そして今のアーカイブ構造へと広がっていった。
今も私は作品を制作し、その過程を機械が読めるデータとして記録している。
作業を続けるうちに、ひとつの考えが生まれた。これからは、作品を残すことだけでなく、作品が作られるメカニズムも一緒に残せる時代が来るのではないか、という考えだ。
データを公開するプラットフォームには、Hugging Faceを選んだ。現在、AI研究者や開発者がデータセットに直接アクセスするプラットフォームとして最も広く使われており、バージョン管理と構造化されたデータセットの公開が可能だからだ。そして、この記録がいつか誰かの役に立つことを願っている。その誰かが、機械であったとしても……。
Eastbrush Archive (Hugging Face Dataset)
https://huggingface.co/datasets/eastbrush/eastbrush_archive
20260629