Tell-i : LLM Agent 서비스 구축기 (2)
RAG 시스템 구축 과정에서 PGVector 선택부터 인제스천 과정, LlamaIndex 프레임워크 선정, 그리고 실제 운영에서 마주친 다양한 도전과제들을 소개합니다.
Dec 10, 2024
1. 들어가며
반갑습니다, AI Product 팀 (이하 AIP)의 Data Scientist 김건호입니다.
AIP는 머신러닝, 딥러닝, LLM 등 AI 기술에 기반한 서비스를 통해 유저들에게 더욱 편의성 높은 서비스를 구축하는 것을 목표로 하고 있습니다. 특히, 리뷰를 비롯하여 다양한 정보를 찾아 떠나는 잡플래닛 유저 분들의 여정에 지도와 이정표가 되는 서비스를 만들고 있습니다.
지난 포스팅에서는
Telli에 사용된 기술들의 개념과 코어 프레임워크를 소개시켜드렸습니다.이번 포스팅에서는 실제로 데이터를 어떻게 가공하였는지, 그리고 그 과정에서 겪었던 AIP팀 경험을 공유드리고자 합니다.
2. 잠시, 용어 정리 먼저 할게요!
지난 포스팅은 개념을 소개시켜드리기 위한 목적인만큼 개념 설명 중심이었습니다. 이번 포스팅은 본격적인 개발 여정이므로, 이 글에서 사용될 용어들을 정리 할 필요가 있습니다. 특히나 아직은 용어 정립이 명확하지 않은 분야인 만큼, 글을 명료하게 이해함에 있어서 도움이 되실거라고 생각합니다.
용어 | 설명 |
RAG
Retrival Augmented Generation | LLM이 답변을 생성 할 때, 질문과 관련있는 자료를 참고해서 답변을 생성하는 기법을 의미합니다. |
문서 Document | RAG에 사용되는 자료를 통칭합니다. 텍스트로 구성되어 일반적인 문서와 같은 형태입니다. |
자연어 Natural Language | 인간이 사용하는 모든 언어를 의미합니다. 한국어, 영어 등이 자연어의 대표적인 예시입니다. |
벡터 Vector | 컴퓨터 연산에 용의하도록 사용되는 숫자로 구성된 표현된 행렬을 의미합니다. |
임베딩 Embedding | 자연어를 벡터로 변환하는 과정을 의미합니다. |
벡터 데이터베이스 Vector Database | 텍스트 등 비정형 데이터를 벡터 형식으로 변환하여 저장하고, 이를 기반으로 유사성 검색을 효율적으로 수행하는 데이터베이스입니다. 일반적인 데이터베이스와 달리 벡터 간의 거리를 사용하여 가장 유사한 항목을 빠르게 찾을 수 있습니다. |
쿼리 Query | 문서를 찾기 위해 사용되는 문장을 의미합니다. 일반적으로 질문, 키워드 등이 사용됩니다. |
검색 Retrieve | 임베딩 된 문서워 쿼리 간의 거리를 비교하여 가장 가까운 문서를 찾는 과정을 의미합니다. |
검색기 Retriever | 검색을 수행하기 위해 특정 벡터 데이터베이스와 통신하도록 되어있는 모듈을 의미합니다. |
인제스쳔 Ingestion | 외부 데이터(텍스트, 이미지, 데이터베이스 등)를 수집하여 벡터로 변환하고, 이를 구조화하여 저장하는 과정입니다. 이 과정에서는 데이터를 임베딩해 유사성 검색이나 자연어 처리 같은 작업에 활용할 수 있도록 준비하며, 주로 벡터 데이터베이스나 AI 애플리케이션에서 사용됩니다. |
변환 Transform | 데이터를 처리하여 모델이 이해할 수 있는 형식으로 변환하는 과정입니다. 주로 텍스트 데이터를 정제하고, 임베딩 모델을 사용해 벡터로 변환하여 의미적 정보를 수치로 표현합니다. |
메타 데이터 Metadata | 데이터의 추가 정보를 제공하여 검색과 필터링을 효율성을 향상시키기 위해 추가적으로 저장하는 데이터입니다. 문서에서 추출된 정보 외 다양한 속성을 포함하며, 이를 통해 검색 결과를 정확하게 필터링하고, 성능을 향상시킬 수 있습니다. 또한, |
문장 나누기 Sentence Split | 텍스트를 문장 단위로 분리하는 과정으로, 긴 텍스트를 처리 가능한 작은 단위로 나눕니다. 이를 통해 임베딩과 같은 후속 처리에서 효율성을 높이고, 더 정확한 의미 분석과 검색이 가능해집니다. |
정보 추출 Information Extraction | 문서의 원문에서 요약, 키워드 등 정보를 추출하는 것을 의미합니다. |
사전 추출 Pre-Extraction | 문장 나누기를 수행하기 이전에, 전체 문서를 대상으로 정보를 추출하는 과정을 일컫습니다. |
사후 추출 Post-Extraction | 문장 나누기를 수행 한 이후, 나누어진 문서를 대상으로 정보를 추출하는 과정을 일컫습니다. |
3. ‘문서 Document’는 어디에 저장되나요?
문서나 동영상 등 비정형 데이터를 효율적으로 저장하고 검색하기 위해 널리 활용되고 있는 DB는
벡터DB(Vector Database; VDB) 입니다. 개별 Data를 Vector로 저장해놓은 VDB 내에서 Vector 간의 거리를 계산하여 유사한 Data를 신속하게 찾아내는 데 특화되어 있기 때문입니다.특히,
RAG(Relevant Augmented Generation) 시스템에서는 사용자의 질문과 가장 연관성 있는 문서를 빠르게 검색하기 위해 임베딩 과정을 거쳐 생성된 벡터 데이터를 VDB에 저장합니다. 이렇게 저장된 벡터 데이터는 사용자의 질의와 비교되어, 가장 적절한 문서를 제공하는 데 중요한 역할을 합니다.벡터 데이터베이스의 가장 큰 장점은 비정형 데이터 검색의 효율성입니다. 텍스트, 이미지, 오디오 등 다양한 형태의 데이터를 벡터로 변환하여 저장하고, 이를 기반으로 빠르고 정확한 검색이 가능합니다. 덕분에 자연어 처리(NLP), 컴퓨터 비전과 같은 AI 응용 분야에서 VDB는 매우 유용하게 활용되고 있습니다.
그렇다면 문서는 어떻게 저장될까요? VDB라는 이름에 걸맞게 문서는 벡터로 변환되어 저장됩니다. 이 벡터는 고유한 의미를 담고 있어, 문서의 내용과 관련된 데이터를 빠르게 검색할 수 있게 해줍니다. 따라서 실제 문서 내용은 다른 스토리지에 저장될 수 있지만, 검색과 연관성 분석은 벡터 데이터베이스를 통해 이루어집니다.
3. 1. Vector Database (VDB)
VDB의 종류
현재 시장에는 여러 종류의 VDB가 존재하며, 각기 다른 강점을 가지고 있습니다. 대표적으로는 다음과 같은 옵션들이 있습니다.
- PGVector: PostgreSQL의 확장 모듈로, 벡터 데이터를 기존의 관계형 데이터베이스(RDB)와 함께 관리할 수 있다는 큰 장점이 있습니다. 이를 통해 관계형 데이터와 비정형 데이터를 하나의 시스템에서 통합 관리할 수 있습니다.
- Milvus: Zilliz에서 만든 분산형 벡터 데이터베이스로, 대규모 데이터 처리에 유리합니다. 다만, RDB와의 통합보다는 클라우드 및 분산 환경에 중점을 둔 것이 특징입니다.
- Pinecone: 상업용 클라우드 기반 벡터 데이터베이스로, 사용이 간편하고 관리 부담이 적습니다. 다만, RDB와의 연동성은 다소 제한적일 수 있습니다.
- DuckDB: 분석 중심의 임베디드 데이터베이스로, 벡터 연산을 지원합니다. 빠른 쿼리 처리 속도와 메모리 효율성이 특징이며, 대용량 데이터 분석에 적합합니다. 하지만 분산 환경에서의 확장성은 제한적일 수 있습니다.
- Redis: 인메모리 데이터 구조 저장소로, 최근 벡터 검색 기능을 추가했습니다. 빠른 읽기/쓰기 속도와 다양한 데이터 구조 지원이 장점이지만, 메모리 기반이라 대용량 데이터 처리에는 제한이 있을 수 있습니다.
3.2. AIP의 선택: PGVector
저희 팀은 벡터 데이터베이스로 PostgreSQL의 PGVector를 선택하였습니다. PGVector는 기존 RDBMS 환경을 유지하면서도 벡터 데이터를 효과적으로 처리할 수 있도록 지원하여, 별도의 시스템 구축 없이 기존 데이터베이스 구조를 확장하는 데 유리합니다.
PGVector를 통해 문서 데이터는
원본 문서 정보와 벡터화된 표현으로 나뉘어 관리됩니다. 이 구조는 문서의 원본을 빠르게 참조하거나, 벡터 간 유사도를 기반으로 관련 데이터를 검색할 수 있는 기능을 제공합니다. 이를 통해 하나의 데이터베이스에서 원본과 벡터 데이터를 통합적으로 운영할 수 있어, 별도의 벡터 데이터베이스를 추가로 운용하는 복잡성을 줄일 수 있습니다.더하여 기존 PostgreSQL 문법을 그대로 사용할 수 있어 학습 곡선이 낮으며, 데이터 조회와 API 개발 시 확장성이 뛰어난 것이 장점입니다. 이러한 이유로 저희는 PGVector를 채택하였습니다.
3.3. 인제스천(Ingestion)의 과정
데이터 파이프라인에서 인제스천 과정은 데이터를 RAG 구현을 위한 첫 번째 단계입니다. 이 과정은 크게 네 가지 주요 단계로 나눌 수 있습니다.
3.3.1. 데이터 수집 및 정제
첫 번째 단계는 데이터 수집과 정제입니다.
Tell-i 는 Jobplanet의 데이터를 RAG로 제공하는 것을 목표로 합니다. 이를 효과적으로 구현하기 위해, 기존 데이터베이스에서 필요한 데이터를 추출하고 하나의 문서 형태로 재구성합니다. 이 과정에서 데이터의 일관성을 유지하고 중복을 제거하며, 향후 활용할 수 있는 메타데이터를 선별합니다. 이를 통해 기존 시스템과의 연동성을 유지하고 Tell-i를 위한 데이터 구조를 최적화합니다.3.3.2. 정보 추출 및 임베딩
이 단계에서는 수집된 데이터에서 주요 정보를 추출하고, 텍스트를 적합한 단위로 분할한 뒤 임베딩 과정을 진행합니다.
먼저, 원본 문서에서 요약, 키워드 등 핵심 데이터를 추출하여 중요한 정보를 선별합니다. 이후 긴 텍스트는 문장 또는 작은 단위로 나누어, 임베딩 모델이 세밀하게 의미를 파악할 수 있도록 준비합니다. 마지막으로, 정제된 텍스트를 임베딩 모델을 통해 벡터로 변환하여 의미를 수치적으로 표현합니다. 이러한 과정은 텍스트의 구조화와 검색 정확도를 높이는 데 기여합니다.
3.3.3. 데이터 저장
마지막 단계는 벡터화된 데이터와 문서의 구조적 정보를 각각 적합한 형태로 저장하는 것입니다. 벡터 데이터는 검색 및 유사도 계산을 위해 관리되며, 문서의 구조 정보는 원본 문서와 분할된 텍스트 간의 관계를 유지하고, 데이터를 효율적으로 업데이트할 수 있도록 저장됩니다.
특히, 문서의 구조 정보를 활용하면 특정 데이터만 선택적으로 업데이트하거나 관리할 수 있어, 실시간으로 데이터가 변경되는 환경에서도 유연하게 대응할 수 있습니다. 이를 통해 새로운 데이터의 추가 및 변경 사항을 빠르게 반영하고, 데이터 일관성을 유지할 수 있습니다.
3.4. 메타데이터는 어떻게 활용되나요?
용도
메타데이터는 다양한 활용성을 지니고 있습니다. 검색 필터링 외에도 프론트엔드에서 UI 요소를 구현할 때 유용합니다. 예를 들어, 채용 공고의 시작 일시와 마감 일시는 현재 채용 중인 공고를 빠르게 찾기 위해 활용될 수 있으며, 채용 공고의 ID는 기존 서비스의 API를 통해 기업 대표 이미지를 불러오는 데 사용됩니다. 이를 통해 사용자 인터페이스를 더욱 직관적이고 유용하게 구성할 수 있습니다.
또한, 메타데이터는 요약이나 키워드와 같은 정보를 미리 저장해두어 LLM의 답변 생성 과정에서 맥락 정보로 활용할 수 있습니다. 매번 LLM을 통해 정보를 생성하는 대신, 미리 메타데이터에 저장된 정보를 사용하면 rerank와 같은 기법을 적용하는 데 도움이 됩니다. 이와 같은 방식은 LLM을 매번 호출하지 않고도 JobPlanet의 여러 서비스에 연동하는 One-Source-Multi-Use 확장성 전략을 구현하는 데에 사용될 수 있습니다.
그런데, 처음에 잘 만들어야해요.
다만, 앞서 언급한 바와 같이, 메타데이터는 변경이 될 경우, 전체 VDB를 새로 써야 하는 문제가 발생할 수 있습니다. 예컨대, 클라이언트(Client, 웹이나 모바일 애플리케이션)에서 필요한 정보로
리뷰가 올라온 날짜가 있다고 해보겠습니다. 데이터베이스에 존재하는 값이니까, 새롭게 추가될 데이터를 위한 코드를 변경하고 메타데이터를 저장한 JSONB 컬럼을 업데이트해서 리뷰가 올라온 날짜를 추가 할 수 있었습니다.
이번에는
요약의 프롬프트를 변경해서, 조금 더 짧은 문장으로 기업 장점 요약을 한다고 해봅시다. 앞서 리뷰가 올라온 날짜는 기존 RDB에서 가져오면 되지만, 기업 장점 요약은 Ingestion 과정에서 넣어두는 정보입니다. 이 문제를 발견한 시점에서는 초기 데이터 구축을 위해서 방대한 양의 데이터를 벌크(Bulk)로 인제스천(Ingestion) 하였습니다. 리뷰가 올라온 날짜와는 달리, 요약은 처음부터 다시 Ingestion 해야 합니다. 인제스천(Ingestion)은 시간이 꽤 오래 걸리는 작업이고, 더해서 비용이 발생합니다. 특히 사전/사후 정보추출 과정에서 요약, 키워드 등을 생성하기 위해서 LLM을 사용하고, 임베딩에서도 마찬가지로 비용이 발생합니다 - 물론 Local Model로 self-hosting 한다고 해도, GPU 등 비용이 발생합니다. 그리고, 전반적인 모든 기업들의 장점 요약을 변경한다는 것은 벌크 인제스천(Bulk Ingestion)을 처음부터 새로 한다는 의미입니다. 시간이 오래 걸리고 비용이 많이 드는 작업을 메타데이터의 일부분을 업데이트하기 위해서 매번 처음부터 다시 해야 하는 상황에 직면할 수 있습니다.따라서 메타데이터를 저장하실 때에는 사전에 충분한 테스트와 검토를 거친 다음에 작업해야 합니다. 소스 코드 레벨에서는 별것 아닌 작업은 아니지만, 시간과 비용의 측면에서는 마땅한 해결책이 없기 때문입니다.
(물론, 이 문제를 알고 있는 이유는... 😢)
3.5. 개발자분들을 위한 경험 공유 (Do & Don't)
Do
- 유연한 설계: 데이터 처리 및 임베딩 모듈을 설계할 때는 재사용성을 고려해 다양한 설정과 모델 변경에 유연하게 대응할 수 있도록 설계하세요.
- 효율적인 자원 활용: 자주 업데이트가 필요한 경우, 비용 효율이 높은 모델과 설정값을 활용하는 것을 권장합니다.
- 안정적인 설정: 모델의 답변 품질을 안정적으로 유지하기 위한 주요 파라미터인 Temperature를 적절히 조정하세요.
- 구체적인 프롬프트 작성: 명확하고 구체적인 예시를 포함한 프롬프트를 사용하여 일관된 결과를 도출하세요.
Don't
- 불필요한 데이터 포함: 데이터 수집 단계에서 불필요한 정보를 포함하지 않도록 주의하세요. 데이터가 복잡할수록 처리 비용이 높아지고, 모델의 정확성이 저하될 수 있습니다.
- 단일 구조 의존: 모든 데이터를 한 곳에 모으기보다, 용도에 따라 적합한 구조로 나누어 관리하는 것이 효율적입니다.
- 과도한 기대: RAG 시스템은 참고 자료를 기반으로 답변을 생성할 뿐, 모든 정보를 완벽히 해결할 수 있는 만능 도구는 아니라는 점을 인지하세요.
4. 파이프라인 설계시 고려사항
4.1. 프레임워크(Framework)
인제스천과 워크플로에 대해 이해하셨다면, 프레임워크를 선택해야합니다. AIP에서도 프레임워크를 선택하는 과정에서 오픈 소스 프로젝트를 비교 분석하는 과정을 거쳤습니다. 프레임워크를 선택하는 과정에서의 기준은 다음과 같았습니다.- 인제스천 (Ingestion)부터 LLM을 통한 답변까지 하나의 프레임워크 내에서 이루어질 수 있는가?
- 역설계(Reverse Engineering) 분석이 가능한 규모(Volume)인가?
- 적절한 추상화 수준을 통해서 빠르게 구현이 가능한가?
- low-level에서 필요한 기능의 수정이 가능한가?
- 다른 프레임워크와의 호환이 가능한가?
- 문서화가 잘 되어있는가?
- 활발한 프로젝트인가?
이러한 기준을 바탕으로 많은 프레임워크를 1차적으로 분석하고, 그 중에서도 LlamaIndex, LangChain, HayStack의 내부적인 구조를 분석하였습니다. 간략한 장/단점은 다음과 같습니다.
LlamaIndex:- 장점: 데이터 인덱싱과 검색에 특화되어 있으며, 다양한 데이터 소스를 지원합니다.
- 단점: 상대적으로 새로운 프레임워크로, 성장 중인 커뮤니티를 지니고 있습니다.
LangChain:- 장점: 다양한 LLM 작업을 위한 강력한 도구와 추상화를 제공합니다.
- 단점: 복잡한 워크플로우를 구현할 때 학습 곡선이 높을 수 있습니다.
HayStack:- 장점: 검색 기반 QA 시스템 구축에 강점이 있습니다.
- 단점: 다른 두 프레임워크에 비해 유연성이 떨어질 수 있습니다.
최종적으로 AIP는 (1편에서 소개드린 바와 같이)
LlamaIndex를 선택했습니다. LlamaIndex는 대규모 데이터 인덱싱과 검색에 특화되어 있어 Tell-i의 서비스 목표에 가장 부합하였습니다. 빠른 구현이 가능하도록 high-level의 메서드를 지원함과 동시에 필요시 low-level에서 메서드(Method)를 활용할 수 있는 유연성을 제공하며, 다른 프레임워크와의 호환성이 좋아 LangChain 등과 함께 사용할 수 있는 장점이 있었습니다. 그리고 기여자(Contributor)의 수가 많아 업데이트가 빨랐습니다. 또한 다행히(?) 상세한 문서를 제공하여 개발 팀의 학습과 구현 속도를 높일 수 있었습니다.LlamaIndex의 강점은 인제스천을 Pipeline으로 구현하는 기능이 추가적인 코드 수정 없이도 유연하게 대처할 수 있도록 되어 있다는 점입니다. 물론, 서비스를 위한 프레임워크를 구축하는 과정에서 어느 정도 Wrapper를 구현해야 합니다. 하지만 인제스천 과정에서 메타데이터 추출, 텍스트 분할, 임베딩 생성 등의 작업을 개별적으로 자유도를 확보하여 개발 부담이 적었습니다. 이러한 이유로 LlamaIndex가 Tell-i의 RAG 시스템 구축에 가장 적합한 프레임워크라고 판단하여 선택하게 되었습니다.4.2. 인제스천의 변동성
프레임워크를 선정했다면, 나머지 구현 부분은 앞서 설명드린 요소를 잘 고려한다면 파이프라인 구축까지 난감한 부분은 없을 것이라고 생각됩니다. 기능적으로 부족한 부분들은 추가적으로 구현하면 되고, 기존의 기능들에서 대부분은 해결 될 수 있습니다.
하지만 예상하지 못한 변수로는 인제스천에 소요되는 시간에 변동성이 있다는 점 입니다. 어느정도 염두에 두고 있던 부분이긴 합니다. 하지만 실제 운영 단계에서는 생각보다 더 큰 변동성을 보였습니다.
결론을 말씀드리자면, 인제스천 (Ingestion)에 소요되는 시간은 짧게는 1분도 안걸리지만, 길면 1시간도 걸릴 수 있다는 점입니다. 그리고 이 점은 모델의 성능과는 무관하게 발생합니다. 모델의 성능이 좋다고 해서 더 빠르게 인제스천이 되는 것이 아니라는 것 입니다. 새로 다루어야하는 데이터의 양이 얼마나 많은지에 따라서 가장 큰 영향을 받게됩니다.
예를 들어, 저희 JobPlanet 리뷰 데이터는 유저분들께서 작성한 후 바로 올라가는 것이 아닙니다. 욕설이나 특정인에 대한 모욕 등 잠재적인 문제가 될 수 있는 리뷰들은 담당 조직에서 검수를 거치게 됩니다. 업무 시간대에 따라 오전에는 일간 리뷰 승인이 이루어지고, 오후 시간대에는 추가적인 리뷰 승인이 이루어집니다. 그 결과 오전에는 처리해야 하는 리뷰 데이터의 양이 많고, 오후에는 그보다 적은 양의 리뷰 데이터를 처리하게 됩니다. 따라서 인제스천에 소요되는 시간은 업무 시간대에 따라 변동성을 갖게 됩니다.
상반된 두가지 관점에서 해결책을 떠올릴 수 있습니다.
- 얼마나 걸릴지 모르니, 야간 시간대를 활용해서 인제스천을 진행한다.
- 최적 주기를 설정해서, 주기적으로 인제스천을 진행한다. (단, 신규 리뷰가 추가되지 않는 업무 외 시간대에는 인제스천을 진행하지 않는다.)
(1)의 경우, 데이터를 실시간으로 반영하지 못한다는 문제가 있습니다. 이는 사용자에게 최신 정보를 제공하지 못할 수 있어 서비스 품질에 영향을 줄 수 있습니다. 또한, 야간 시간대에 대량의 데이터 처리로 인해 시스템에 부하가 집중될 수 있어 다른 야간 작업에 영향을 줄 수 있습니다.
(2)의 경우, 주기적인 업데이트로 데이터의 최신성을 유지할 수 있지만, 최적의 주기를 설정하는 것이 중요합니다. 너무 짧은 주기는 시스템에 불필요한 부하를 줄 수 있고, 너무 긴 주기는 데이터의 실시간성을 해칠 수 있습니다.
결론적으로, 저희 팀은 (2)의 방식을 채택하여 데이터 양과 시스템 부하를 고려하여 최적의 주기를 설정하기로 결정했습니다. 이를 통해 데이터의 신선도와 시스템 효율성 사이의 균형을 맞추고자 했습니다. 또한, 필요에 따라 중요한 업데이트가 있을 때 수동으로 인제스천을 트리거할 수 있는 옵션도 추가하여 유연성을 확보했습니다.
4.3. 모니터링 도구: SLACK
데이터가 실시간으로 업서트되는 상황이므로, 데이터 스트림이 끊길 이유는 무궁무진합니다. 예컨대,
OpenAI나 Google Gemini의 세이프가드(Safeguard; 부적절하거나 공격적인 의미의 내용을 방지하는 기준)에 걸려 인제스천 도중에 정지되는 문제가 있을 수 있습니다. 또한, 처리 과정에서 원천 데이터는 서버의 메모리에 할당된 상태로 작업이 진행되기 때문에, Out-of-Memory 에러 또는 Task Queue와의 충돌, DB와의 연결 끊김 문제 등이 발생 할 수 있습니다. 따라서 인제스천을 담당하는 서버의 로깅은 실시간으로 매 작업을 확인할 수 있어야 합니다. 저희의 경우에는 GCP 환경에서 구축하였기 때문에 GCP에서 제공하는 로깅 도구를 사용하는 것이 가능했지만, 현실적으로 다른 업무를 하는 데 모니터링이 원활하지는 않습니다. 따라서 사내 메신저인 슬랙(Slack)과 연동해서 서버의 로그를 전부 전송했습니다.
물론 이렇게 되면 로그의 양이 상당히 많습니다. 따라서 필요한 로그만
INFO로 보낼 수 있도록 하고, 실패한다면 Traceback 로그를 전부 출력해서 빠른 문제 해결이 진행되도록 했습니다. 초기에는 AIP에서도 기존의 GCP Logging 도구를 사용하였습니다. 하지만 시스템 관리 차원에서는 확실히 '눈에 잘 보이는 게' 중요합니다. 따라서 저희는 슬랙과 연동하는 방식을 최종적으로 채택해서 현재까지 수월하게 모니터링을 하고 있습니다.
5. 끝으로
이번 포스팅에서는 Tell-i의 RAG 시스템 구축 과정을 자세히 살펴보았습니다. 벡터 데이터베이스 선택부터 인제스천 과정, 프레임워크 선정, 그리고 실제 운영에서 마주친 다양한 도전과제들을 다루었습니다.
PGVector 선택의 이유, LlamaIndex 프레임워크의 장점, 그리고 인제스천 과정의 변동성 문제와 해결 방안 등을 설명했습니다. 특히 메타데이터 활용의 중요성과 주의점, 그리고 실시간 모니터링을 위한 Slack 연동 등 실제 구현 과정에서 얻은 인사이트를 공유했습니다.
이 모든 과정은 많은 시행착오를 통한 결과였습니다. 처음에는 단순히 기술적 구현에만 집중했지만, 실제 운영 과정에서 데이터의 일관성 유지, 시스템 안정성 확보, 사용자 경험 개선 등 다양한 측면을 고려해야 한다는 것을 깨달았습니다. 특히 인제스천 시간의 변동성 문제는 예상치 못한 도전이었지만, 이를 통해 더욱 유연하고 효율적인 시스템을 구축할 수 있었습니다.
다음 포스팅에서는 이렇게 구축된 RAG 시스템을 기반으로 한 LLM Agent 시스템 구축 과정을 소개하겠습니다.
Share article