Amazon Bedrock, LLM 환상 문제 해결 사례

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

데이터 분석

대상자

LLM(대규모 언어 모델)과 RAG(검색 기반 생성) 파이프라인을 사용하는 소프트웨어 개발자 및 데이터 분석자.

• 난이도: 중간 (LLM의 환상 문제와 데이터베이스 설정 이해 필요)

핵심 요약

• LLM 환상 문제는 OpenSearch Serverless Collection 기반의 Amazon Bedrock Knowledge Base에서 Jira 티켓 데이터 처리 시 지속적으로 발생했다.
• Aurora Postgresql 기반의 Bedrock Knowledge Base로 전환 후, 13개의 Jupyter 티켓을 정확히 검색할 수 있었다.
• 합성 데이터(synthetic data)를 사용한 실험에서, 짧은 설명 필드가 환상 문제 해결에 긍정적인 영향을 미쳤다.

섹션별 세부 요약

1. 문제 발생 배경

• Claude V2.0 및 Amazon Titan Text Embeddings을 사용해 Jira 티켓 데이터를 분석하려 했으나, LLM 환상으로 인해 정확한 결과를 얻지 못했다.
• 4,000개의 Jira 티켓 중 "Jupyter" 키워드가 포함된 티켓은 13개였으나, Bedrock은 항상 2~4개만 반환했다.
• OpenSearch Serverless Collection 기반의 벡터 저장소가 원인으로 추정됨.

2. 해결 시도 및 실패

• Claude 3.5 업데이트 후 개선 사항이 있었으나, 예상보다 낮은 성능을 보였다.
• 프롬프트 수정, 소스 청크 조정, 검색 유형 변경 등 다양한 설정 변경 시도했으나, 결과 개선 없음.
• "Jupyter" 키워드가 전혀 언급되지 않은 비논리적인 응답도 발생했다.

3. 해결책 발견: Aurora Postgresql 기반 전환

• 2025년 4월 22일에 Aurora Postgresql 기반 Bedrock Knowledge Base를 사용했을 때, 13개의 Jupyter 티켓을 정확히 검색할 수 있었다.
• 합성 데이터 생성 시, 원본 데이터보다 짧은 설명 필드를 사용했을 때 성능이 향상되었다는 점을 확인.
• Aurora Postgresql은 OpenSearch Serverless보다 비용 효율적이었다 (OpenSearch: ~$5/일).

4. 추가 검증 및 제한 사항

• Aurora Postgresql과 OpenSearch Serverless에서 합성 데이터를 사용하면 동일한 성능을 보였으나, 실제 데이터에서의 검증이 필요하다.
• LLM의 환상 문제는 데이터 품질과 데이터베이스 설정에 따라 달라질 수 있음.

결론

• LLM 환상 문제 해결을 위해 짧은 설명 필드의 합성 데이터와 Aurora Postgresql 기반의 Bedrock Knowledge Base 사용을 권장.
• 비용 효율성을 고려할 경우 Aurora Postgresql이 더 유리하나, 실제 Jira 티켓 데이터 기반의 추가 테스트가 필요.