LLM 위키 구축 방법

저는 LLM을 이용해 위키를 만들고 Obsidian에서 노트들을 탐색하는 튜토리얼을 통해 이 아이디어를 접했습니다. 해당 영상은 Andrej Karpathy의 LLM Wiki에서 시작되었습니다.

여기서 저는 제 업무상의 어려움과 관련된 경로를 발견했습니다. 바로 다양한 기술과 공급자들이 어떻게 상호 연관되어 있는지 이해하는 것이었습니다. 저는 이 지식을 정리하고, 매번 대화를 할 때마다 모든 것을 재구성하지 않고도 나중에 참조할 수 있도록 해야 했습니다.

이 과정에서 Open Knowledge Format에 대한 영상도 접했습니다. 이 영상은 또 다른 질문을 던졌습니다. 바로 이러한 지식 구조를 도구와 에이전트 간에 어떻게 공유할 것인가 하는 것이었습니다.

여기서는 이 조각들이 어떻게 연결되는지, 그리고 제가 Cereja에서 이미 구현한 내용들을 보여드리겠습니다. 예시는 저의 자체 자료입니다. 작업 문서와 이미지들은 그곳에 있습니다.

읽고, 관계 짓고, 참조할 수 있는 위키

LLM 위키는 출처(sources), 노트, 개념, 그리고 종합된 내용을 관련 페이지들에 모아 놓습니다. 사람들과 에이전트들은 이 기반을 참조하고, 검토 및 업데이트에 대한 규칙을 따르며 유지 관리에 참여할 수 있습니다.

저는 노트를 읽고 링크를 탐색하기 위해 기기에 동기화된 Obsidian을 사용합니다. 그리고 그래프 기능은 정말 대단합니다. 다른 경로로 전체 집합을 탐색할 수 있습니다. 다만, 아름다운 연결 고리를 잘 뒷받침되는 주장과 혼동해서는 안 됩니다. 정보를 확인하려면 출처로 돌아가야 합니다.

Karpathy는 자신의 모델에서 세 가지 구성 요소를 설명했습니다: 보존된 출처(sources preserved), 관련 페이지(related pages), 그리고 에이전트에게 위키를 유지하도록 안내하는 문서입니다. 저는 이 제안을 저의 필요에 맞게 조정했습니다.

위키는 영구적인 지식을 저장합니다. 반면, **에이전트의 컨텍스트(context of the agent)**는 모델이 작업을 수행하는 동안 받는 정보와 지침들의 집합입니다. 기반은 수백 개의 노트를 가질 수 있지만, 하나의 작업에는 몇 개의 노트만 필요할 수 있습니다.

또한 저는 이 기반에서 조각들을 검색하여 모델에게 제시하는 RAG(Retrieval-Augmented Generation), 즉 검색 증강 생성도 사용할 수 있습니다. 지식의 구조화와 그 검색은 서로 다른 기능을 수행합니다.

에이전트 작업에서 위키의 역할

Cereja에서는 핵심(Núcleo)에 지식, 증거, 해석 및 논지를 기록합니다. Editorial Engine은 출판물을 준비하고, Agentic Factory는 에이전트의 역할을 유지하며 시스템 간 공유되는 제어 기능을 담당합니다.

위키는 이러한 아키텍처에서 지식을 검색 가능하게 만듦으로써 참여합니다. 가이드(guides)는 작업을 안내하는데, 이는 특정 작업에 필요한 절차, 순서 및 정보를 설명합니다.

예를 들어: 연구에 대한 텍스트를 준비하려면 에이전트는 출처, 한계점 및 편집 지침이 필요합니다. 에이전트는 요약본을 제안할 수 있습니다. 이 요약본을 Cereja의 입장으로 승인하고 출판을 승인하는 것은 별개의 결정입니다.

이것이 바로 에이전트 계층(camada agêntica)의 역할입니다: 실행 중 검색 및 도구 사용을 조직합니다. 이는 지식을 어디서 찾아야 하는지, 그리고 어떤 작업을 수행할 수 있는지 모두 알아야 합니다.

Cereja의 교육적 도식. 일부 단계는 여전히 수동입니다.

가져오기는 명령으로 시작된다

작업 위키에서 raw/에 문서를 배치하는 것만으로는 가져오기(ingestão)가 발생하지 않습니다. 누군가 처리해 달라고 요청하거나, 또는 제가 작업의 끝을 활용합니다.

