엔터프라이즈 데이터 분석을 위한 생성형 AI 기반 비즈니스 인텔리전스가 등장하면서 인사이트에 대한 접근성이 향상되고 이러한 인사이트의 속도, 관련성, 정확성도 높아졌다.

그러나 이런 이야기는 어디까지나 최상의 시나리오를 전제한 것이다. AI 기반 분석을 실행하는 데이터 팀은 환각, 보안 및 거버넌스 혼란, 유효 기간이 지났거나 부정확한 답변, 틈새 전문 분야에 대한 이해 부족, 그리고 사유 데이터에 근거한 답변은 제공할 수 없다는 제약 등의 문제에 흔히 직면한다. 이러한 과제의 상당수는 한 가지 요인에 기인한다. 생성형 BI의 기반을 형성하는 LLM은 학습 데이터에서만 답변을 도출할 수 있으며, 이 학습 데이터는 대부분 정적이고 경직돼 있다는 점이다.

검색 증강 생성(RAG)이 이 문제에 대한 해결책을 제시하지만, RAG가 항상 모범적인 결과를 도출한다고 보장할 수는 없다. RAG 기술에 대해 매우 회의적인 일부 전문가들은 실제 환경의 RAG 구현이 성공적인 결과로 이어지는 비율은 25%에 불과한 것으로 추정한다.

구글이 서던 캘리포니아 대학과 공동으로 발표한 최근 연구 논문에 따르면 RAG로 강화된 모델 출력에 사용자 질문에 대한 직접적인 답변이 포함된 경우는 30%에 그쳤으며, 문제가 있는 출력의 경우 그 원인은 대부분 내부 정보와 검색된 정보 간의 충돌인 것으로 나타났다.

올바르게 구현된 RAG는 내부 지식 기반, 사유 데이터베이스, 문서 저장소를 비롯한 외부 소스에서 검색된 데이터를 활용해 LLM 지식을 증강한다. 이를 통해 AI 분석 엔진은 당면한 주제에 대한 정확한 최신 데이터로 일반적인 시장 지식을 강화할 수 있다.

RAG 생성형 BI 애플리케이션의 과제

데이터 분석 팀이 RAG를 도입하는 가장 큰 이유는 인사이트의 정확성을 높이는 데 있다. 출력 품질을 검증할 담당자 없이 비즈니스 사용자가 단독으로 작업하는 셀프 서비스 환경에서 이는 특히 중요한 부분이다.

RAG의 정확성은 실제로 제한적일 수 있다. 안타깝지만 이것이 큰 단점이다.

또한 팀은 다음과 같은 부분에서도 어려움을 겪을 수 있다.

• LLM을 민감한 사유 데이터에 연결할 때 데이터 프라이버시, 데이터 거버넌스, 규정 준수 보장
• 복잡한 환경에서 데이터 찾기
• RAG 아키텍처의 드리프트 방지

물론 성공 사례도 많다. 예를 들어 제약 연구원들이 과학 논문을 기반으로 생물의학 관련 질문에 답하는 RAG 커넥터인 PaperQA를 평가한 결과 정확도는 86.3%로 나타났다. GPT-4의 57.9%에 비해 월등히 높다. 까다로운 질문을 사용해 테스트한 또 다른 사례에서는 환각 없이 69.5%의 정확도와 약 87.9%의 정밀도를 달성했다. 생물의학 분야 전문가와 비슷한 수준이다. 대조적으로, RAG가 아닌 LLM의 환각 비율은 40~60%에 이르는 것으로 보고된다.

RAG의 성공적인 사례

광범위한 LLM 지식과 좁은 영역에 특화된 RAG 데이터의 조합은 많은 업종에서 중요한 역할을 한다.

예를 들어 의료와 금융 분야는 모두 관련 코호트 집단 대비 특정 개인에 초점을 맞춘 입력을 기반으로 높은 정확도를 요구한다. 과학 연구, 법률, 규정 준수 기업은 복잡한 질문에 답하기 위해 방대한 양의 문헌을 검색한다. 제조 및 공급망 기업은 회사 고유의 상황을 해석해야 할 때 글로벌 데이터 신호를 고려해야 하는데, 이러한 신호는 매우 다양할 수 있다.

그 결과 RAG는 데이터 분석의 필수적인 기반으로 빠르게 자리 잡고 있다. 피라미드 애널리틱스(Pyramid Analytics)의 CTO인 아비 페레즈는 더 비즈니스 오브 테크(The Business of Tech)와의 인터뷰에서 “RAG는 기본적으로 기업의 사유 데이터 집합, 즉 정보를 수집하고 쿼리해서 LLM 흐름의 일부로 사용하는 비즈니스”라고 설명했다.

“애크미 코퍼레이션(Acme Corporation)에 대해 질문하고 싶다고 가정해 보자. LLM이 애크미에 대한 자세한 정보를 갖고 있는 것이 아니다. 누군가 애크미의 모든 문서를 가져와 그래프 데이터베이스에 넣은 다음 RAG 기술을 적용한다. 최종 사용자가 질문하면 데이터베이스의 일부를 가져와 벡터화한 다음 LLM과 결합해 지능적인 답변을 제공한다.”

