지식 시스템에서의 검색과 표현

대부분의 현대 지식 시스템은 검색(Retrieval) 최적화에 집중하며, 이는 이해할 수 있는 접근입니다. 검색은 가시적이며 데모하기 쉽고, 작동할 때 마법처럼 느껴집니다. 질문을 입력하면 답변이 돌아옵니다.

하지만 검색은 문제의 절반에 불과합니다. 더 근본적인 질문은 다음과 같습니다.

검색이 시도되기 전, 지식은 어떤 형태를 띠고 있어야 할까요?

이것이 바로 표현(Representation)입니다. 지식 뒤의 구조, 즉:

• 노트(notes)
• 페이지(pages)
• 스키마(schemas)
• 그래프(graphs)
• 엔티티(entities)
• 관계(relationships)
• 요약(summaries)
• 분류학(taxonomies)
• 출처 경계(source boundaries)
• 표준 버전(canonical versions)

검색은 다음을 묻습니다.

관련 정보를 찾을 수 있는가?

표현은 다음을 묻습니다.

지식이 의미 있게 조직되어 있는가?

이는 서로 다른 문제입니다. 표현이 부실한 RAG 시스템은 혼란스러운 아카이브에 대한 빠른 인터페이스가 될 뿐입니다.该系统은 단편을 검색할 수는 있지만 깨진 구조를 고칠 수는 없습니다. 문서를 인용할 수는 있지만 어떤 것이 표준인지 결정할 수는 없습니다. 문맥을 조합할 수는 있지만 기반 지식이 일관성이 있는지 보장할 수는 없습니다.

이것이 LLM Wiki 스타일 시스템이 흥미로운 이유입니다. 이러한 시스템은 노력의 방향을 쿼리 시간에서摄入(ingest) 시간으로 전환합니다. 사용자가 질문할 때 단순히 청크를 검색하는 대신, 지식을 페이지, 개념, 요약, 링크로 사전에 구조화하려고 시도합니다. 이것이 RAG를 구시대적 것으로 만드는 것은 아닙니다. 검색과 표현은 서로 다른 레이어이며, 좋은 지식 시스템은 둘 다 필요하다는 것을 의미합니다.

핵심적인 차이점

검색은 접근(Access)에 관한 것이고, 표현은 의미(Meaning)에 관한 것입니다.

약한 시스템은 종종 검색으로 바로 넘어갑니다. 반면 강한 시스템은 먼저 다음을 묻습니다.

1. 핵심 개념은 무엇인가?
2. 표준 출처는 무엇인가?
3. 어떤 관계가 중요한가?
4. 시간에 따라 무엇이 변하는가?
5. 무엇을 검색해야 하는가?
6. 무엇이 이미 표현되어 있어야 하는가?

이것이 문서 위에서의 검색과 실제 지식 시스템 사이의 차이입니다.

검색이 지배적이 된 이유

검색이 지배적이 된 이유는 현대 AI 스택에 잘 맞기 때문입니다. 일반적인 RAG 파이프라인은 다음과 같습니다.

1. 문서 로드
2. 청크로 분할
3. 임베딩 생성
4. 벡터 저장
5. 관련 청크 검색
6. 필요시 리랭킹
7. LLM 프롬프트에 삽입
8. 답변 생성

이 파이프라인은 실용적입니다. 구축이 비교적 쉽고, 지저분한 문서와도 작동하며, 대규모 코퍼스(corpus)로 확장 가능하고, 모델 재훈련을 피할 수 있으며, LLM이 최신 정보에 접근할 수 있게 해줍니다. 이것이 RAG가 “문서 위의 AI"를 위한 기본 패턴이 된 이유입니다.

하지만 함정이 있습니다.

RAG는 지식에 대한 접근을 개선합니다. 하지만 지식을 자동으로 개선하지는 않습니다.

콘텐츠가 중복되거나, 오래되었거나, 모순되거나, 나쁘게 분할되었거나, 이름이 적절치 않다면 검색은 이러한 문제들을 — 종종 확신을 가지고 — 표면화할 것입니다.

표현이란 무엇인가

표현은 검색이 발생하기 전에 지식이 형성되는 방식입니다. 다음과 같은 질문에 답합니다.

