AI 에이전트에서 memory는 가장 쉽게 과장되는 기능 중 하나다.
모든 대화와 실패를 다 기억시키면 더 똑똑해질 것 같지만, 실제로는 반대일 때가 많다.
오래된 가정과 일회성 실패가 다음 작업을 오염시키기 때문이다.
그래서 중요한 건 “많은 기억”이 아니라
실패는 먼저 Run Ledger에 남기고, 반복 가능하고 검증된 사실만 Memory로 승격하는 절차다.
더보기
이 영상의 핵심은 “또 하나의 AI 지식관리 앱이 나왔다”가 아니다.
핵심은 Andrej Karpathy가 던진 LLM Wiki 아이디어가 왜 RAG와 다른지를 선명하게 설명한다는 데 있다.
즉 이 영상은 LLM Wiki를 어떤 특정 제품명이 아니라, 지식을 축적하는 방식 자체를 바꾸는 패턴으로 본다.
더보기
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
더보기