그러나 RAG 자체가 마법의 지팡이는 아니다. RAG 기반 답변의 정확도가 낮다는 보고도 많고, 데이터 분석 팀은 ROI 달성이 가능하도록 RAG 프로세스를 설정하는 데 자주 어려움을 겪는다.

성공을 위해 도움이 되는 5가지 팁은 다음과 같다.

1. 데이터를 체계적으로 정비

방사선학 분석을 위해 RAG 도입한 에모리 의과대학의 주디 W. 기초야 박사는 “RAG 시스템의 품질은 전적으로 지식 라이브러리에 의해 좌우된다. 이 라이브러리가 특정 주제를 과대 표현하고 다른 주제를 과소 표현한다면 시스템도 그러한 편향을 반영해 동작한다”고 말했다.

RAG의 정확도는 RAG가 활용하는 데이터에 따라 좌우되지만 대부분의 데이터는 사일로화되고 분산된 채 레거시 인프라에 저장돼 있고, 경우에 따라서는 편향성도 내제하고 있다.

기업 정보 신호를 데이터 레이크에 넣어두고 필요할 때까지 비정형, 비표준 상태로, 레이블과 색인도 제대로 지정하지 않은 채 방치하는 경우가 많다. RAG 아키텍처는 이러한 상황에 처한 모호한 데이터를 해석할 수 없으며 일관된 분석을 생성하는 데 필요한 정보를 판별할 수도 없다.

모든 AI 프로젝트가 그렇듯이 분석을 위해 RAG를 구현할 때는 먼저 모든 데이터를 정비하는 것이 중요하다.

• 가장 가치 있는 데이터 소스 파악
• 관련성이 없거나 유효 기간이 지난 정보 삭제
• 텍스트 형식을 표준화
• 메타데이터를 검증하고 정리
• 필요에 따라 개선 및 보강

그런 다음 이 모든 것을 반복 가능한 프로세스로 전환해서 반복적인 데이터 준비 파이프라인으로 만들어야 한다. 시간이 지나면서 더 많은 데이터가 계속해서 유입되고 기존 데이터는 무의미해지며 오래된 데이터는 제거해야 하기 때문이다.

KX의 데이터 과학자인 라이언 시글러는 “데이터 품질은 RAG 파이프라인 성공의 기반이다. 전처리를 통해 잠재적인 문제를 선제적으로 제거하거나 완화할 수 있다”고 말했다.

2. 벡터화 제대로 하기

벡터화는 RAG 프로세스의 근간으로, 복잡한 데이터를 벡터 임베딩이라는 수치 벡터로 변환해서 검색의 정확성과 속도를 높인다.

RAG 아키텍처는 청크 단위의 벡터를 사용해서 LLM이 응답에 사용할 가장 관련성 높은 데이터를 검색한다. 효과적인 벡터화를 통해 사유 소스를 더 광범위한 LLM 데이터와 더 효율적으로 병합할 수 있다.

즉, 벡터화 선택은 RAG의 성공에 매우 중요하다. 선택 가능한 주요 옵션은 다음과 같다.

• 벡터 데이터베이스: 문서 임베딩을 저장하고 빠르게 확장되며, 고급 인덱싱 및 벡터 쿼리를 위한 분산 스토리지 지원
• 벡터 라이브러리: 벡터 임베딩을 저장하기 위한 더 빠르고 가벼운 방법
• 기존 데이터베이스에 통합된 벡터 지원: 벡터 임베딩을 저장하고 쿼리를 지원

최선의 선택은 각자 처한 상황에 따라 다르다. 예를 들어 벡터 네이티브 데이터베이스는 가장 강력한 방법이지만, 비용과 리소스가 너무 많이 소비되므로 규모가 작은 조직에서는 실용성이 떨어진다. 벡터 라이브러리는 속도가 빨라 지연 문제를 해결하기에 적합하고, 벡터 기능 통합은 가장 쉽지만 확장성이 떨어져 대규모 엔터프라이즈 요구사항을 충족하기 어렵다.

3. 견고한 검색 프로세스 구축

이름에서 알 수 있듯이 RAG의 목적은 올바른 데이터를 검색해서 정확한 응답을 작성하는 데 있다. 그러나 단순히 RAG 인프라를 데이터 소스에 연결하는 것으로 최선의 답변을 기대할 수는 없다. 특히 관련성에 중점을 두고 RAG 시스템에 관련 정보를 검색하는 방법을 학습시켜야 한다. RAG 시스템이 데이터를 과수집하고 그에 따라 과다한 노이즈와 혼란을 야기하는 경우가 너무 많다.

