LLM Wiki 관리: 드리프트, 모순 및 검토

LLM 위키(Wiki)는 오래된 사실이 여전히 그럴듯해 보일 때, 모순이 정교하게 다듬어질 때, 그리고 생성된 요약이 원천 자료에서 벗어나면 실패합니다.

컴파일된 지식 시스템의 진정한 프로덕트는 유지보수(Maintenance)입니다. 수개월에 걸친 자료 수집, 편집, 재작성, 그리고 새로운 소스 도입 동안 위키 페이지의 신뢰성을 유지하는 것은 페이지를 생성하는 것보다 훨씬 복잡합니다.

이 글은 LLM 위키 시스템의 운영 측면을 다룹니다: 드리프트(변이) 감지, 모순 확인, 인용 규율, 린팅(Linting), Git 검토, 그리고 유지보수 워크플로우입니다. 이 글은 LLM 위키 - RAG가 대체할 수 없는 컴파일된 지식에서 설명된 기본 패턴, 즉 원천 소스가 나중에 인간과 에이전트가 조회할 수 있는 내구성 있는 마크다운 페이지로 컴파일된다는 점을 이미 이해하고 있다고 가정합니다. 저자의 차분하지만 확고한 견해는 유지보수가 없는 LLM 위키란 단지 더 멋지게 꾸며진 ‘지식의 묘지’에 불과하다는 것입니다.

LLM 위키 유지보수가 다른 이유

전통적인 위키는 사람들이 업데이트를 멈추기 때문에 부패합니다. RAG 시스템은 코퍼스(문서 집합)가 변하고, 청크가陳舊해지며, 메타데이터가 약해지고, 검색이 여전히 그럴듯하지만 오래된 단편을 계속 찾게 되기 때문에 드리프트가 발생합니다. 근본적인 이유는 검색과 표현은 서로 다른 문제를 해결하기 때문입니다: 검색은 새로운 데이터에 대해 다시 실행할 수 있지만, 이미 컴파일된 표현은 적극적으로 정직하게 유지되어야 합니다.

LLM 위키에는 실패 모드가 다릅니다. 틀려도 깔끔해 보일 수 있습니다.

페이지는 잘 포맷되어 있을 수 있습니다. 링크는 작동할 수 있습니다. 요약은 균형 잡힌 것처럼 들릴 수 있습니다. 그러나 그 깔끔한 표면 아래에서 시스템은 중요한 사실을 누락하거나, 호환되지 않는 개념을 병합하거나, 소스가 아닌 요약을 인용하거나, 더 이상 적용되지 않는 과거의 결정을 그대로 유지하고 있을 수 있습니다.

따라서 LLM 위키 유지보수는 구조와 의미를 모두 확인해야 합니다.

유지보수의 목표

목표는 모든 페이지를 완벽하게 만드는 것이 아닙니다. 그 비용은 너무 크며, 종종 시스템이 방치되는 결과로 이어집니다.

목표는 위키를 유용하게 하고, 검사 가능하며, 복구 가능하게 유지하는 것입니다.

유지보수가 잘 된 LLM 위키라면 다음 질문에 쉽게 답할 수 있어야 합니다:

• 이 주장을 지지하는 소스는 무엇입니까?
• 이 페이지가 마지막으로 검토된 시기는 언제입니까?
• 이 개념은 변경되었습니까?
• 상충하는 페이지가 있습니까?
• 이 요약은 현재에도 유효합니까?
• 에이전트가 필요 이상으로 재작성했습니까?
• 잘못된 업데이트를 롤백할 수 있습니까?
• 인간이 페이지가 왜 그런 내용을 담고 있는지 이해할 수 있습니까?

답이 ‘아니오’라면, 문제는 단순히 콘텐츠의 질이 아닙니다. 시스템 설계의 문제입니다.

간단한 유지보수 루프

유용한 LLM 위키에는 반복 가능한 루프가 필요합니다. 이 루프는 자주 실행하기에 간단해야 하고, 드리프트가 눈에 띄지 않게 되기 전에 이를 잡기에 충분히 엄격해야 합니다.

이 루프는 화려하지 않습니다. 그것이 포인트입니다.

