제가 과학적 이미지 모델(scientific image models)을 테스트할 때 계속 사용하는 프롬프트는 짧습니다: "MAPK 경로를 그려줘."

이 문장은 대부분의 중요한 결정 사항들을 명시하지 않은 채 남겨둡니다. 어떤 분기가 중요한가요? 어떤 세포 유형(cell type)에 대해 이야기하고 있나요? 화살표가 활성화(activation), 이동(transport), 또는 단순히 "다음에 이 일이 일어난다"를 의미하나요? 이 그림이 알려진 메커니즘을 설명하는 것인가요, 아니면 하나의 실험을 요약하는 것인가요?

모델은 이러한 누락된 결정들을 스스로 내릴 수 있습니다. 그 결과물은 세련되어 보일 수는 있지만, 과학적으로는 여전히 쓸모가 없을 수 있습니다.

그림은 마지막 단계입니다

텍스트-투-피겨(text-to-figure) 생성 작업을 시작했을 때, 저는 렌더링(rendering)을 생각하는 데 대부분의 시간을 보냈습니다. 선의 품질, 간격, 색상, 내보내기 크기 같은 것들 말이죠. 일주일도 채 되지 않아, 저는 픽셀(pixel)보다 화살표를 확인하는 데 더 많은 시간을 쓰고 있었습니다.

유용한 중간 산출물(intermediate artifact)은 작은 피겨 사양(figure specification)이라는 것이 밝혀졌습니다. 저의 사양은 종종 다음과 같이 간단하게 시작합니다:

