프로그래밍 언어로서의 룬(Runes) (그리고 비유가 깨지는 지점)
요약
룬 문자를 활용한 시스템 구축 사례를 통해, LLM의 환각 문제를 해결하기 위한 구조적 접근법을 제시합니다. 출처(provenance) 정보를 단순 메타데이터가 아닌 생성 단계의 제약 조건으로 활용하는 '타입 시스템' 방식의 중요성을 강조합니다.
핵심 포인트
- LLM의 정확성은 프롬프트가 아닌 구조적 제약으로 해결해야 함
- 출처 정보는 생성 과정에 직접 개입하는 타입 시스템 역할을 해야 함
- 검색 시스템 구축 시 출처는 단순 메타데이터를 넘어 컨텍스트에 포함되어야 함
- 유니코드 룬 블록의 렌더링 이슈 등 실무적 고려 사항 존재
저는 룬 문자가 새겨진 비문(runic inscriptions)을 일종의 결합 가능한 시스템(composable system)처럼 취급하는 프로젝트를 관리하고 있습니다. 즉, 사용자가 의도(intent)를 기술하면 시스템이 룬을 선택하고 이를 순서대로 배열하는 방식입니다. 저는 이를
historical-fact(역사적 사실): 비문(inscriptions)이나 학술적 룬학(runology)에 의해 증명되었으며, 인용(citation)이 포함됨revival-claim(부활 주장): 현대에 만들어졌으며, 누가 언제 발명했는지 기록됨practice-instruction(실행 지침): 현대의 수행자가 실제로 무엇을 하는지mechanism-evidence(기제 증거): 특정 수행이 왜 효과를 낼 수 있는지에 대한 심리학적 근거ethnographic-data(민족지 데이터): 공동체가 무엇을 한다고 보고하는지, 관찰 결과로 유지됨
출처가 없는 진술은 조용히 홍보되는 대신 '검증되지 않음(unverified)'으로 표시됩니다. 학술적 출처가 서로 상충할 경우, 두 해석 모두 경쟁적인 해석으로서 유지되며 누구도 승자를 결정하지 않습니다.
기능적으로 이것은 타입 시스템 (type system)입니다. 컴파일러를 통과하지는 못하겠지만, 동일한 역할을 수행합니다. 즉, 불가능한 상태(illegal state)를 표현 불가능하게(unrepresentable) 만듭니다. 여기서 불가능한 상태란, 고대의 사실로 둔갑한 현대의 발명품을 의미합니다.
LLM이 개입될 때 이것이 선택 사항이 아닌 이유
언어 모델 (language model)을 이와 같은 코퍼스 (corpus)에 적용하고 룬에 대한 문단을 작성하라고 요청해 보십시오. 제약 조건이 없다면, 9세기 비문과 1930년대의 비전적(esoteric) 발명품을 눈에 보이는 경계 없이 결합한, 유창하고 자신감 넘치는 텍스트를 얻게 될 것입니다. 모델이 고장 난 것이 아닙니다. 그러한 혼합이 바로 모델의 학습 데이터 (training data)가 보여주는 모습입니다. 소스들을 수집하면서 추정해 보건대, 온라인에 있는 룬 관련 정보의 약 90%는 자신만만하게 틀린 정보입니다. 따라서 통계적으로 가능성이 높은 문장 역시 자신만만하게 틀린 문장이 됩니다.
프롬프트 (prompt)에 "정확하게 작성해 주세요"라고 적는 것으로는 이 문제를 해결할 수 없습니다. 정확성 (accuracy)은 스타일이 아닙니다. 저에게 해결책이 된 것은 구조적인 것이었습니다. 출처 태그 (provenance tag)가 주장과 함께 모델의 컨텍스트 (context)로 전달되며, 생성 (generation) 과정이 그 태그에 의해 제약됩니다. 모델에게 무엇이 고대 것인지 알라고 요구하지 않습니다. 대신 모델에게는 이미 인식론적 상태 (epistemic status)를 지닌 주장들이 전달됩니다.
논쟁의 여지가 있는 코퍼스 위에서 검색 (retrieval) 시스템을 구축한다면, 전이 가능한 핵심은 이것입니다: 출처 (provenance)는 푸터 (footer)에 머무는 메타데이터 (metadata)여서는 안 됩니다. 그것은 반드시 생성 단계까지 도달해야 합니다. 모델이 결코 볼 수 없는 사이드카 테이블 (sidecar table)에 있는 태그는 타이핑 (typing)이 아니라 장식에 불과합니다.
작고, 어리석고, 실제적인 문제: 룬이 렌더링되지 않음
웹에서 역사적 스크립트를 렌더링하는 모든 사람을 위한 실용적인 참고 사항입니다.
Unicode에는 Runic 블록(U+16A0부터 U+16FF까지)이 있습니다. 지원 상태가 정말 좋지 않습니다. 많은 시스템에서 해당 코드 포인트는 '두부 상자'(tofu boxes)로 대체되며, 이 실패는 조용하고 플랫폼에 따라 다릅니다. 사용자님의 기기에서는 괜찮지만, 독자의 3분의 1에게는 깨져 보일 수 있습니다.
이 문제를 해결하는 데 도움이 된 두 가지 방법이 있었습니다.
- 폰트를 직접 제공하세요. 역사적 블록의 경우 시스템 기본값에 의존하지 마세요. 저는 Noto Sans Runic을 번들로 포함했고, 한때 재현할 수 없었던 버그 보고서가 해결된 문제로 바뀌었습니다.
- 렌더링을 제어할 수 없는 텍스트에는 코드 포인트를 넣지 마세요. 소셜 게시물, 신디케이션(syndicated) 복사본 등 제3자가 폰트 스택을 선택하는 모든 곳에서는 룬의 이름을 라틴 문자로 작성하세요. 두부 상자는
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기