• 이 지식은 문서, 노트, 엔티티, 또는 사실로 저장되어 있는가?
• 관계가 명시적인가, 암묵적인가?
• 표준 페이지가 있는가?
• 요약이 있는가?
• 개념들이 연결되어 있는가?
• 시스템은 주제, 워크플로우, 시간, 또는 소유주에 따라 조직되어 있는가?
• 인간이 유지할 수 있는가?
• 기계가 추론할 수 있는가?

표현은 장식이 아닙니다. 어떤 연산이 가능한지를 결정합니다.

표현의 형태

문서

문서는 가장 일반적인 표현 형태입니다. 예시로는 다음이 있습니다.

• 기사
• PDF
• 매뉴얼
• 보고서
• README 파일
• 지원 페이지
• 블로그 포스트

문서는 인간이 작성하기 쉽지만, 사실, 서사, 문맥, 예시, 의견, 오래된 섹션, 반복적인 설명을 동일한 컨테이너에 섞어 놓기 때문에 기계가 사용하기에는 종종 어렵습니다. 문서는 좋은 컨테이너이지만, 항상 좋은 지식 구조는 아닙니다.

노트

노트는 문서보다 유연합니다. 노트는 다음과 같을 수 있습니다.

• 원자적(atomic)
• 연결된(linked)
• 사적인(private)
• 미완성
• 개념 중심

PKN 또는 두 번째 뇌와 같은 노트 시스템은 완성된 문서 저장소보다 진화하는 지식을 더 잘 표현할 수 있습니다. 좋은 노트는 진행 중인 사고를 포착합니다. 나쁜 노트는 검색 불가능한 쓰레기 서랍이 됩니다.

위키

위키는 유지 관리되는 페이지로 지식을 표현합니다. 좋은 위키에는 다음이 있습니다.

• 안정적인 페이지
• 명확한 주제
• 내부 링크
• 소유주
• 표준 답변
• 업데이트 패턴

위키는 느슨한 문서 덤프보다 강력합니다. 왜냐하면 지식을 위한 집(Home)을 제공하기 때문입니다. “배포 체크리스트"는 한곳에, “사건 대응"은 한곳에, “RAG 아키텍처"는 한곳에 존재합니다. 이는 검색이 지식이 안정적인 구조를 가질 때 더 잘 작동하기 때문에 중요합니다.

지식 그래프

지식 그래프는 지식을 엔티티와 관계로 표현합니다. 텍스트만 저장하는 대신 다음과 같은 것을 모델링합니다.

• Person works on Project (사람이 프로젝트에 참여함)
• Model supports ContextLength (모델이 컨텍스트 길이를 지원함)
• Page depends on Concept (페이지가 개념에 의존함)
• Service connects to Database (서비스가 데이터베이스에 연결됨)
• Tool implements Protocol (도구가 프로토콜을 구현함)

그래프는 관계가 명시적이 되어 탐색, 종속성 분석, 엔티티 해결, 계보, 추론, 추천에 도움이 되기 때문에 강력합니다. 하지만 그래프는 유지 관리에 비용이 많이 들며, 마법은 아닙니다. 나쁜 그래프는 단지 구조화된 혼란일 뿐입니다.

스키마와 온톨로지

스키마는 예상되는 구조를 정의합니다. 온톨로지는 한 단계 더 나아가 유형, 관계, 제약 조건을 정의합니다. 이는 다음을 묻습니다.

• 어떤 종류의 것들이 존재하는가?
• 그것들은 어떤 속성을 가지고 있는가?
• 어떻게 관계 맺을 수 있는가?
• 어떤 규칙이 적용되는가?

이는 의료 지식, 법률 지식, 엔터프라이즈 데이터 카탈로그, 제품 분류학, 규정 준수 시스템 등 정확성이 중요한 경우에 유용합니다. 대가는 경직성입니다. 표현이 더 형식적일수록 진화하는 데 더 많은 비용이 듭니다.

LLM 생성 표현

현대 시스템은 increasingly LLM을 사용하여 표현을 생성합니다. 예시로는 다음이 있습니다.

• 요약
• 추출된 엔티티
• 주제 페이지
• 개념 맵
• 합성 FAQ
• 문서 개요
• 교차 링크
• 용어집 항목