지식 시스템은 지루한 유지보수를 통해 내구성을 갖게 됩니다: 소스 보존, 명시적 검토, 예측 가능한 구조, 그리고 작고 안전한 업데이트. 동일한 본능이 영구 노트(Evergreen notes)를 구동합니다: 노트나 위키 페이지는 초안 작성 후 방치하여 부패하게 두는 대신 누군가가 지속적으로 다듬어 줄 때만 그 가치가 누적됩니다.

LLM 위키의 드리프트 유형

지식 드리프트는 단일 현상이 아닙니다. 다양한 드리프트 유형은 서로 다른 확인이 필요합니다. 좋은 유지보수 시스템은 이를 명확히 명명해야 합니다.

소스 드리프트(Source Drift)

소스 드리프트는 기저 소스 자료가 변경될 때 발생합니다.

예를 들어, 도구가 새 버전을 출시하거나, 정책이 업데이트되거나, API가 변경되거나, 벤더가 기존 기능을 비추적(deprecate)하는 경우입니다. 오래된 위키 페이지는 이전 버전에는 정확할 수 있지만, 현재 사용에는 잘못될 수 있습니다.

소스 드리프트는 위험합니다. 왜냐하면 오래된 주장이 역사적 맥락에서는 여전히 참일 수 있기 때문입니다. 문제는 그 주장이 가짜라는 것이 아닙니다. 문제는 더 이상 현재의 질문에 답하지 못한다는 것입니다.

유지보수 대응:

• 소스 날짜 기록
• 마지막 검토 날짜 기록
• 버전별 페이지를 명확히 표시
• 오래된 페이지를 대체하는 페이지로 링크
• 레이블 없이 오래된 버전과 새로운 버전을 혼합하지 않기

개념 드리프트(Concept Drift)

개념 드리프트는 용어의 의미가 시간이 지남에 따라 변경될 때 발생합니다.

이는 AI 및 소프트웨어 아키텍처에서 흔히 볼 수 있습니다. “에이전트”, “메모리”, “RAG”, “워크플로우”, “도구 사용”, “구조화된 출력”, “컨텍스트 엔지니어링"과 같은 용어는 빠르게 의미가 이동할 수 있습니다.

위키는 차이점을 설명하지 않고 동일한 용어의 여러 의미를 우연히 보존할 수 있습니다. 이는 일관성 있어 보이지만 호환되지 않는 아이디어를 결합하는 혼란스러운 페이지를 생성합니다.

유지보수 대응:

• 용어집 페이지 유지
• “이 위키에서의 의미” 섹션 추가
• 과부하된 개념을 별도의 페이지로 분리
• 관련된 의미를 명시적으로 링크
• 모델이 용어를 조용히 병합하지 않도록 방지

용어 드리프트(Terminology Drift)

용어 드리프트는 개념 드리프트보다 작지만 여전히 해롭습니다.

위키가 동일한 사물에 대해 여러 이름을 사용할 때 발생합니다: “LLM 위키”, “컴파일된 지식베이스”, “AI 유지보수 위키”, “에이전트 유지보수 위키”, “마크다운 지식베이스”.

일부 변이는 괜찮습니다. 너무 많은 변이는 검색, 링크, 그리고 검토를 무너뜨립니다.

유지보수 대응:

• 표준 페이지 이름 정의
• 프론트 매터 또는 페이지 메타데이터에 별명(Alias) 유지
• 중복 페이지 리디렉션
• 유사 중복 제목에 대한 린트 실행
• 내부 링크에서 일관된 앵커 텍스트 사용

결정 드리프트(Decision Drift)

결정 드리프트는 과거의 결정이 기록되어 있지만 현재 관행을 더 이상 반영하지 않을 때 발생합니다.

예를 들어, 페이지가 프로젝트가 모든 문서 검색에 벡터 RAG를 사용한다고 말할 수 있지만, 더 새로운 페이지는 LLM 위키 워크플로우를 설명할 수 있습니다. 두 진술 모두 역사적으로 참일 수 있지만, 위키는 어느 것이 현재인지 보여야 합니다.

이는 아키텍처 노트, 엔지니어링 프로세스, 콘텐츠 전략, 그리고 내부 툴링에 중요합니다. 동일한 규율이 AI 기반 개발의 결정 기록에도 적용됩니다: 결정 페이지는 대체된 선택이 조용히 덮어쓰이는 대신 대체되었도록 표시될 때만 신뢰할 수 있습니다.

