RAG 시스템을 처음 만들 때는 대부분 기본 임베딩 모델을 그대로 사용합니다. 초반에는 검색이 꽤 잘 되는 것처럼 보입니다. 그런데 운영을 조금 해보면 이상한 검색 결과가 나오기 시작합니다. 저희 팀도 임베딩 모델 때문에 검색 품질 문제를 겪었던 경험이 있습니다.기본 임베딩 모델 사용 시 발생하는 검색 품질 문제RAG 시스템에서 가장 중요한 요소 중 하나는 임베딩입니다. 문서를 벡터로 변환하고 유사도를 기반으로 검색하기 때문입니다.저희 서비스에서도 FAQ 챗봇을 만들면서 벡터 검색을 도입했습니다. Elasticsearch 기반 벡터 인덱스를 사용했고 기본 임베딩 모델을 그대로 사용했습니다.초기 테스트에서는 꽤 괜찮은 결과가 나왔습니다. 문서가 약 3만 개 정도였고 검색 정확도도 나쁘지 않았습니다.문제가 ..
RAG 시스템을 처음 만들 때 대부분 문서를 한 번 임베딩해서 벡터 인덱스에 넣습니다. 초기 데모 단계에서는 잘 동작합니다. 그런데 운영 단계로 넘어가면 문제가 생깁니다. 문서가 계속 바뀌는데 인덱스는 그대로라는 상황입니다. LLM RAG 시스템에서 인덱싱 동기화 문제RAG 시스템에서 가장 흔하게 발생하는 문제 중 하나는 데이터 동기화입니다. 원본 데이터는 계속 업데이트되는데 벡터 인덱스는 업데이트되지 않는 경우입니다.저희 서비스에서도 FAQ 챗봇을 운영하면서 같은 문제가 발생했습니다. FAQ 데이터는 MySQL에 저장되어 있었고 Elasticsearch 벡터 인덱스에 임베딩을 저장하는 구조였습니다.초기에는 문서가 약 2만 개 정도였습니다. 수동으로 임베딩을 생성하고 인덱싱했습니다. 테스트 환경에서는 문..
RAG 시스템을 운영하다 보면 어느 순간 한계가 보입니다. 단순 문서 검색은 잘 되는데 관계가 있는 질문이 나오면 답변 품질이 갑자기 떨어집니다. 저희 팀도 이 문제 때문에 꽤 오래 고생했습니다. 결국 벡터 검색만으로는 해결되지 않는 질문이 있다는 것을 느끼게 되더군요.RAG 시스템에서 관계형 질문이 깨지는 문제RAG 시스템은 기본적으로 문서 유사도 기반 검색입니다. 질문과 가장 유사한 문서를 찾고 그 내용을 기반으로 답변을 생성합니다.초기에는 이 구조가 꽤 잘 동작합니다. 특히 FAQ, 정책 문서, 매뉴얼 같은 콘텐츠에서는 정확도가 좋습니다.하지만 서비스가 조금 복잡해지면 다른 유형의 질문이 등장합니다. 바로 관계형 질문입니다.예를 들어 이런 질문입니다. 특정 상품을 만든 회사는 어디인가. 그 회사의 ..
검색 품질은 생각보다 쉽게 무너집니다. 벡터 검색을 붙이면 좋아질 줄 알았는데 실제 운영에서는 전혀 다른 문제가 나오더군요. 특히 상위 K개만 가져오는 방식은 생각보다 많은 문제를 만듭니다. Re ranking 도입 전 운영에서 발생했던 검색 품질 문제Re ranking 이야기를 하려면 먼저 왜 필요한지부터 말씀드리는 게 좋겠습니다. 벡터 검색을 처음 붙이면 대부분 Top K 방식으로 결과를 가져옵니다. 저희도 Elasticsearch 기반 검색에 벡터 검색을 붙이면서 단순히 상위 K개 결과만 가져오는 구조로 시작했습니다.초기에는 문제가 없어 보였습니다. 검색 latency는 평균 70ms 정도였고 RPS는 150 수준이었습니다. 그런데 서비스가 커지면서 문서 수가 300만 건을 넘기기 시작하더군요. 그..
RAG 시스템을 운영하다 보면 반드시 한번 겪는 문제가 있습니다. 모델이 그럴듯하게 말을 하는데 실제로는 틀린 정보를 답하는 상황입니다. 이게 바로 환각입니다. 처음에는 모델 문제라고 생각했는데 운영을 하다 보니 시스템 구조 문제라는 걸 알게 되었습니다. RAG에서 환각을 줄이기 위해 실제로 운영에 넣었던 검증 레이어 이야기를 말씀드리겠습니다.RAG 환각 문제가 실제 서비스에서 어떻게 발생했는가RAG 시스템을 처음 붙이면 대부분 기대가 큽니다. 내부 문서를 기반으로 답을 하니까 정확할 것이라고 생각합니다. 저희도 Elasticsearch 기반 벡터 검색과 LLM을 붙여서 FAQ 챗봇을 만들었습니다.초기 트래픽은 RPS 40 정도였습니다. 하루 질문 수는 약 30만 건 정도였습니다그런데 문제가 하나 생기기..
RAG 시스템을 운영하다 보면 생각보다 단순한 부분에서 품질이 갈립니다. 대부분 모델이나 벡터 검색을 먼저 의심하지만 실제로는 문서를 어떻게 자르느냐가 더 중요하더군요. 바로 Chunking 전략입니다. 운영에서 여러 번 삽질해보니 답변 품질의 상당 부분이 여기서 결정됩니다.RAG 시스템에서 Chunking 전략이 왜 중요한가Chunking 전략은 RAG 시스템에서 문서를 어떤 단위로 나누어 벡터 인덱스에 저장할 것인지 결정하는 방식입니다. 처음 RAG를 만들 때 대부분 문서를 일정 길이로 잘라서 저장합니다. 저희도 처음에는 단순히 500 토큰 기준으로 문서를 나누었습니다.초기에는 큰 문제가 없어 보였습니다. 문서 수는 약 200만 개였고 Elasticsearch 벡터 검색 latency는 평균 90ms..