시스템이 수행하는 확인(check)은 어떤 노트도 참조하지 않는 파일을 지적합니다. 출처를 의도적으로 폐기할 때는 그 이유를 기록합니다. 이렇게 하면 파일은 역사에서 사라지지 않으면서 더 이상 미결 상태로 나타나지 않습니다.

감시자(watcher)나 예약된 작업이 없습니다. 폴더가 매분마다 바뀌지 않기 때문에, 이 흐름은 제 사용에 충분했습니다.

Cereja에서는 저 역시 같은 트리거, 즉 명령으로 시작했습니다. 추출 및 요약보다 먼저 출처 기록을 구현했습니다.

raw/ # 원본 로컬 파일
sources/ # 출처 및 읽기 메모
tools/ingest_source.py # 수집(ingestion) 명령어
...

이 명령어는 파일의 SHA-256을 계산합니다. 이 해시 값은 해당 바이트를 식별하며 노트 이름에 포함됩니다. 만약 이미 노트가 존재하면, 명령어는 그 경로를 반환하고 메모를 보존합니다.

digest = hashlib.sha256(path.read_bytes()).hexdigest()
destination = target_dir / f"source-{digest}.md"

...

이 작업의 위키는 resource에 기록된 정규화된 출처를 식별자로 사용합니다. Cereja에서는 기능을 분리했습니다: 해시 값은 콘텐츠를 식별하고, 참조(reference)는 그것이 어디에서 왔는지 기록합니다.

이를 통해 다른 바이트를 감지할 수 있지만, 모든 중복을 해결하지는 못합니다. 두 개의 PDF가 같은 연구를 나타낼 수 있습니다. 또한 업데이트가 있을 경우 그 버전들 간의 관계도 설정해야 합니다.

노트는 출처를 명시해야 한다

Cereja의 노트는 draft에서 시작됩니다. 여기에는 제목, 제공된 저자 정보, 원본 경로, 해시 값, 사용 가능한 URL, 선언된 권리, 수집 날짜가 기록됩니다. 명령어는 알 수 없는 필드를 unknown으로 표시합니다.

다음과 같이 자체 구현 예제를 실행할 수 있습니다:

python tools/ingest_source.py examples/wiki-ingestion/source-demo.md \
  --title "Cereja의 수집 예제" \
  --author "Cereja Flamejante" \
...

이 명령어는 한 줄로 작성될 수도 있습니다. --public-note 옵션은 파일 이름과 메타데이터가 공개적으로 나타날 수 있음을 확인합니다. 이는 문서에 대한 권리를 부여하지 않습니다.

raw/의 원본들은 기본적으로 Git 외부에 보관됩니다. PDF를 게시하기 전에 라이선스를 확인해야 합니다. 재배포가 허용되지 않는 경우, 출처의 권리를 존중하며 참조와 저의 원래 분석을 유지할 수 있습니다.