여기가 LLM Wiki 스타일 시스템이 자리 잡는 곳입니다. 이러한 시스템은 모델로 쿼리에 답변하는 것뿐만 아니라, 쿼리가 발생하기 전에 지식을 사전 처리하고 구조화합니다. RAG는 “쿼리 시간에 관련 청크를 검색하라"고 말합니다. LLM Wiki는 “摄入 시간에 유용한 지식 구조를 컴파일하라"고 말합니다. 두 패턴은 동일한 아키텍처에서 공존할 수 있습니다.

검색이란 무엇인가

검색은 관련 정보를 찾는 과정입니다. 일반적인 검색 방법에는 다음이 포함됩니다.

• 키워드 검색
• 전체 텍스트 검색
• 벡터 검색
• 하이브리드 검색
• 메타데이터 필터링
• 그래프 탐색
• 리랭킹
• 쿼리 재작성
• 에이전트 기반 검색

검색은 단일한 것이 아닙니다. 상호 보완적인 방법들의 레이어된 스택입니다.

키워드 검색

키워드 검색은 용어를 매칭하며, 예측 가능하고, 디버깅이 가능하며, 빠르고, 정확한 용어, ID, 오류 메시지, 이름, 코드에 좋기 때문에 여전히 유용합니다. 그 약점은 시맨틱 불일치입니다. 사용자가 “반복되는 답변을 멈추는 방법"을 검색하지만 문서에 “presence penalty"라고 되어 있다면, 키워드 검색은 가장 좋은 결과를 놓칠 수 있습니다.

벡터 검색

벡터 검색은 시맨틱 유사성으로 검색합니다. 다음 경우에 유용합니다.

• 표현이 다를 때
• 개념이 모호할 때
• 사용자가 자연어 질문을 할 때
• 문서가 일관되지 않은 용어를 사용할 때

그 약점은 정확성입니다. 벡터 검색은 관련 있다고 느껴지지만 실제로는 올바르지 않은 것을 검색할 수 있으며, 이는 기술 시스템에서 특히 위험합니다.

하이브리드 검색

하이브리드 검색은 키워드와 벡터 검색을 결합하며, 종종 각각보다 더 좋습니다. 키워드 검색은 정확한 매치를, 벡터 검색은 개념적 매치를 잡습니다. 기술 지식 베이스에 대해 하이브리드 검색은 일반적으로 강력한 기본값입니다.

리랭킹

리랭킹은 초기 검색 결과 세트를 가져와 더 강력한 모델을 사용하여 재순서화합니다. 첫 번째 검색 단계가 종종 광범위하기 때문에 이는 품질을 향상시킵니다. 일반적인 패턴은 50개의 청크를 검색하고 상위 5개 또는 10개로 리랭킹한 다음, LLM에게 가장 좋은 문맥만 전달하는 것입니다. 리랭킹은 RAG 품질을 개선하는 가장 실용적인 방법 중 하나입니다.

에이전트 기반 검색

에이전트 기반 검색은 검색을 프로세스로 전환합니다. 하나의 쿼리가 아닌, 에이전트는 다음과 할 수 있습니다.

1. 초기 질문하기
2. 검색
3. 결과 검토
4. 쿼리 재구성
5. 다시 검색
6. 출처 비교
7. 답변 종합

이는 검색보다 연구에 더 가깝습니다. 복잡한 질문에 유용하지만, 더 느리고 제어하기 어렵습니다.

표현 없는 검색은 취약합니다

검색 시스템은 존재하는 것만 검색할 수 있습니다. 다음을 신뢰할 수 있게 고칠 수는 없습니다.

• 불명확한 개념
• 중복된 페이지
• 일관되지 않은 용어
• 오래된 문서
• 누락된 출처 소유주
• 모순된 진술
• 약한 내부 링크
• 나쁜 문서 경계

이는 RAG 프로젝트에서 가장 흔한 실수입니다. 팀들은 벡터 데이터베이스를 구축하고 이것이 지식 시스템이 될 것이라고 기대합니다. 벡터 데이터베이스는 지식 아키텍처가 아닙니다. 그것은 접근 레이어입니다.

검색 없는 표현은 고립됩니다

반대 실패도 존재합니다. 아무도 찾을 수 없는 아름답게 구조화된 지식 베이스를 가질 수 있습니다. 이는 다음과 같은 경우에 발생합니다.