유지보수 대응:

• 결정을 제안됨, 승인됨, 대체됨, 또는 기각됨으로 표시
• 결정 날짜 유지
• 대체된 결정을 대체재로 링크
• 역사적 맥락 보존
• 흔적 없이 오래된 결정을 삭제하지 않기

인용 드리프트(Citation Drift)

인용 드리프트는 페이지가 소스를 인용하지만, 주장이 더 이상 소스가 말하는 것과 일치하지 않을 때 발생합니다.

이는 재작성 후에 발생할 수 있습니다. 인용은 그대로 남아있지만, 그 주변의 문장은 변경됩니다. 페이지는 여전히 출처가 있는 것처럼 보이지만, 인용은 더 이상 주장을 지지하지 않습니다.

이는 LLM 위키의 가장 심각한 실패 모드 중 하나입니다. 왜냐하면 잘못된 자신감을 생성하기 때문입니다.

유지보수 대응:

• 주장 수준의 인용 지지 확인
• 요약만 인용하지 않기
• 원천 소스 유지
• 중요한 주장에 대한 인용 요구
• 소스는 있지만 직접적인 지지가 없는 단락 플래그 표시
• Git diff에서 인용 변경 검토

구조 드리프트(Structure Drift)

구조 드리프트는 위키가 서서히 탐색성을 잃을 때 발생합니다.

오래된 페이지를 업데이트하는 대신 새로운 페이지가 생성됩니다. 인덱스 페이지가 뒤처집니다. 중복 페이지가 나타납니다. 고아 페이지가 누적됩니다. 관련된 페이지가 서로를 더 이상 링크하지 않습니다.

위키에는 여전히 유용한 지식이 포함되어 있지만, 이를 찾고 신뢰하는 것이 더 어려워집니다.

유지보수 대응:

• 고아 페이지에 대한 린트 실행
• 인덱스 페이지 유지
• 중복 주제 감지
• 표준 페이지에 대한 백링크(Backlink) 요구
• 흩어지지 않고 아카이빙하기
• 폴더 역할 명확히 유지

핵심 유지보수 파일들

LLM 위키는 기억, 느낌, 또는 반복적인 프롬프팅에 의존해서는 안 됩니다. 인간과 에이전트가 이를 어떻게 유지보수해야 하는지 알려주는 운영 파일이 필요합니다.

실용적인 구조는 다음과 같을 수 있습니다:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

정확한 이름은 중요하지 않습니다. 역할이 중요합니다.

위키에는 소스 저장소, 컴파일된 페이지, 검토 산물, 그리고 세션 간에 생존하는 규칙이 필요합니다.

AGENTS.md

AGENTS.md는 에이전트가 작업하도록 허용되는 방식을 설명해야 합니다.

다음과 같은 질문에 답해야 합니다:

• 에이전트는 새로운 페이지를 생성하기 전에 기존 페이지를 업데이트해야 합니까?
• 언제 검토를 요청해야 합니까?
• 어떻게 소스를 인용해야 합니까?
• 폴더를 재구성할 수 있습니까?
• 오래된 페이지를 재작성할 수 있습니까?
• 모순이 발생하면 어떻게 해야 합니까?
• 절대 삭제해서는 안 되는 것은 무엇입니까?

유용한 규칙은 다음과 같습니다:

광범위한 재작성보다 소스에 기반한 작은 업데이트를 선호합니다.

이 한 문장은 많은 나쁜 유지보수 습관을 방지합니다. 또한 에이전트 메모리와 관련하여 유용한 경계를 그립니다: 메모리는 에이전트가 순간적으로 어떻게 행동하는지를 형성하는 반면, 위키의 규칙 파일은 에이전트가 공유 지식베이스에서 변경할 수 있는 것을 형성합니다.

schema.md

schema.md는 페이지 구조를 정의해야 합니다.

예를 들어:

# 페이지 제목

## 요약
짧고 현재적인 요약.

## 핵심 주장
- 소스 참조가 있는 주장.
- 소스 참조가 있는 주장.

## 현재 상태
현재, 역사적, 대체됨, 초안, 또는 불확실.

## 상세
주요 컴파일된 설명.

## 관련 페이지
내부 링크.

## 소스
원천 소스 참조.

## 검토 노트
마지막 검토 날짜 및 검토자.

