RAG 인덱스와 에이전트 메모리를 Git처럼 버전 관리하기 (LambdaDB)

현시점의 문제 RAG 지식베이스나 에이전트 메모리는 계속 덮어써짐. 문서가 바뀌면 답도 조용히 바뀌지만, 어떤 데이터 상태에서 나온 답인지 되짚기 어려움 새 문서나 새 임베딩을 반영할 때도 운영 인덱스에 바로 쓰는 것 말고는 선택지가 마땅치 않음 보통 쓰는 방법과 이러한 방법의 한계 인덱스 통째로 복제(blue/green): 새 인덱스를 따로 만들어 검증한 뒤 교체함. Elasticsearch/OpenSearch의 index alias 교체가 대표적. 안전하지만 저장 공간과 재색인 시간이 버전 수만큼 늘어남 문서에 version 필드를 달아 필터링: 복제는 없지만 모든 쿼리에 필터가 붙고, 삭제·수정 이력 관리가 금방 복잡해짐 데이터 레이크 버저닝(lakeFS, Lance 포맷의 time travel 등): 파일·테이블 단위로는 잘 되지만, 검색 서빙 계층과는 따로 놀기 쉬움 LambdaDB의 접근: 검색 컬렉션 자체에 Git식 참조를 둠 Branch: 독립적으로 쓸 수 있는 문서 이력. 운영 데이터를 건드리지 않고 새 문서를 넣어 검증함 Tag: 특정 스냅샷에 이름을 붙여 고정. 태그가 있는 동안 스냅샷이 보존됨 Alias: 앱이 읽을 branch나 tag를 가리키는 포인터. 검증이 끝나면 포인터만 교체함 (ES alias 교체와 같은 발상이지만, 복제 없이 버전 단위로 동작함) 스토리지가 S3 위 불변 파일이라 바뀌지 않은 파일은 버전끼리 공유함 → 버전을 늘려도 전체 복사가 없음 asOf로 과거 시점에서 branch를 만들어 "그때 무엇이 검색됐는지" 재현할 수 있음 # 1) 3일 전 main 상태에서 조사용 branch 생성 collection.branches.create( "investigation", source=BranchSource.branch("main", as_of=cutoff_ms), ) # 2) 같은 쿼리를 그 시점 데이터로 실행 collection.query( query=..., ref=Ref.branch("investigation"), ) 써볼 만한 곳 RAG: 새 문서를 평가한 뒤 공개함. Git 릴리스를 태그로 매핑하면 코드 버전별 검색이 가능함 AI 에이전트·캐릭터챗 메모리: 세이브 지점에서 분기하거나, 꼬이기 전 시점으로 되돌림 RL·평가: 검색 데이터 버전을 고정해 모델 비교를 재현 가능하게 만듦