• 과도하게 설계된 위키
• 깊은 폴더 트리
• 경직된 분류학
• 인덱싱이 부실한 문서
• 발견 기능이 없는 사적인 노트 시스템
• 사용 가능한 인터페이스가 없는 그래프

표현은 지식에 구조를, 검색은 지식에 도달(Reach)을 제공합니다. 둘 다 필요합니다.

트레이드오프 맵

속도 vs 일관성

검색은 구축이 빠르고 표현은 시간이 더 걸립니다. 프로토타입이 필요하면 검색이 우세하며, 장기적인 신뢰가 필요하면 표현이 더 중요합니다.

순수한 RAG 프로토타입은 빠르게 구축할 수 있지만, 신뢰할 수 있는 지식 시스템은 큐레이션이 필요합니다.

유연성 vs 일관성

느슨한 문서는 유연하고, 구조화된 지식은 일관성이 있습니다. 유연성은 다음 경우에 도움이 됩니다.

• 도메인이 빠르게 변할 때
• 지식이 불완전할 때
• 사용자가 탐색 중일 때
• 시스템이 개인적일 때

일관성은 다음 경우에 도움이 됩니다.

• 여러 사람이 의존할 때
• 답변이 신뢰되어야 할 때
• 워크플로우가 의존할 때
• AI 시스템이 소비할 때

지식에 의존하는 사람이나 에이전트가 많을수록 표현이 더 중요합니다.

재현(Recall) vs 정확성(Precision)

검색 시스템은 종종 먼저 재현을 최적화합니다. 즉, 관련 있을 수 있는 것을 찾습니다. 하지만 좋은 답변은 정확성이 필요합니다. 즉, 단순히 관련 증거가 아닌 가장 좋은 증거를 찾는 것입니다. 표현은 개념과 경계를 더 명확하게 함으로써 정확성을 향상시킵니다. 잘 구조화된 페이지는 긴 문서 안에 묻힌 무작위 단락보다 정확하게 검색하기 더 쉽습니다.

###摄入 시간 비용 vs 쿼리 시간 비용

RAG는 일반적으로 작업을 쿼리 시간으로 미룹니다. 쿼리 시간에 시스템은 다음과 합니다.

• 쿼리 재작성
• 청크 검색
• 결과 리랭킹
• 문맥 조합
• 모델이 단편에 대해 추론하도록 요청

LLM Wiki 스타일 시스템은 더 많은 작업을摄入 시간으로 미룹니다.摄入 시간에 시스템은 다음과 합니다.

• 출처 읽기
• 개념 추출
• 요약 작성
• 페이지 생성
• 관련 아이디어 연결
• 구조 유지

이 중 어느 것도 보편적으로 더 좋은 것은 아닙니다. 이들은 서로 다른 비용을 최적화합니다.

LLM Wiki가 존재하는 이유

LLM Wiki는 검색만으로는 종종 작업을 반복하기 때문에 존재합니다. 일반적인 RAG 시스템에서는 각 쿼리가 모델을 강제로 원시 단편을 다시 해석하도록 할 수 있습니다.

1. 주제에 대한 청크 검색
2. LLM에게 개념을 추론하도록 요청
3. 답변 생성
4. 종합 잊기
5. 다음번에 반복

LLM Wiki는 다음과 말합니다.

동일한 종합을 재파생하는 것을 멈추세요. 컴파일하세요.

원시 문서만 저장하는 대신, 지식을 요약하고 연결하는 구조화된 페이지를 생성하여 일관성, 재사용, 토큰 효율성, 인간 가독성, 장기 유지 관리를 개선할 수 있습니다. 하지만 비용이 있습니다. 시스템은 위키를 유지해야 하며, 위키가 잘못되거나, 오래되거나, 환각(hallucinated)되면 구조가 위험해집니다.

RAG 환각 vs 나쁜 표현

사람들은 종종 RAG 시스템이 나쁜 답변을 줄 때 LLM을 탓하며, 때로는 그것이 맞습니다. 하지만 많은 실패는 실제로 검색 또는 표현 실패입니다.

실패 모드 1. 올바른 문서, 잘못된 청크

답변이 존재하지만, 청킹이 나쁘게 분할합니다. 모델은 다음을 받습니다.

• 단락의 절반
• 누락된 문맥
• 설명 없는 표
• 제약 조건 없는 정의