스키마는 엄격할 필요가 없습니다. 그러나 스키마가 없으면 위키는 일관성 없는 에세이의 무더기가 됩니다. 스키마는 에이전트가 보존할 무언가를 제공합니다.

citation-policy.md

인용 정책은 어떤 것이 소스를 필요로 하는지 명시해야 합니다. 최소한 다음 사항에 대해서는 인용을 요구해야 합니다:

• 기술적 주장
• 비교
• 제품 동작
• 버전별 진술
• 벤치마크 결과
• 가격
• 법적 또는 규정 준수 주장
• 현재 상태 주장
• 소스에서 복사되거나 파생된 주장

좋은 인용 정책은 하지 말아야 할 것기도 명시합니다. 컴파일된 페이지를 원래 소스인 것처럼 인용하지 마십시오. 지지하지 않는 단락에 인용을 첨부하지 마십시오. 주장을 재작성한 후에도 소스가 여전히 지지하지 않는 한 인용을 유지하지 마십시오.

인용 규율은 유용한 LLM 위키와 장식적인 자신감 사이의 차이입니다.

source-policy.md

소스 정책은 원천 소스가 어떻게 저장되는지 정의해야 합니다.

예를 들어:

• 가능하면 원본 파일 유지
• URL 및 접근 날짜 보존
• 복사된 노트를 생성된 요약과 별도로 저장
• 소스 유형 기록
• 낮은 신뢰도 소스 표시
• 원재료 덮어쓰기 피하기
• 역사적 결정을 설명하는 경우 대체된 소스 유지

이 정책은 흔한 실수로부터 위키를 보호합니다: 소스를 요약하고, 원본을 버린 후, 요약을 증거로 취급하는 것.

그것은 지식 관리가 아닙니다. 그것은 손실성 압축입니다.

LLM 위키 린터가 확인해야 할 사항

린터는 먼저 구조를 확인해야 합니다. 구조적 문제는 자동화하기 더 쉽고, 종종 더 깊은 의미적 문제를 드러냅니다.

유용한 구조적 확인 항목에는 다음이 포함됩니다:

• 깨진 내부 링크
• 고아 페이지
• 중복 제목
• 누락된 소스 섹션
• 누락된 검토 날짜
• 백링크가 없는 페이지
• 비어 있거나 플레이스홀더인 섹션
• 섹션 구조가 없는 매우 긴 페이지
• 인덱스에서 들어오는 링크가 없는 페이지
• 일관되지 않은 명명 규칙
• 유효하지 않은 프론트 매터
• 검토 임계값보다 오래된 陳舊한 “현재” 페이지

이러한 확인은 지식이 참임을 증명하지 않습니다. 위키가 여전히 유지보수 가능하다는 것을 증명합니다. 이는 필요한 시작점입니다.

의미적 확인

의미적 확인은 더 어렵지만 더 가치 있습니다.

유용한 의미적 확인에는 다음이 포함됩니다:

• 직접적인 소스 지지가 없는 주장
• 서로 호환되지 않는 주장을 하는 두 페이지
• 현재로 제시된 오래된 결정
• 다른 이름을 가진 중복 개념
• 여러 의미를 혼합하는 단일 개념 페이지
• 알려진 제약 조건을 생략한 요약
• 기준이 없는 “최고” 또는 “권장” 주장
• 버전 레이블이 없는 버전별 주장
• 새로운 소스와 모순되는 페이지

이러한 확인은 위키를 자동으로 재작성해서는 안 됩니다. 일반적으로 검토를 위한 보고서를 생성해야 합니다.

더 안전한 패턴은 다음과 같습니다:

자동 감지.
명확히 설명.
의도적으로 업데이트.
위험한 변경 검토.

모순 감지

모순 감지는 LLM에게 두 페이지가 서로 모순되는지 단순히 묻는 것이 아닙니다.

그것은 도움이 될 수 있지만, 너무 모호합니다. 더 나은 접근법은 주장을 비교하는 것입니다.

모순 워크플로는 다음과 같을 수 있습니다:

이 방식이 더 잘 작동하는 이유는 많은 겉보기 모순은 실제 모순이 아니기 때문입니다.