{
  "purpose": "MEK 억제가 하위 ERK 신호 전달에 어떻게 변화를 주는지 보여줌",
  "entities": ["MEK", "ERK", "전사 인자 (transcription factor)"],
...

이것은 프로덕션용 스키마(production schema)가 아닙니다. 모델이 매력적인 픽셀 아래에 결정을 숨기기 전에, 결정을 드러내기 위한 빠른 방법입니다.

만약 목적(purpose)을 한 문장으로 쓸 수 없다면, 그 그림은 대개 너무 많은 일을 수행해야 하는 상태입니다. 레이블(label)의 크기를 줄인다고 해서 해결되지 않습니다. 대신 저는 그림을 분리합니다.

화살표에는 타입이 필요합니다

화살표는 그리기에 가장 쉬운 도형 중 하나이자, 잘못된 주장을 하기 가장 쉬운 방법 중 하나입니다.

워크플로우(workflow)에서 화살표는 순서를 의미할 수 있습니다. 경로(pathway)에서 화살표는 활성화(activation) 또는 억제(inhibition)를 의미할 수 있습니다. 장비 다이어그램(equipment diagram)에서 화살표는 물질의 흐름(material flow)을 의미할 수 있습니다. 이러한 의미들은 단순히 동일한 SVG 경로를 공유한다고 해서 서로 교체 가능해서는 안 됩니다.

개발자에게 있어, 관계(relation)는 고유한 타입(type)을 가질 가치가 있습니다:

type Edge = {
  from: string
  to: string
...

이 타입은 두 가지 유용한 역할을 합니다. 렌더러(renderer)가 시각적 관습(visual convention)을 선택할 수 있게 해주고, 검증기(validator)에게 조사할 수 있는 구체적인 대상을 제공합니다. 모호한 "이 노드들을 연결하라"는 지침은 우리에게 그 어느 것도 제공하지 못합니다.

또한 가능한 한 색상(color)에서 관계의 의미를 배제합니다. 색상은 흑백 인쇄, 성능이 낮은 프로젝터, 그리고 색각 차이가 있는 일부 독자들에게는 보이지 않기 때문입니다. 화살표 머리(arrowheads), 선 스타일(line styles), 그리고 레이블(labels)이 의미를 전달해야 합니다. 색상이 도움을 줄 수는 있지만, 유일한 전달 수단이 되어서는 안 됩니다.

증거(Evidence)와 설명(explanation)은 다르게 취급되어야 합니다

과학 논문은 여러 종류의 시각 자료를 혼합하여 사용합니다. 차트(chart)는 측정값을 제시합니다. 현미경 이미지(microscopy image)는 관찰 내용을 기록합니다. 메커니즘 다이어그램(mechanism diagram)은 저자가 구성 요소들이 어떻게 결합되어 있다고 생각하는지를 설명합니다.

문제는 생성된 삽화가 측정된 데이터(measured data)의 시각적 권위(visual authority)를 빌려올 때 시작됩니다.

상세한 수용체 모델(receptor model)은 실제로는 측정되지 않은 구조적 정밀함(structural precision)을 암시할 수 있습니다. 사실적인 해부학적 단면도(anatomical cutaway)는 일반적인 모델임에도 불구하고 특정 환자에게 특화된 것처럼 보일 수 있습니다. 렌더링(render)이 설득력 있을수록, 이러한 차이를 놓치기 더 쉬워집니다.

이제 저는 그림(figure)에 들어가는 모든 요소에 소스 카테고리(source category)를 부여합니다.

• 현재 연구에서 측정됨 (measured in the current work)
• 인용된 문헌에 의해 뒷받침됨 (supported by cited literature)
• 해석 또는 가설 (interpretation or hypothesis)
• 방향 지시용일 뿐임 (orientation only)

이러한 카테고리에 따라 선의 굵기(line weight), 레이블(labels), 캡션(captions), 그리고 인용(citations)이 달라질 수 있습니다. 또한 이는 검토(review)를 더 쉽게 만듭니다. 공동 저자는 전체 구성에 대해 논쟁하지 않고도 특정 카테고리에 대해 이견을 제시할 수 있습니다.

설명용 그림(explanatory figures)의 경우, 저는 영화 같은 렌더링(cinematic render)보다 단순한 라인 아트(line art)를 선호하는 경우가 많습니다. 시각적 디테일이 낮을수록 의도치 않은 주장(accidental claims)을 할 여지가 줄어들기 때문입니다.

저의 검증 루프(validation loop)는 의도적으로 지루합니다

예전에는 어떤 버전이 마음에 들 때까지 그림을 계속 다시 생성하곤 했습니다. 그러한 루프는 외형(appearance)에 보상을 줍니다. 깔끔한 레이아웃은 잘못된 연결(wrong connection)로부터 저자의 주의를 분산시킬 수 있습니다.

이제 저는 다음 네 가지를 순서대로 확인합니다:

1. 위상(topology)이 정확한가?
2. 레이블(labels)이 논문이나 소스 자료와 일치하는가?
3. 모든 화살표가 무엇을 의미하는지 설명할 수 있는가?
4. 그림이 최종 크기에서 읽기 쉬운가?

오타는 보통 국소적인 수정(local edit)으로 해결됩니다. 하지만 위상 오류(topology error)는 그림을 다시 사양(specification) 단계로 되돌려 보냅니다. 잘못된 그래프의 그림자(shadows)를 조정하는 것은 아무런 의미가 없습니다.

최종 크기 확인(final-size check) 단계에서 예상보다 더 많은 문제들이 발견됩니다. 전체 브라우저 창에서는 보기 편해 보이는 그림이 2단 구성의 논문(two-column paper) 안에서는 무너질 수 있습니다. 저는 에디터 뷰(editor view)가 아니라, 내보내기(exported)된 크기를 테스트합니다.

생성(Generation)의 위치

생성형 도구(Generative tools)는 메커니즘 스케치(mechanism sketches), 실험 워크플로(experimental workflows), 장비 개념(equipment concepts), 그리고 초기 그래픽 초록(graphical-abstract) 초안을 작성하는 데 유용합니다. 이 도구들은 빈 캔버스에서 팀이 논의할 수 있는 무언가를 만들어내는 데 드는 비용을 줄여줍니다.

하지만 데이터 기반 차트(data-driven charts), 독창적인 현미경 사진(original microscopy), 진단 이미지(diagnostic images), 또는 정확한 화학 구조(exact chemical structures)를 대체하기에는 부족합니다. 그러한 시각 자료들은 기초 데이터나 전문 소프트웨어(specialist software)로부터 나와야 합니다. 생성된 이미지는 증거를 설명할 수는 있지만, 증거 자체를 사칭해서는 안 됩니다.

결국 저는 이 워크플로의 일부를 Scientific Figure Generator에 구축했습니다. 이 도구는 텍스트로부터 라인 아트(line art), 플랫 일러스트레이션(flat illustrations), 그리고 3D 스타일의 초안을 생성할 수 있습니다. 저는 완성된 것처럼 보이는 결과물이라 할지라도 여전히 모든 결과물을 초안으로 취급합니다.

제가 계속해서 고민하게 되는 제품적 질문은 '얼마나 많은 구조(structure)를 노출할 것인가'입니다. 구조가 너무 적으면 허구의 관계(invented relationships)를 초래하기 쉽습니다. 반대로 구조가 너무 많으면 빠른 시각화 작업이 수십 개의 필드가 있는 긴 양식(long form)으로 변해버립니다. 저는 이 트레이드오프(tradeoff)에 보편적인 정답이 있다고 생각하지 않습니다.

현재 저의 규칙은 간단합니다. 생성된 다이어그램이 논문이나 발표 자료에 도달하기 전에, 그 안의 모든 관계(relationship)는 반드시 출처(source)가 있어야 합니다. 만약 출처를 찾을 수 없다면, 그 그림은 준비되지 않은 것입니다.

여러분의 도구에서 AI가 다이어그램을 생성할 때, 의미론적 검증(semantic validation)을 어떻게 처리하고 계신가요?

공개 사항: 저는 영문 편집을 돕고 초안을 다듬기 위해 AI 글쓰기 어시스턴트(AI writing assistant)를 사용했습니다. 예시, 워크플로 및 제품 결정 사항은 과학 시각화 도구(scientific-visualization tools)를 구축하는 저의 작업에서 비롯되었습니다.