spring ai에서 RAG ETL 파이프라인 성능 최적화에 대해 질문이 있습니다!

Question

안녕하세요! 문서 분할 후 ETL 작업 마무리까지 시간이 오래 걸리길래, 프로파일링 해보니 keywordMetadataEnricher 작업 부분에서 가장 많이 시간이 소요되더라구요. 청크 사이즈를 키워 청크 개수를 줄여서 다시 테스트해보니 소요 시간이 많이 줄어들었습니다! 물론 아무래도 cpu나 gpu자원이 좋을수록 더 최적화할 수 있는 것 같긴 한데요ㅠ.ㅠ 어쨌든 작업 중 궁금한 점이 좀 많이 생겨서 질문 드려봅니다! keywordMetadataEnricher 의 기능이 rag의 검색 성능 등 서비스 활용 시에 사용자가 체감할 수 있는 성능을 많이 좌우할까요? keywordMetadataEnricher 사용을 최적화 하는 방법이 궁금합니다..! 저는 청크 개수를 줄였지만 그만큼 트레이드오프도 존재할 거 같아서, 병렬 처리를 한다든가.. 또 다른 방식이 있을 거 같은데 궁금합니다! (이것도 임베딩 모델과 연관 있을까요?) 추가로, 청크 개수를 줄였을 때의 장단점과 실제 서비스나 실무에서 사용 시, 청크 개수와 오버랩 값을 어떻게 결정할 수 있을지 궁금합니다! 실제로 테스트해보면서+경험론적으로 내가 etl 작업하고자 하는 로우 데이터의 성향에 따라 적절한 값을 찾는 것 밖에 없을까요..? 그 외 강사님께서 생각하시는 spring api 사용 시 ETL 파이프라인의 성능(시간 성능과 검색 성능)을 향상시킬 수 있는 방법도 궁금합니다. 시간 성능의 경우, ETL이라는 것은 무조건 시간이 오래 걸릴 수밖에 없는 작업이라는 생각이 들지만요..! 검색하면 논문도 나올만큼 많은 곳에서 얻을 수 있는 지식이지만,,! 강사님의 노하우나 생각도 궁금해서 질문 남겨봅니당. 항상 감사드립니다 : )

synee · Answer

안녕하세요! jyee님~ JSCODE 시니 입니다~

직접 프로파일링까지 진행하시고 청크 사이즈 조절을 통해 성능 테스트까지 해보신 점, 정말 훌륭한 접근입니다!ㅎㅎ

ETL 파이프라인을 구축하다 보면 누구나 마주하게 되는 깊이 있는 고민들을 잘 짚어주신것 같아요~!

질문해주신 내용들에 대해 하나씩 자세히 답변드리겠습니다!

1. keywordMetadataEnricher가 RAG 성능에 미치는 영향

결론부터 말씀드리면, 어떤 검색 방식을 사용하느냐에 따라 체감 성능이 크게 달라집니다!

• 영향이 적은 경우: 단순히 '벡터 유사도 검색'만 사용할 경우, 키워드 메타데이터는 검색 결과에 큰 영향을 주지 않습니다.

• 영향이 매우 큰 경우: 하이브리드 검색이나 메타데이터 필터링을 사용할 때 영향이 크다고 할 수 있습니다.

벡터 검색은 의미론적 유사성은 잘 찾지만, 고유명사, 특정 제품명, 약어 등의 '정확한 키워드 매칭'에는 취약할 때가 있습니다..!

이때 추출된 키워드 메타데이터를 기반으로 필터링을 걸거나 BM25 같은 키워드 검색을 병행하면 RAG의 검색 정확도가 비약적으로 상승합니다..!

2. keywordMetadataEnricher 최적화 방법 (시간 단축)

이 작업이 오래 걸리는 이유는 주로 각 청크마다 키워드 추출을 위해 LLM API를 호출(네트워크 I/O 및 추론 시간이 오래 걸림!)하기 때문입니다. 이를 최적화하는 방법은 다음과 같습니다.

• 병렬 처리 (비동기 처리): Spring의 @Async나 CompletableFuture, 혹은 Project Reactor(WebFlux)를 사용하여 청크 단위의 Enrich 작업을 병렬로 처리하면 시간을 획기적으로 줄일 수 있습니다!

