케냐의 여러 지역에 걸쳐 분산된 IoT 장치들을 위한 AI 모델 개선 작업에 처음 참여했을 때, 저는 자원이 제한적이고 연결성이 예측 불가능하다는 것을 빠르게 깨달았습니다. 이 설정에서 2,500개가 넘는 IoT 장치가 작동하고 있었기 때문에, 저의 AI 모델은 까다로운 네트워크 환경과 빠듯한 예산 조건에도 효율적이고, 빠르며, 적응력이 있어야 했습니다. Retrieval-Augmented Generation (RAG) 기술과 모델 Fine-Tuning 중 어떤 것을 선택할지 결정하는 문제는 단순히 학문적인 것이 아니라 필수적이었습니다.

필요성 이해하기

처음에는 많은 사람들이 모델을 데이터에 완벽하게 맞추는 가장 좋은 방법으로 강조했기 때문에 Fine-Tuning을 선택했습니다. 이상적인 해결책처럼 보였지만, 저는 한계에 부딪혔습니다. 2GB RAM VPS에서 이러한 작업을 관리하는 것만으로도 어려웠는데, Fine-Tuning은 제가 감당할 수 있는 것보다 더 많은 계산 비용과 시간을 추가했습니다. 처리 시간이 평균 15분에서 거의 한 시간 가까이 증가했습니다. 전력 및 네트워크 가용성이 불안정한 환경에서는 이것이 지속 가능하지 않았습니다.

반면에 RAG는 희망을 주었습니다. 문서 검색을 사용하여 기존 모델을 활용함으로써, 이는 2,500개 이상의 장치들이 파이프라인에 지속적으로 입력을 제공하는 것과 더 잘 작동했습니다. 검색 모델(retrieval model) 덕분에 전체 모델 대신 필요한 데이터 포인트만 업데이트할 수 있어 다운타임을 최소화했습니다. 이로 인해 처리 시간이 약 20분으로 줄어들었고, 이는 상당한 개선이었습니다.

실무에서 RAG 구현하기

RAG 기술은 사전 학습된 언어 모델(pre-trained language model)과 특정 데이터 검색을 결합할 수 있게 해주었습니다. 이는 모델이 모든 지식을 미리 갖추어야 하는 대신, 필요에 따라 특정 정보를 요청할 수 있다는 것을 의미했습니다. 이 접근 방식은 Raspberry Pi 장치와 유사한 기술에서 실행되는 저희의 예산 환경에 적합했습니다.

RAG를 구현하는 과정 자체에도 어려움이 있었습니다. 특히 지연 시간(latency) 측면에서 문제가 발생했습니다. 검색 구성 요소가 효율적으로 캐싱하지 못하거나 연결 상태가 끊기면 지연이 발생합니다. 때로는 네트워크 문제로 인해 2초 응답 시간이 무려 30초까지 늘어지기도 했습니다. LangChain을 사용하여 RAG를 어떻게 설정했는지 간단한 예시를 보여드리겠습니다:

from langchain.docstore import SimpleDocStore
from langchain.chains import RetrievalQA

...

이 설정을 통해 연결 상태가 문서 저장소(document store)에 접근할 만큼 충분히 안정적으로 유지된다는 전제 하에, 시스템 과부하 없이 효율적으로 질의응답을 할 수 있었습니다.

왜 파인튜닝(fine-tuning)이 완전히 배제되지는 않았는지

RAG가 유연성과 적응성 면에서 뛰어나지만, 저는 파인튜닝을 완전히 포기하지는 못했습니다. 예측 유지보수 모델(predictive maintenance models)과 같은 특정 애플리케이션은 여전히 파인튜닝의 이점을 누립니다. 이러한 모델들은 우리 환경에 고유한 특정 패턴을 감지해야 하기 때문입니다. 저는 모델의 더 작은 하위 집합(smaller subset)만 파인튜닝하여 네트워크 격리가 발생할 수 있는 지역에 로컬로 배포하는 것이 효과적이라는 것을 알게 되었습니다.

파인튜닝은 초기 설정 시간을 늘렸지만, 응답 시간의 지연 시간은 줄여주었습니다. 모델의 필수적인 부분만을 분리하고 파인튜닝함으로써, 저는 배포 구성을 약 35%까지 줄일 수 있었습니다. 핵심은 모델의 어떤 부분이 빈번한 업데이트가 필요한지, 그리고 어떤 부분이 변경되지 않고 유지될 수 있는지를 식별하는 것이었습니다.

현장에서 얻은 교훈

RAG와 파인튜닝을 균형 있게 사용하면서 자원 관리 측면에서 귀중한 교훈들을 얻었습니다. 제가 배운 점들은 다음과 같습니다:

1. 자원 역량 평가: 파인튜닝은 낮은 자원에서 병목 현상(bottleneck)이 발생할 수 있으므로, 정적이고 로컬적으로 중요한 모델에 가장 적합합니다.
2. 네트워크 현실 이해: RAG는 연결 중단 문제를 처리하기 위해 효율적인 캐싱 시스템을 필요로 합니다. 그렇지 않으면 응답 시간이 저하될 수 있습니다.
3. 하이브리드 시스템 고려: 동적이고 가변적인 데이터 요구 사항 처리는 RAG를 사용하고, 특히 빠른 응답이 운영에 영향을 미치는 경우 정적이고 중요한 분석에는 파인튜닝을 사용하는 것이 좋습니다.

다음 단계

아직 끝나지 않았습니다. 저의 계획은 RAG를 사용하여 가볍지만 여전히 신뢰할 수 있는 캐싱 전략을 채택하여 네트워크 장애 발생 시 지연 시간을 줄이는 것입니다. 파인튜닝(Fine-tuning)은 어떤 모델이 가장 큰 이점을 얻는지 알아내면서 계속 개발될 것입니다.

IoT 또는 리소스가 제한된 환경에서 비슷한 문제에 직면한 분들에게는 적응력을 유지하는 것이 중요합니다. AI 분야는 다양한 접근 방식을 제공합니다. 궁극적으로 가장 중요한 것은 자신의 상황을 이해하고, 일반적으로 상충되는 것처럼 보이는 방법들을 결합하는 것입니다. 진정한 혁신, 그리고 때로는 이성(sanity)이 바로 그곳에 있습니다.