LLM은 이러한 간극을 채우며, 이는 환각처럼 보이지만, 더 근본적인 문제는 깨진 표현입니다.

실패 모드 2. 관련 청크, 잘못된 답변

벡터 검색은 시맨틱하게 유사하지만 운영상 잘못된 것을 검색합니다. 쿼리는 프로덕션 배포에 대해 묻지만, 검색된 청크는 로컬 개발을 논의합니다. 용어는 겹치지만 의미는 다르므로, 모델은 프로덕션 문제에 대해 로컬 설정 지침으로 답변합니다. 이는 검색의 부정확성입니다.

실패 모드 3. 상충되는 출처

두 문서가 불일칩니다 — 하나는 오래되고, 하나는 새롭습니다. 검색 시스템은 둘 다 반환하고, LLM은 이를 확신하는 하지만 유효하지 않은 답변으로 병합합니다. 이는 검색 문제일 뿐만 아니라 표현 문제입니다. 지식 베이스에 표준 상태가 없기 때문입니다.

실패 모드 4. 개념 모델 부재

시스템에는 많은 문서가 있지만 도메인의 모델이 없습니다. 다음을 알지 못합니다.

• “에이전트 메모리"는 “RAG"와 다름
• “위키"는 “PKM"과 다름
• “임베딩 검색"은 “전체 텍스트 검색"과 다름
• “배포"는 “호스팅"과 다름

개념적 표현 없이 검색은 모호한 매칭이 됩니다.

실패 모드 5. 생성된 구조가 가짜 권위가 됨

LLM Wiki 시스템은 자체적인 실패 모드를 가집니다. LLM이 나쁜 출처에서 깨끗한 페이지를 생성하면, 결과는 원래 자료보다 더 권위 있어 보일 수 있습니다. 이는 위험합니다. 광택이 나는 환각은 지저분한 출처 문서보다 나쁩니다. 모든 생성된 표현은 다음이 필요합니다.

• 출처 링크
• 검토
• 업데이트 규칙
• 신뢰도 마커
• 소유주

설계 함의

코퍼스가 크고 동적일 때 검색 최적화

코퍼스가 다음과 같을 때 검색이 우선순위여야 합니다.

• 코퍼스가 거대할 때
• 문서가 빈번하게 변경될 때
• 사용자가 예측 불가능한 많은 질문을 할 때
• 광범위한 커버리지가 필요할 때
• 완벽한 구조가 비현실적일 때

예시: 지원 지식 베이스, 엔터프라이즈 문서 검색, 연구 어시스턴트, 많은 파일에 대한 내부 채팅, 법률 발견, 고객 서비스 봇. 이러한 경우 강력한 검색에 투자하세요.

• 하이브리드 검색
• 메타데이터 필터
• 리랭킹
• 쿼리 재작성
• 출처 인용
• 평가 세트

일관성이 중요할 때 표현 최적화

지식이 다음과 같을 때 표현이 우선순위여야 합니다.

• 지식이 신뢰되어야 할 때
• 답변이 일관되어야 할 때
• 개념이 자주 재사용될 때
• 도메인이 명확한 구조를 가질 때
• 여러 시스템이 의존할 때

예시: 아키텍처 지식, 제품 문서, 규정 준수 규칙, API 참조, 운영 런북, 큐레이션된 연구 컬렉션, 기술 블로그 클러스터. 이러한 경우 다음에 투자하세요.

• 표준 페이지
• 용어집 용어
• 다이어그램
• 내부 링크
• 소유주
• 버전 관리
• 검토 주기

AI 시스템이 지식에 의존할 때 둘 다 최적화

AI 에이전트가 지식에 의존한다면, 검색만으로는 보통 충분하지 않습니다. 에이전트는 다음이 필요합니다.

• 안정적인 문맥
• 명확한 작업 규칙
• 내구성 있는 메모리
• 구조화된 참조
• 출처 경계
• 업데이트 동작

에이전트 시스템에서 표현은 시스템 설계의 일부가 됩니다. 코딩 에이전트는 “일부 문서"를 검색하는 것뿐만 아니라 다음을 알아야 합니다.

• 프로젝트 관례
• 아키텍처 결정
• 명령 패턴
• 금지된 종속성
• 테스트 워크플로우
• 배포 규칙