한 페이지는 버전 1.0을, 다른 페이지는 버전 2.0을 설명할 수 있습니다. 한 페이지는 개인 사용을, 다른 페이지는 엔터프라이즈 사용을 설명할 수 있습니다. 한 페이지는 설계 목표를, 다른 페이지는 구현 현실을 설명할 수 있습니다.

모순 보고서에는 다음이 포함되어야 합니다:

• 상충하는 주장
• 관여된 페이지
• 소스 참조
• 날짜 또는 버전 컨텍스트
• 가능한 설명
• 제안된 해결책
• 인간 검토가 필요한지 여부

에이전트가 두 주장을 모호한 타협으로 조용히 병합하여 모순을 해결하지 못하게 하십시오. 그건 매끄러운 무의미함을 생성합니다.

모순 해결 방법

모순을 해결하는 몇 가지 유효한 방법이 있습니다.

• 한 주장이过时이라면, 대체됨으로 표시하고 더 새로운 페이지로 링크하십시오.
• 두 주장이 다른 컨텍스트에서 모두 참이라면, 컨텍스트를 명확히 분리하십시오.
• 소스가 일치하지 않는다면, 불일치를 보존하고 설명하십시오.
• 위키 페이지가 주장을 발명하거나 과장 일반화했다면, 주장을 제거하거나 좁히십시오.
• 모순이 아직 해결되지 않은 실제 결정을 반영한다면, 결정 페이지를 생성하거나 업데이트하십시오.

목표는 모든 긴장을 제거하는 것이 아닙니다. 일부 긴장은 유용합니다. 좋은 위키는 지식이 확립된 곳과 아직 불확실한 곳을 보여줍니다.

陳舊 페이지 검토

모든 컴파일된 페이지는 검토 상태가 있어야 합니다.

간단한 메타데이터 블록이면 충분할 수 있습니다:

status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium

빠르게 움직이는 주제에는 짧은 검토 기간을 사용하십시오. 안정적인 개념에는 더 긴 기간을 사용하십시오.

간격보다 습관이 더 중요합니다. 검토 날짜가 없는 페이지는 결국 조용히 거짓말하게 됩니다.

소스 인식 업데이트

새로운 소스가 도착하면, 에이전트는 단순히 새로운 요약 페이지를 작성해서는 안 됩니다.

다음과 같이 질문해야 합니다:

• 이것이 기존 개념을 업데이트합니까?
• 이전 소스를 대체합니까?
• 기존 페이지와 모순됩니까?
• 새로운 엔티티 또는 용어를 추가합니까?
• 권장 사항을 변경합니까?
• 인덱스 업데이트가 필요합니까?
• 결정 페이지에 영향을 미칩니까?

좋은 수집 워크플로는 위키를 격리된 요약의 스택이 아닌 그래프로 업데이트합니다.

따라서 하나의 소스가 여러 페이지를 터치할 수 있습니다. 이는 정상입니다. 유지보수 과제는 이러한 업데이트를 작고, 검토 가능하며, 추적 가능하게 만드는 것입니다.

Git Diff로 검토

Git은 LLM 위키를 위한 최고의 유지보수 도구 중 하나입니다.

Git이 유행하기 때문이 아니라, 생성된 지식은 검토 가능한 변경 이력이 필요하기 때문입니다. Git diff는 에이전트가 변경, 삭제, 이동, 또는 재표현한 것을 보여줍니다.

Git을 사용하여 다음을 검토하십시오:

• 새로운 페이지
• 삭제된 섹션
• 변경된 주장
• 변경된 인용
• 이름이 변경된 페이지
• 인덱스 업데이트
• 링크 변경
• 상태 변경
• 광범위한 재작성

가장 중요한 검토 습관은 삭제를 검사하는 것입니다. LLM은 종종 프로즈를 더 깔끔하게 만들면서 세부 사항을 제거합니다.

깔끔한 프로즈가 항상 더 나은 지식은 아닙니다.

안전한 커밋 전략

다음과 같은 거대한 커밋을 피하십시오:

Update wiki

작업을 설명하는 커밋을 사용하십시오:

ingest: Qwen 임베딩 출시 관련 소스 노트 추가
maint: 오래된 벡터 스토어 비교를 대체됨으로 표시
lint: RAG 페이지의 깨진 내부 링크 수정
review: LLM 위키 페이지 인용 업데이트
refactor: 에이전트 메모리 개념을 장기 메모리에서 분리