• 특히 Java 21 버전 또는 그 윗버전의 가상 스레드를 적극 활용하시면 I/O 바운드 작업인 LLM API 호출 성능을 크게 높일 수 있습니다!

• 가볍고 빠른 모델 사용: 키워드 추출은 고도의 추론 능력이 필요하지 않은 단순 요약 작업입니다. 따라서 GPT-4o 보다는 GPT-3.5-turbo, GPT-4o-mini, 혹은 Claude Haiku 같은 빠르고 저렴한 모델을 메타데이터 추출용으로 따로 지정해 사용하시는 것을 권장합니다..! 검색해보시면 이런 키워드 추출용으로 자주 언급되는 모델이 있을거에요!ㅎㅎ

• 임베딩 모델과의 연관성: 키워드 추출 자체는 텍스트 생성(LLM) 영역이라 텍스트를 벡터로 바꾸는 임베딩 모델의 성능과는 직접적인 연관은 없다고 할 수 있습니다..!ㅎㅎ

3. 청크 개수(크기)에 따른 장단점 및 설정 노하우!

청크 크기를 키워서 개수를 줄이면 ETL 속도는 빨라지지만, 명확한 트레이드오프가 존재합니다.

• 큰 청크의 장점: 문맥이 넓게 유지됨, 파이프라인 처리 속도 향상.

• 큰 청크의 단점: 검색의 정밀도 하락. 여러 주제가 섞여 있어 사용자의 질문과 정확히 일치하는 부분을 벡터로 찾기 어려워짐(Lost in the middle 현상 발생 가능성이 높아져요!)

• 실무에서의 결정 방법: 수강생분 말씀대로 '데이터의 특성에 따른 경험적/반복적 테스트'가 정답에 가깝습니다🫠 다만 무작정 테스트하기보단 다음 기준을 참고해 보시면 좋을 것 같아요!

◦ Semantic Chunking (의미 기반 분할): 만약 마크다운이나 html을 사용하신다면, 단순히 글자 수(Token)로 자르지 않고, 마크다운의 헤더(#), 문단, 혹은 HTML 태그 단위로 논리적인 완결성을 가지도록 자르는 것이 중요할 것 같습니다!

◦ 오버랩(Overlap): 보통 청크 사이즈의 10~20% 정도를 줍니다. 문맥이 중간에 뚝 끊기는 것을 방지하기 위함입니다.

4. 실무 관점에서의 ETL 파이프라인 성능 향상 노하우

ETL은 본질적으로 무거운 작업이 맞습니다. 하지만 구조적으로 최적화할 방법은 많습니다..!!

• 시간 성능 (ETL 속도) 향상:

◦ 배치 처리(Batching): 임베딩 API를 호출할 때 1건씩 보내지 않고, API가 허용하는 최대 배치 사이즈(예: OpenAI의 경우 한 번에 여러 텍스트 배열 전송)로 묶어서 보내면 네트워크 오버헤드를 크게 줄일 수 있습니다~!

◦ Delta Update (증분 업데이트): 전체 문서를 매번 다시 벡터 DB에 넣는 것이 아니라, 해시(Hash)값을 비교하여 변경되거나 추가된 문서만 처리하도록 파이프라인을 설계할수도 있습니다!

• 검색 성능 (RAG 품질) 향상:

◦ Re-ranking (재정렬): 벡터 검색으로 1차 후보군(Top K)을 넓게 뽑은 뒤, Cross-Encoder 모델 등을 사용해 질문과 문서 간의 관련성을 다시 정밀하게 채점하여 순위를 매기는 방식입니다.

◦ Query Transformation: 강의에서 말씀드린 Query Transformation을 사용하는 방법인데요~사용자의 질문을 그대로 검색에 쓰지 않고, LLM을 한 번 거쳐 질문을 더 명확하게 재작성(Query Rewriting)하거나, 가상의 답변을 만들어 그 벡터로 검색(HyDE 기법)하는 방법이 있습니다..!

ETL 과정에서 시간이 오래 걸려 답답하셨을 텐데, 이런 성능적 병목을 직접 찾아내고 개선해 보려는 과정 자체가 실무 역량을 키우는 가장 좋은 방법입니다!ㅎㅎ

제 답변이 충분한 답변이 되었기를 바라며, 추가로 궁금한 점이 있다면 언제든 질문 남겨주세요! 응원합니다 :)🤍