[

첫 번째 단계는 자체 데모 Markdown으로 구현되었습니다. 추출(Extraction)과 종합(Synthesis)은 아직 명령에 포함되어 있지 않습니다.

종합(Synthesis)은 나중에 이루어집니다

이 작업에서는 Poppler의 pdftotext를 사용하여 PDF에서 텍스트를 추출합니다. 이 위키는 OCR 기능을 갖추고 있지 않습니다. 문서가 이미지와 같은 페이지를 포함하는 경우, 모델은 해당 형태로 읽을 수 있습니다.

LLM이 종합 내용을 작성하고 페이지를 참조합니다. 주석(Note)은 문서의 진술과 우리의 해석 및 유보 사항을 분리합니다. 또한 생성된 모델과 토큰 소비량도 기록합니다. 개념 및 개체 주석은 출처 주석으로 연결됩니다.

Cereja에서는 현재 명령이 오직 출처 기록만 생성합니다. 다음 필드들이 이를 보여줍니다:

type: "source"
status: "draft"
certainty: "unverified"
...

아직 이 흐름에서 문서를 추출하거나 요약하지 않았습니다. 읽은 후에는 방법론, 모집단 또는 범위를 기록하고, 각 진술을 뒷받침하는 발췌문을 기록해야 합니다. Cereja의 증거 스키마가 이 검토를 안내합니다.

종합된 내용은 인간의 승인(human promotion)을 거쳐야만 비로소 정식 지식, 즉 시스템이 승인한 참조 자료가 됩니다. 그리고 'Kell에 의해 승인됨'은 'Kell에 의해 작성됨'을 의미하지 않습니다. 저작권 출처는 그대로 유지됩니다.

누가 남아 있는 것을 확인하나요?

작업의 위키에서는 체크(checks)들이 메타데이터, 링크, 주석 크기 및 색인 존재 여부를 검사합니다. 또한 처리되지 않은 출처를 지적하고 파생된 주석이 출처의 제약을 유지하는지 확인합니다.

주석은 draft 상태로 시작합니다. 한 사람이 읽기를 기록하면 review_stage가 됩니다. stable로 승격되려면 인간 책임자가 필요하며, 체크는 모델에 할당된 안정적인 주석을 거부할 수 있습니다. PR(Pull Request)을 여는 사람이 자신의 PR을 승인하지 않습니다.

이러한 검사들은 기반 지식을 유지하는 데 도움이 되지만, 연구 자체를 대신 읽어주지는 못합니다. 링크가 작동하여 부적절한 출처로 연결될 수도 있습니다. 한 사람이 여전히 진술을 뒷받침하는 내용을 평가해야 합니다.

Cereja의 경우, 커버리지(coverage), 권리(rights) 및 프로모션 체크는 여전히 조정하고 테스트해야 합니다. 또한 핵심(Núcleo)이 이미 사용하는 상태들을 존중해야 합니다. 의미를 확인하지 않고 이름을 복사하는 것은 또 다른 혼란을 야기할 것입니다.

모델에 모든 것을 쏟아내지 않고 기반 데이터베이스 조회하기

핵심에서는 작업부터 시작하여 적용 가능한 규칙을 찾고 필요한 자료를 조회합니다. 이 세트가 에이전트의 컨텍스트로 들어갑니다. 나머지 위키는 계속해서 조회가 가능합니다.

Anthropic은 이를 컨텍스트 조직화 전략으로 설명합니다(https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). 또한 한 가지 비용을 지적합니다: 에이전트는 실행 과정 동안 기반 데이터베이스를 탐색해야 합니다.

더 많은 문서가 모든 오류를 해결하지는 못합니다. 때로는 정보 자체가 부족하거나, 다른 경우에는 도구에 의해 적용된 제한이나 결과 검증이 부족할 수 있습니다. 다른 폴더를 추가하기 전에 어떤 부분이 빠져 있는지 알아내야 합니다.

OKF는 이식성 문제를 더한다

Google Cloud가 발표한 Open Knowledge Format (OKF)은 YAML 메타데이터와 개념 간 링크를 사용하여 Markdown으로 지식을 표현하기 위한 규칙을 제안합니다.

이것이 흥미로운 이유는 지식의 형식을 생성하고 조회하는 도구로부터 분리하기 때문입니다. 기반 데이터베이스는 단일 인터페이스에 의존하지 않고 공유될 수 있습니다.

OKF v0.1은 여전히 초기 제안 단계입니다. Markdown과 메타데이터를 사용한다고 해서 우리의 위키가 자동으로 OKF와 호환되는 것은 아니며, 사양을 확인해야 합니다.

Cereja에서의 첫 테스트

자체 제작한 데모 Markdown 파일로 명령을 실행했습니다. 첫 번째 호출은 노트를 생성했습니다. 두 번째 호출은 같은 노트였지만 덮어쓰지 않고 반환했습니다.

테스트는 바이트와 인간의 주석 보존, 재잉스테이션(reingestion), 변경된 콘텐츠, 경로 제한, 공개 메타데이터 확인을 검증했습니다.

구현은 PR #34에 있습니다. 두 개의 새로운 테스트는 통과했습니다. 전체 스위트에서는 Windows의 경로 구분자와 관련된 Flame의 기존 오류가 나타났습니다.

이러한 결과들은 해당 명령어의 특정 동작들을 확인시켜 줍니다. 아직 시간 절약이나 큐레이션 품질 향상 정도는 측정하지 않았습니다. 다음 단계로는 PDF 추출, 검토 가능한 요약(sínteses revisáveis), 그리고 커버리지 체크가 있습니다. OCR과 폴더 모니터링은 사용 사례에서 이러한 필요성이 드러날 때 진행할 예정입니다.

귀하의 지식 기반에서는 생성된 노트와 이미 검토된 정보를 어떻게 구분하시나요? 댓글로 이 과정을 구성하는 방법을 알려주세요.