이 중 일부는 RAG에, 일부는 메모리에, 일부는 구조화된 프로젝트 문서에 속합니다.

실용적인 의사 결정 프레임워크

문제가 정보 찾는 것이라면

검색을 최적화하세요. 예시:

• “관련 페이지 찾기.”
• “문서에 대해 질문 답변.”
• “많은 PDF 검색.”
• “유사한 지원 티켓 위치 파악.”

사용:

• 전체 텍스트 검색
• 벡터 검색
• 하이브리드 검색
• 리랭킹
• 메타데이터 필터링

문제가 지식을 일관되게 만드는 것이라면

표현을 최적화하세요. 예시:

• “표준 설명 생성.”
• “중복 페이지 해결.”
• “도메인 모델 정의.”
• “안정적인 지식 베이스 구축.”

사용:

• 위키 페이지
• 개념 맵
• 분류학
• 지식 그래프
• 요약
• 스키마

문제가 반복적인 종합이라면

컴파일된 표현을 사용하세요. 예시:

• “동일한 개념적 질문에 반복적으로 답변.”
• “시스템이 동일한 출처를 계속 재요약.”
• “안정적인 종합 레이어 필요.”

사용:

• LLM Wiki
• 큐레이션된 요약
• 주제 페이지
• 인간 검토된 생성 페이지

문제가 적응적 지속성이라면

메모리를 사용하세요. 예시:

• “에이전트가 사용자 선호도를 기억해야 함.”
• “코딩 에이전트가 프로젝트 관례를 기억해야 함.”
• “어시스턴트가 세션 간 작업을 계속해야 함.”

사용:

• 에이전트 메모리
• 선호도 저장소
• 에피소드 메모리
• 시맨틱 메모리
• 프로젝트 메모리

기술 블로그에 적용하는 방법

기술 블로그는 포스트의 연속 이상일 수 있습니다 — 표현된 지식 시스템이 될 수 있습니다. 기사는 문서이고, 카테고리는 약한 분류학이며, 내부 링크는 그래프 간선이고, 핵심 페이지는 표준 요약이며, 시리즈 페이지는 큐레이션된 경로이고, 검색은 검색입니다. 고립된 포스트만 게시하면 검색이 더 열심히 작동해야 합니다. 강한 표현을 구축하면 검색이 더 쉬워집니다.

이는 다음을 의미합니다.

• 명확한 클러스터 경계
• 안정적인 슬러그
• 표준 페이지
• 비교 페이지
• 용어집 스타일 설명서
• 내부 링크
• 구조화된 메타데이터

이것이 사이트 아키텍처가 중요한 이유입니다. SEO뿐만 아니라, 그것이 지식 표현이기 때문입니다. 이 사이트의 Knowledge Management 클러스터는 표현 중심 출판의 자체적인 예입니다.

RAG에 적용하는 방법

RAG 품질은 표현에 크게 의존합니다. 잘 구조화된 출처 코퍼스는 다음을 개선합니다.

• 청크 품질
• 검색 정확성
• 인용 품질
• 답변 일관성
• 평가 명확성

복잡한 RAG 파이프라인을 구축하기 전에 다음을 물어보세요.

1. 출처 문서가 최신인가?
2. 중복이 제거되었는가?
3. 중요한 개념이 명확하게 명명되었는가?
4. 페이지가 올바르게 범위를 잡았는가?
5. 표와 코드 블록이 검색 가능한가?
6. 표준 답변이 명확한가?
7. 문서 경계가 의미 있는가?

답이 아니오라면, 더 나은 임베딩은 한계가 있습니다.

LLM Wiki에 적용하는 방법

LLM Wiki는 표현 중심 패턴입니다. 다음에 유용합니다.

• 코퍼스가 작거나 중간 크기일 때
• 지식이 요약하기에 충분히 안정적일 때
• 반복적인 종합이 비용이 많이 들 때
• 인간이 가독성 있는 페이지에서 이익을 볼 때
• 검색 전에 구조를 원할 때

다음에 덜 유용합니다.

• 코퍼스가 거대할 때
• 콘텐츠가 끊임없이 변경될 때
• 신선도가 일관성보다 중요할 때
• 거버넌스가 약할 때
• 생성된 요약을 검토할 수 없을 때

