LightRAG는 이제 단순히 “Graph RAG 오픈소스 하나”로 보기 어려운 프로젝트가 됐습니다. 출발은 Simple and Fast Retrieval-Augmented Generation 이었지만, 현재 저장소를 보면 Web UI, API 서버, 여러 스토리지 백엔드, reranker, citation, tracing, evaluation, 멀티모달 연동까지 붙으면서 사실상 하나의 RAG 플랫폼처럼 진화하고 있습니다. GitHub 저장소 더보기

RAG를 실제로 오래 굴려 본 사람이라면, 문제는 모델보다도 벡터 저장소에서 먼저 터지는 경우가 많다는 걸 압니다. 문서 수가 커질수록 임베딩 저장 공간이 커지고, 인덱싱 과정도 무거워지며, 온프레미스 환경에서는 메모리 예산이 곧 설계 제약이 됩니다. 이번 Threads 포스트가 흥미로운 이유는 바로 그 지점을 찌르기 때문입니다. Google Research의 TurboQuant 알고리즘을 RAG 쪽으로 가져온 pyturboquant가 공개됐고, 1,000만 chunk 규모에서 기존 float32 기준 약 31GB가 필요하던 인덱스를 약 4GB 수준으로 줄일 수 있다고 소개합니다. Threads 원문 더보기

이 영상은 단순히 “RAG가 좋다”를 말하지 않습니다. 오히려 Claude Code와 memory 문제를 어디서부터 어떻게 풀어야 하는지 단계별로 분해합니다. 핵심 질문은 이것입니다. 과거 대화나 거대한 문서 묶음에 대해 AI가 더 정확하게 답하게 하려면, 우리는 언제 그냥 CLAUDE.md 로 버틸 수 있고, 언제 Obsidian 정도면 충분하며, 언제 진짜 RAG 시스템으로 넘어가야 할까요? YouTube 영상 더보기

이 영상의 핵심은 “RAG를 더 잘 튜닝하는 법”이 아니라, 아예 벡터와 청킹을 전제로 하지 않는 RAG를 Codex로 빠르게 조립하는 법 에 있습니다. 발표자는 전통적인 vector-based RAG가 문서를 잘게 자르고 임베딩으로 바꾼 뒤 벡터 DB에서 유사도 검색을 하는 방식이라고 먼저 정리한 다음, PageIndex는 문서의 트리 구조 인덱스를 만들고 추론 기반 검색을 수행하는 vectorless RAG 라고 소개합니다. 0:01 1:23 더보기

LightRAG를 한 번 써 본 사람이라면 금방 부딪히는 한계가 있습니다. 텍스트 문서는 잘 다루지만, 스캔 PDF나 이미지가 섞인 보고서, 차트와 그래프가 많은 문서는 갑자기 처리 난도가 올라간다는 점입니다. 이 영상은 그 빈칸을 메우는 방법으로 RAG-Anything 를 소개합니다. 핵심은 새로운 RAG를 처음부터 다시 만드는 것이 아니라, LightRAG 위에 멀티모달 문서 처리 레이어를 하나 더 얹는 방식 이라는 데 있습니다. 0:48 1:03 더보기

Andrej Karpathy가 공개한 LLM Wiki 문서는 구현체가 아니라 패턴 문서에 가깝습니다. 핵심 주장은 단순합니다. 대부분의 RAG는 질문할 때마다 원문에서 관련 조각을 다시 찾고 다시 합성하지만, LLM이 직접 유지하는 영속적 위키를 하나 두면 지식이 누적되고 복리처럼 쌓일 수 있다 는 것입니다. Karpathy gist GeekNews도 이 포인트를 잘 요약하면서, 개인 지식 저장소·연구·독서·팀 위키 등으로 확장 가능한 패턴으로 소개했습니다. GeekNews 더보기

RAG를 이야기할 때 우리는 보통 벡터 DB, 임베딩, 검색 파이프라인부터 떠올립니다. 그런데 Chase AI의 영상은 완전히 다른 출발점을 제안합니다. Obsidian vault의 파일 구조만 잘 잡으면, Claude Code가 꽤 많은 문서를 다루는 지식베이스를 사실상 RAG처럼 사용할 수 있다 는 것입니다. 영상은 이걸 Andrej Karpathy의 Obsidian 기반 개인 지식 시스템에서 가져와 설명합니다. 영상 0:00 영상 1:01 더보기