이는 미래의 인간과 에이전트에게 유용한 이력을 제공합니다.

커밋 메시지는 지식 시스템의 일부입니다. 위키가 왜 변경되었는지 설명합니다.

검토 수준

모든 페이지가 동일한 검토 수준을 필요로 하는 것은 아닙니다. 리스크 기반 검토를 사용하십시오.

저위험 변경:

• 깨진 링크 수정
• 포맷 정리
• 백링크 추가
• 인덱스 엔트리 추가
• 오타 수정
• 별명 추가

중위험 변경:

• 소스 요약 추가
• 새로운 개념 페이지 생성
• 권장 사항 업데이트
• 중복 페이지 병합
• 페이지 상태 변경

고위험 변경:

• 주장 삭제
• 표준 페이지 재작성
• 결정 기록 변경
• 보안, 법적, 가격, 또는 벤치마크 주장 업데이트
• 모순 해결
• 콘텐츠를 현재 또는 대체됨으로 표시

고위험 변경은 인간 검토를 받아야 합니다. 이는 당신, 유지보수자, 또는 도메인 소유자일 수 있습니다.

에이전트는 변경을 준비할 수 있지만, 최종 권위자가 항상 되어서는 안 됩니다.

유지보수 대시보드

간단한 유지보수 대시보드는 마크다운에 있을 수 있습니다.

예시:

# LLM Wiki 유지보수 대시보드

## 검토 필요
- wiki/concepts/agent-memory.md - 검토 기한 초과
- wiki/projects/search-index.md - 상충하는 주장 발견

## 陳舊 페이지
- wiki/tools/ollama.md - 마지막 검토 120일 전
- wiki/concepts/rag.md - 빠르게 움직이는 주제, 검토 예정

## 깨진 링크
- wiki/index.md -> wiki/concepts/old-page.md

## 고아 페이지
- wiki/entities/vendor-x.md

## 모순 보고서
- reports/contradictions/2026-07-10-agent-memory.md

## 최근 수집
- raw/sources/2026-07-09-new-paper.md

이는 세련된 관리 패널이 아닙니다. 이는 작업 표면입니다.

많은 솔로 또는 소규모 팀 시스템에는 마크다운 대시보드가 충분합니다.

건강한 LLM 위키를 위한 지표

과도한 엔지니어링 없이 위키 건강을 추적할 수 있습니다.

유용한 지표에는 다음이 포함됩니다:

• 페이지 수
• 소스가 없는 페이지
• 검토 날짜가 없는 페이지
• 검토 날짜가 지난 페이지
• 깨진 내부 링크
• 고아 페이지
• 중복 제목 또는 별명
• 미해결 모순 보고서
• 해결된 모순 보고서
• 클러스터별 평균 페이지 연령
• 아직 수집되지 않은 원천 소스
• 인간 검토 없이 변경된 페이지
• 지난 30일 동안 변경된 표준 페이지

이러한 지표는 허영심 숫자가 아닙니다. 시스템이 신뢰하기 쉬워지는지 어려워지는지를 알려줍니다.

고아 페이지와 陳舊한 검토가 증가하는 성장하는 위키는 지식을 누적하는 것이 아닙니다. 유지보수 부채를 누적합니다.

유지보수 프롬프트

유지보수 프롬프트는 좁아야 합니다. 넓은 프롬프트는 광범위한 재작성을 생성합니다.

구조적 린트 프롬프트

위키 구조를 검토하십시오.

다음 사항을 확인하십시오:
- 깨진 내부 링크
- 고아 페이지
- 중복 또는 유사 중복 페이지 제목
- 소스 섹션이 누락된 페이지
- last_reviewed 메타데이터가 누락된 페이지
- 새로운 페이지로 링크하지 않는 인덱스 페이지

콘텐츠를 재작성하지 마십시오.
찾아낸 내용과 제안된 수정 사항이 포함된 마크다운 보고서를 생성하십시오.

인용 검토 프롬프트

선택된 페이지의 인용을 검토하십시오.

각 중요한 주장에 대해:
- 지지하는 소식 식별
- 소스가 주장을 직접 지지하는지 확인
- 약하거나, 누락되거나, 불일치하는 지지가 있는 주장 플래그
- 아직 페이지를 재작성하지 마십시오

