LightRAG는 벡터 데이터베이스와 그래프 데이터베이스 관계를 독특하게 결합하여 지식 검색을 향상시키는 고급 Retrieval-Augmented Generation (RAG) 시스템입니다. 이를 구현한 Go 라이브러리가 바로 go-light-rag입니다.

go-light-rag은 완전한 엔드투엔드(end-to-end) 시스템을 제공하기보다는 LightRAG 아키텍처의 핵심 구성 요소를 구현하는 Go 라이브러리입니다. 이 라이브러리는 두 가지 필수 기능에 중점을 둡니다:

Insert: 유연한 처리 옵션을 사용하여 문서를 지식 기반에 추가합니다.
Query: 원본 결과를 보존하면서 상황적으로 관련된 정보를 검색합니다.

완전한 RAG 솔루션을 제공하는 원래의 Python 구현체와 달리, 이 라이브러리는 문서 처리 파이프라인과 프롬프트 엔지니어링(prompt engineering) 문제를 의도적으로 분리합니다. 이러한 접근 방식은 개발자에게 다음을 제공합니다:

• 문서 삽입 워크플로우에 대한 완전한 제어권
• 검색된 컨텍스트 데이터에 대한 직접적인 액세스
• 특정 사용 사례에 맞춰 사용자 지정 프롬프트를 작성할 자유
• 기존 Go 애플리케이션 및 워크플로우와의 통합 능력

미니멀한 API와 강력한 확장 지점(extension points)을 결합하여 go-light-rag은 미리 정의된 프롬프트 템플릿이나 처리 파이프라인에 구애받지 않으면서 하이브리드 검색의 이점을 필요로 하는 개발자에게 이상적입니다.

go-light-rag은 유연성, 확장성 및 모듈식 설계를 가능하게 하는 잘 정의된 인터페이스를 기반으로 구축되었습니다. 이러한 인터페이스는 구성 요소 간의 계약(contract)을 정의하여 핵심 로직을 수정하지 않고도 기능을 대체하거나 확장할 수 있게 합니다.

LLM 인터페이스는 다음 구현체들을 포함하여 다양한 언어 모델 제공업체를 추상화합니다:

OpenAI: GPT 모델에 대한 전체 지원
Anthropic: Claude 모델과의 통합
Ollama: 오픈 소스 모델을 위한 자체 호스팅 옵션
OpenRouter: 여러 모델 제공업체에 대한 통합 액세스

LLM 인터페이스를 구현함으로써 사용자 지정 구현체를 만들 수 있으며, 이 구현체는 Chat() 메서드만 요구합니다.

이 라이브러리는 세 가지 스토리지 인터페이스를 정의합니다:

GraphStorage: 개체 및 관계 데이터를 관리합니다
VectorStorage: 의미론적 검색 기능을 제공합니다
KeyValueStorage: 원본 문서 청크를 저장합니다

• GraphStorage: Neo4j (및 호환 그래프 데이터베이스)
• VectorStorage: ChromeM, Milvus
• KeyValueStorage: BoltDB, Redis

이러한 인터페이스 중 어느 것을 구현하든 다양한 스토리지 솔루션을 사용할 수 있습니다.

핸들러는 문서 및 쿼리 처리를 제어합니다:

DocumentHandler: 청킹(chunking), 개체 추출 및 처리를 제어합니다
QueryHandler: 키워드 추출 및 프롬프트 구조화를 관리합니다

Default: 공식 Python 구현을 따르는 범용 텍스트 문서 처리 방식입니다. Default 핸들러에 기본값(zero-value)을 사용하면 Python 구현과 동일한 구성을 사용하게 됩니다.
Semantic: Default를 확장하여 LLM을 활용해 고정된 토큰 수 대신 자연스러운 콘텐츠 경계를 식별함으로써 의미론적으로 의미 있는 청크를 생성하는 고급 핸들러입니다. 추가적인 LLM 호출 비용이 발생하지만 RAG 품질을 향상시킵니다.
Go: 함수, 타입, 선언과 같은 논리적 섹션으로 코드를 분할하기 위해 AST 파싱(parsing)을 사용하는 Go 소스 코드 전용 핸들러입니다.

사용자 정의 핸들러는 기존 핸들러를 임베드하고 특정 메서드만 오버라이드할 수 있습니다.

// LLM 초기화
llm := llm.NewOpenAI(apiKey, model, params, logger)
// 스토리지 구성요소 초기화
...

// 사용자 쿼리로 대화 생성
conversation := []golightrag.QueryConversation{
{
...

문서에 맞는 적절한 핸들러 선택: Default
일반 텍스트의 경우
Semantic
비용보다 콘텐츠 이해도 향상이 중요한 경우
Go
Go 소스 코드의 경우 - 전문화된 콘텐츠를 위해 사용자 정의 핸들러 생성

청킹 매개변수 최적화:

• 청크 크기가 클수록 더 많은 컨텍스트를 제공하지만 토큰 제한을 초과할 수 있습니다.

• 청크 크기가 작을수록 처리 속도가 빠르지만 컨텍스트를 잃을 수 있습니다.

• 개념의 연속성을 유지하기 위해 오버랩(overlap) 균형을 맞추는 것을 고려하세요.

• 자연 경계가 중요한 콘텐츠에는 Semantic 핸들러를 고려하세요.

• Semantic 핸들러 사용 시:

• LLM 컨텍스트 창에 기반하여 적절한 TokenThreshold를 설정하세요.

• 개별 청크 크기를 제한하기 위해 MaxChunkSize를 구성하세요.

• 의미론적 분석을 위해 신뢰할 수 있는 LLM 인스턴스를 제공해야 합니다.

• 동시성(concurrency) 적절히 구성:

• 동시성이 높으면 처리 속도는 빨라지지만 리소스 사용량은 증가합니다.

• 하드웨어 성능과 LLM 속도 제한에 맞춰 균형을 맞추세요.

• 개체 유형 사용자 정의:

• 도메인과 관련된 개체 유형을 정의하세요.

• 중요한 개념을 포착할 만큼 충분히 구체적이면서, 과도한 분열(fragmentation)을 피할 만큼 충분히 일반적이어야 합니다.

go-light-rag는 NaiveRAG 구현과의 성능 비교 벤치마크 테스트를 포함합니다. 이 벤치마크는 Python 구현과 동일한 평가 프롬프트를 사용하지만, 문서와 쿼리는 다릅니다.

자세한 벤치마크 결과 및 방법론은 benchmark 디렉토리를 방문하세요.

더 자세한 예시는 examples 디렉토리를 참조해 주세요.