LLM Wiki는 RAG의 대체품이 아니라 다른 레이어이며, 강한 시스템은 둘 다 사용할 수 있습니다.

1. LLM Wiki는 구조화된 요약을 생성합니다.
2. RAG는 원시 출처와 위키 페이지에서 검색합니다.
3. 인간 검토는 표현을 신뢰할 수 있게 유지합니다.

제안된 아키텍처 패턴

패턴 1. 검색 우선

속도가 중요할 때 사용.

documents
  -> chunks
  -> embeddings
  -> retrieval
  -> LLM answer

좋음:

• 프로토타입
• 광범위한 검색
• 대규모 코퍼스
• 초기 실험

약점: 일관성은 출처 품질에 의존.

패턴 2. 표현 우선

신뢰가 중요할 때 사용.

sources
  -> curated pages
  -> internal links
  -> maintained knowledge base
  -> search or RAG

좋음:

• 문서
• 기술 지식
• 장기 콘텐츠
• 팀 지식

약점: 유지 관리 필요.

패턴 3. 컴파일된 지식

반복적인 종합이 중요할 때 사용.

raw sources
  -> LLM extraction
  -> generated summaries
  -> topic pages
  -> reviewed knowledge base
  -> retrieval

좋음:

• LLM Wiki 시스템
• 연구 컬렉션
• 개인 지식 베이스
• 안정적인 도메인

약점: 생성된 구조는 감사 필요.

패턴 4. 하이브리드 지식 아키텍처

심각한 시스템을 구축할 때 사용.

raw documents
  -> structured knowledge layer
  -> search index
  -> retrieval and reranking
  -> AI answer
  -> feedback and maintenance

좋음:

• 프로덕션 RAG
• 내부 지식 시스템
• AI 어시스턴트
• 기술 출판 시스템

약점: 더 많은 이동 부품.

평가 질문

검색을 평가하려면 다음을 물어보세요.

• 시스템이 올바른 출처를 찾았는가?
• 올바른 출처를 높은 순위로 매겼는가?
• 충분한 문맥을 검색했는가?
• 관련 없는 문맥을 피했는가?
• 답변이 올바른 출처를 인용했는가?

표현을 평가하려면 다음을 물어보세요.

• 지식이 명확하게 구조화되었는가?
• 표준 페이지가 있는가?
• 개념이 일관되게 명명되었는가?
• 관계가 명시적인가?
• 콘텐츠가 유지 관리되는가?
• 인간과 기계가 둘 다 사용할 수 있는가?

답변 품질만으로 지식 시스템을 평가하지 마세요. 좋은 답변은 나쁜 구조를 숨길 수 있습니다.

의견 기반 규칙

시스템이 가끔 실패한다면, 검색을 개선하세요. 동일한 개념 영역에서 반복적으로 실패한다면, 표현을 개선하세요.

나쁜 검색은 올바른 정보를 놓칩니다. 나쁜 표현은 올바른 정보가 사용 가능한 형태로 실제로 존재하지 않음을 의미합니다.

결론

검색과 표현은 서로 다른 문제를 해결합니다: 검색은 접근을, 표현은 구조를 제공합니다. RAG는 쿼리 시간에 외부 지식을 LLM에 사용할 수 있게 만들어서 강력하지만, RAG는 지식을 자동으로 일관적, 표준적, 유지 관리 상태로 만들지 않습니다. 이것이 위키, PKM 시스템, 지식 그래프, LLM Wiki 스타일 시스템이 여전히 중요한 이유입니다.

미래는 검색 대 표현이 아니라 레이어된 지식 시스템입니다.

• 구조를 위한 표현
• 접근을 위한 검색
• 지속성을 위한 메모리
• 종합을 위한 추론

심각한 지식 시스템을 구축 중이라면 벡터 데이터베이스로 시작하지 마세요. 지식의 형태부터 시작하고, 그것이 어떻게 검색되어야 할지 결정하세요.

출처 및 추가 읽기

• Google Cloud — Retrieval Augmented Generation
• AWS — What Is Retrieval Augmented Generation?
• IBM — Retrieval Augmented Generation
• IBM — Knowledge Management
• Atlan — LLM Wiki vs RAG Knowledge Base
• Dev.to — RAG vs Agent Memory vs LLM Wiki
• Starmorph — Karpathy LLM Wiki Knowledge Base Guide