다음 표를 반환하십시오:
주장, 현재 인용, 지지 수준, 문제, 제안된 조치.

모순 확인 프롬프트

이 페이지의 관련 페이지에 대한 모순을 확인하십시오.

단계:
1. 페이지에서 주요 주장 추출.
2. 링크, 백링크, 별명, 검색을 통해 관련 페이지 찾기.
3. 잠재적으로 충돌하는 주장 추출.
4. 각 충돌을 분류:
   - 실제 모순
   - 버전 차이
   - 범위 차이
   - 용어 차이
   - 해결되지 않은 불확실성
5. 해결책 권장.

모순 보고서가 검토될 때까지 파일을 편집하지 마십시오.

陳舊 페이지 검토 프롬프트

이 페이지의 陳舊함을 검토하십시오.

확인:
- 날짜
- 버전별 주장
- 도구 동작
- 권장 사항
- 대체된 페이지로의 링크
- 페이지 검토 날짜보다 새로운 소스
- 최근 지지가 없이 현재로 표시된 주장

반환:
- 현재 유지
- 업데이트 필요
- 역사적 표시
- 대체됨 표시
- 버전별 페이지로 분할

안전한 업데이트 프롬프트

제공된 소스를 사용하여 선택된 위키 페이지를 업데이트하십시오.

규칙:
- 기존 유용한 구조 보존
- 소스가 대체되지 한 한 소스가 있는 주장을 제거하지 않기
- 새로운 주장에 인용 추가
- 불확실성 명시적으로 표시
- 필요할 때만 관련 페이지 업데이트
- 변경 사항을 설명하는 검토 노트 추가
- diff 작게 유지

이 프롬프트는 마법이 아닙니다. 이는 안전장치입니다. 진정한 가치는 유지보수 행동을 명시적으로 만드는 데서 옵니다.

흔한 유지보수 실수

첫 번째 실수는 에이전트가 너무 많이 재작성하도록 방치하는 것입니다.

큰 재작성은 페이지를 더 매끄럽게 만들기 때문에 생산적으로 느껴집니다. 또한 변경 사항을 보기 어렵게 만들고 날카로운 세부 사항을 잃기 쉽게 만듭니다.

두 번째 실수는 생성된 요약을 소스로 취급하는 것입니다.

요약은 유용할 수 있지만, 증거는 아닙니다. 원천 소스를 유지하고 주장이 중요할 때 인용하십시오.

세 번째 실수는 오래된 페이지를 업데이트하는 대신 새로운 페이지를 생성하는 것입니다.

이는 중복 개념, 상충하는 권장 사항, 검색 혼란을 생성합니다. 에이전트는 먼저 검색하고, 두 번째로 업데이트하며, 개념이 진정으로 새로운 경우에만 새로운 페이지를 생성해야 합니다.

네 번째 실수는 역사적 컨텍스트를 삭제하는 것입니다.

오래된 결정, 실패한 실험, 대체된 권장 사항은 가치 있을 수 있습니다. 지우기보다 명확히 표시하십시오.

다섯 번째 실수는 인덱스를 잊는 것입니다.

올바른 곳에서 링크되지 않은 페이지는 반쯤 잃어버린 것입니다. 인덱스 유지보수는 사무 작업이 아닙니다. 탐색 아키텍처입니다.

여섯 번째 실수는 모든 페이지에 동일한 검토 정책을 사용하는 것입니다.

안정적인 개념 페이지와 빠르게 움직이는 도구 비교는 동일한 검토 일정을 가져서는 안 됩니다.

아카이빙, 대체, 또는 삭제

대부분의 陳舊 페이지는 즉시 삭제되어서는 안 됩니다.

대체된 페이지는 대체재로 링크해야 합니다.

예를 들어:

Status: superseded
Superseded by: wiki/concepts/agent-memory-architecture.md
Reason: 이 페이지는 프로젝트가 세션 메모리, 사용자 메모리, 컴파일된 지식을 분리하기 전에 에이전트 메모리의 오래된 정의를 사용했습니다.

이는 컨텍스트를 보존하고 혼란을 줄입니다.

삭제는 드물고 검토 가능해야 합니다. 지식 시스템은 가지치기가 필요하지만, 보이지 않는 가지치기는 위험합니다.

표준 페이지는 추가적인 주의가 필요합니다

