벡터 RAG를 버리고 AI 에이전트 메모리를 직접 구축한 이유
We Built an Alternative to Vector RAG for AI Agent Memory
AI 에이전트가 단순 질의응답을 넘어 도구 선택과 다단계 워크플로를 수행하면서, 고정된 retrieve-then-generate 파이프라인인 전통적 벡터 RAG의 한계가 드러나고 있다. 문서를 잘게 쪼개는 청킹은 표·계약 조항 같은 구조를 훼손하고, 임베딩 유사도는 비즈니스 관련성과 다르다. 에이전트가 검색 시점과 도구를 스스로 결정하는 agentic retrieval로 이동해야 한다는 진단이다.
임베딩은 의미적 관계를 표현한다. 쿼리와 유사한 텍스트를 찾아낼 수는 있지만, 유사성이 비즈니스 과업과의 관련성과 같은 것은 아니다.
HN 토론
10- geuis
사이트 전체가 Claude로 생성된 것처럼 보입니다.
사이트가 스크롤을 가로챕니다.
RAG가 어떻게 작동하는지, 그리고 "현대적인 에이전트"가 문서에 접근해야 하는 방식과 비교하여 얼마나 과장되고 반복적인 설명이 이어지는지 문단마다 훑어봤습니다.
이 "RAG의 대안"이 무엇인지에 대해서는 어느 시점에도 전혀 보지 못했습니다.
솔직히 전체 텍스트가 LLM이 생성한 것 같은 느낌입니다.
- cmenge
첫 문단이나 두 문단을 읽었지만, 두 가지 이유로 멈췄습니다:
A) BM25를 사용한 검색과 벡터 임베딩을 통한 검색은 서로 다른 검색 방법입니다. 둘 다 용도가 있고, 많은 실제 사용 사례에서 둘 다 갖추는 것이 이득입니다. 검색 방법은 누가 언제 호출하든 독립적입니다. 즉, 정적인 파이프라인이든 검색 도구가 호출하는 동적인 파이프라인이든 마찬가지입니다.
B) 정적인 파이프라인을 마치 최신 기술인 것처럼 설명하고 있습니다. 제 기억으로는 우리가 그걸 버린 지 1년이 훨씬 넘었습니다. 아직도 그걸로 충분한 경우가 있을 수 있지만, 일반적으로 LLM이 도구 호출을 꽤 잘하게 된 이후로 에이전트 검색이 사실상 기본이 되었습니다.
- ericol
네, 사양하겠습니다. 어떤 종류의 문서든 당신에게 공유할 생각은 전혀 없습니다.