딥러닝 및 LLM 프로젝트 자문 전문가인 이반 팔로마레스 카라스코사는 “실험 연구에 따르면 검색의 질이 양보다 훨씬 더 중요하다. 실제로 수가 더 적더라도 관련성이 높은 문서를 검색하는 RAG 시스템이 최대한 많은 컨텍스트를 검색하려고 시도하는 시스템보다 더 좋은 성능을 보여준다. 후자의 경우 관련성이 충분하지 않은 정보로 인해 정보 과잉이 발생한다”고 지적했다.

RAG 검색의 모범 사례는 다음과 같다.

• 계층적 검색과 동적 컨텍스트 압축을 사용해 프로세스 최적화
• 의심스러운 콘텐츠를 자동으로 플래그 처리하거나 제외하는 메타데이터 필터링 파이프라인 설정
• 검색과 쿼리 사이에 검증 계층 추가
• 컨텍스트 청킹과 늦은 청킹을 포함한 신중한 청크 관리(청크가 너무 짧으면 컨텍스트가 부족하고, 너무 길면 노이즈가 너무 많을 수 있음)
• 수동으로 레이블을 지정한 학습 데이터 집합에 투자해서 관련성을 인식하도록 순위 알고리즘 교육
• 지속적인 개선을 위해 정밀도, 재현율, F1 점수와 같은 검색 성능 지표 평가

4. 통제력 구축

RAG 사용 여부와 관계없이 데이터 프라이버시와 보안, 데이터 거버넌스, 규정 준수는 제대로 되지 않을 경우 모든 데이터 프로젝트를 망칠 수 있는 요소이며, 특히 여러 시스템을 연결하는 경우 더욱 그렇다.

RAG는 외부와 접할 수 있는 LLM을 사유 데이터와 연결하므로 민감한 정보가 노출될 위험을 높인다. 규제에 따라 PII 데이터에 대해 이러한 단계를 아예 금지하는 경우도 있고, 규정 준수를 위해 복잡한 가드레일과 보호 조치를 요구하는 경우도 있다.

이와 동시에 데이터 거버넌스를 보장하고 정보의 노후화 또는 편향을 방지하기 위한 제한 조치도 반드시 필요하다. 데이터 수집, 접근, 관리, 저장 관행에 대한 통제는 데이터 유출을 방지하고 오염으로부터 보호하는 데 있어 매우 중요하다.

RAG 관련 데이터 제어 모범 사례는 다음과 같다.

• 역할 기반 액세스 관리
• 데이터 소스를 검증하기 위한 데이터 계보 추적
• 모든 질의, 응답, 검색된 소스에 대한 감사 추적(로깅) 유지
• 민감한 데이터 액세스에 대한 가드레일 설정
• PII와 같은 데이터에 대한 명확한 정책 수립 및 시행
• 응답에 존재하는 잠재적 편향성을 적극적으로 파악하고 해결
• 생성형 AI에 특화된 정확도 측정 구현

5. 프롬프트 엔지니어링의 중요성 인식

데이터 엔지니어와 분석 프로젝트 리더는 프롬프트 엔지니어링 기술의 필요성을 간과하고 이를 LOB 사용자가 스스로 익혀야 할 부분으로 치부하는 경우가 많은데, 이는 심각한 문제가 될 수 있다. 특히 RAG가 관련되는 경우 BI 쿼리의 정확성을 위해서는 잘 설계된 쿼리가 필수적이기 때문이다.

혼란스럽거나 모호한 프롬프트는 LLM이 부정확한 정보를 활용하고 컨텍스트를 오해하고 잘못된 답변을 내놓도록 유도할 수 있다. 좋은 프롬프트를 작성하는 방법을 모르는 사용자는 프롬프트 자체에 문제가 있음을 인지하지 못하고 생성형 BI 설정, 궁극적으로는 RAG 프로세스를 탓할 수 있다.

트리하이브 스트래티지(TreeHive Strategy)의 도널드 파머는 “프롬프트 엔지니어링을 최종 사용자 문제처럼 취급해서는 안 된다. 잘 설계된 프롬프트는 LLM이 검색된 정보를 컨텍스트에 맞게 이해하고 적절한 응답을 생성하는 데 도움이 된다”고 말했다.

프롬프트 엔지니어링의 모범 사례는 다음과 같다.5

• 가장 일반적인 사용 사례에 대한 프롬프트 템플릿 표준화
• 출처 인용에 대한 명확한 지침 수립
• 프롬프트 템플릿 테스트 및 반복
• 직원을 위한 교육 제공
• 답변의 세부 수준과 형식 지정

RAG에 대한 올바른 접근은 효과적인 분석 프로젝트의 바탕이 된다.

AI 기반 데이터 분석이 기업 의사 결정에서 점점 더 중요한 역할을 하면서 인사이트의 정확성과 관련성, 적시성을 보장하는 것도 더욱 중요해지고 있다. RAG는 열쇠를 쥐고 있지만, 그 열쇠는 신중함과 지식을 갖추고 구현돼야만 기능한다. 데이터 처리와 관리, 검색, 그리고 프롬프트 엔지니어링에 대한 올바른 접근 방식을 취하는 것이 성공을 위한 기반이다.
dl-itworldkorea@foundryco.com