모든 LLM 위키는 결국 표준 페이지를 개발합니다.

이는 핵심 개념, 아키텍처 선택, 워크플로우, 또는 프로젝트 어휘를 정의하는 페이지입니다. 많은 다른 페이지가 이들에 의존하기 때문에 일반 노트보다 더 중요합니다.

예시:

• LLM 위키란 무엇인가
• RAG 대 컴파일된 지식
• 에이전트 메모리
• 소스 정책
• 검토 워크플로우
• 프로젝트 아키텍처
• 용어집
• 인덱스

표준 페이지에 대한 변경은 더 엄격한 검토가 필요합니다.

오해의 여지가 있는 페이지의 작은 오류는 국지적입니다. 표준 페이지의 작은 오류는 전체 위키를 왜곡할 수 있습니다.

유지보수를 얼마나 자주 실행해야 합니까

활발한 LLM 위키의 경우, 작은 유지보수는 자주, 깊은 유지보수는 가끔 실행하십시오.

일정자는 리스크와 일치해야 합니다. 개인 연구 위키는 더 가볍게 할 수 있습니다. 기술 출판, 고객 지원, 또는 엔지니어링 결정에 사용되는 위키는 더 많은 규율이 필요합니다.

기술 출판용 LLM 위키 사용

기술 블로그 또는 문서 사이트의 경우, LLM 위키는 기사 계획 뒤의 지식 계층이 될 수 있습니다.

다음 사항을 추적할 수 있습니다:

• 표준 설명
• 반복되는 정의
• 내부 링크 기회
• 陳舊한 비교
• 기사 격차
• 주제 클러스터
• 소스 노트
• 구조에 대한 결정
• 검증이 필요한 주장

이는 유용하지만, 유지보수 막대를 높입니다.

위키가 출판된 기사로 이어지면, 陳舊한 위키 페이지는 陳舊한 공개 콘텐츠가 될 수 있습니다. 위키에 모순이 포함되어 있으면, 그 모순은 기사로 누출될 수 있습니다. 인용이 약하면, 생성된 초안은 그 약점을 상속받습니다. 지식 관리를 위한 AI: 견고한 실제 워크플로우에서 설명된 범위 기반 요약, 스키마 기반 추출, 인간 검토 루프는 이러한 편집자 파이프라인을 정직하게 유지하기 위한 좋은 템플릿입니다.

출판 워크플로우를 위해, LLM 위키를 사적인 노트가 아닌 편집 시스템으로 취급하십시오. 디지털 가든은 독자에게 어떤 페이지가 아직 성장 중이고 어떤 것이 성숙한지, 즉 잘 유지보수된 LLM 위키가 노출해야 하는 상태 신호의 정확한 종류를 보여주어 이를 명시합니다.

유지보수는 선택 사항이 아닙니다

LLM 위키는 누적되는 지식을 약속하기 때문에 매력적입니다.

그러나 누적은 오래된 지식이 여전히 유용할 때만 작동합니다. 그렇지 않으면, 시스템은 통찰이 아닌 노이즈를 누적합니다.

에이전트가 관여한다고 해서 유지보수 부담이 사라지지 않습니다. 형태가 바뀝니다.

인간이 모든 지루한 작업을 할 필요는 없습니다. 에이전트는 링크를 확인하고, 陳舊 페이지를 찾고, 주장을 비교하고, 보고서를 작성하고, 업데이트를 제안할 수 있습니다. 그러나 인간은 여전히 정책을 설정하고, 위험한 변경을 검토하며, 위키가 무엇을 의미할 수 있는지 결정해야 합니다.

그것이 진정한 거래입니다.

결론

LLM 위키 유지보수는 컴파일된 지식을 정직하게 유지하는 것입니다.

중요한 관행은 복잡하지 않습니다: 소스 보존, 주장 인용, 인덱스 최신화, 모순 감지, Git diff 검토, 陳舊 페이지 표시, 그리고 검토되지 않은 광범위한 재작성 피하기.

좋은 LLM 위키는 마법처럼 자기 수정되는 것처럼 행동하지 않습니다. 수정을 더 쉽게 만듭니다.

그것이 목표로 삼아할 가치가 있는 표준입니다: 완벽한 지식이 아니라, 시간이 지나도 검토, 수리, 신뢰할 수 있는 검사 가능한 지식.