RAG가 놓친 여러 파일 버그를 긴 문맥 모델로 잡은 사례
오래된 와 300쪽짜리 사양 문서를 함께 이해해야 하는 에이전트에서 RAG 방식이 계속 빗나갔다. , , Chroma, 임베딩, 맞춤 리랭커를 쓰고 조각 크기도 오래 조정했지만, 에이전트는 필요한 함수 로직 대신 쓸모없는 문서 문자열을 자주 가져왔다. 특히 전역 설정 버그에서 문제가 커졌다.
core/.py가 설정 객체를 만들고, main.py가 그 객체를 실행에 넣고, utils/scheduler.py가 에서 그 상태를 바꾸고 있었다. 저장소가 조각으로 나뉜 탓에 에이전트는 일부 단서만 보고 전체 흐름을 한 번에 보지 못했다. 그래서 설정 정의는 찾았지만, 나중에 스케줄러가 상태를 바꾸는 부분을 놓쳤고, 그 결과 그럴듯하지만 레이스 컨디션을 해결하지 못하는 수정안을 계속 냈다.
대안으로 벡터 DB, 조각 나누기, 임베딩 검색을 쓰지 않고 핵심 소스 파일과 전체 사양 문서를 하나로 이어 붙여 M3의 100만 토큰 문맥에 넣었다. 에이전트가 전체 자료를 한 번에 읽게 하자, 파일을 넘나드는 관계를 보는 방식이 달라졌다.
핵심 포인트
- RAG 방식은 코드와 사양 문서를 조각으로 나눠 필요한 부분을 찾으려 했지만 핵심 관계를 놓쳤다.
- 여러 파일에 흩어진 전역 설정 변경 때문에 레이스 컨디션이 남았다.
- 에이전트는 설정 정의는 찾았지만, 이 상태를 바꾸는 흐름을 보지 못했다.
- 대안은 핵심 소스 파일과 전체 사양 문서를 한 번에 긴 문맥 모델에 넣는 방식이었다.
- 만 보지 말고 검색 실패, 튜닝 시간, 잘못된 수정 비용까지 함께 봐야 한다.