line·2025년 5월 23일원문

문의 대응을 효율화하기 위한 RAG 기반 봇 도입하기 (새 탭에서 열림)

LY 주식회사의 SR(Service Reliability) 팀은 반복되는 AWX 플랫폼 관련 문의를 효율적으로 처리하기 위해 RAG(검색 증강 생성) 기반의 지원 봇을 도입했습니다. 이 시스템은 사용자가 방대한 가이드 문서를 읽지 않고 중복된 질문을 던질 때 발생하는 운영 리소스 소모 문제를 해결하기 위해 고안되었습니다. 사내 위키와 과거 상담 이력을 활용해 정확도 높은 답변을 생성함으로써 관리자의 개입 없이도 사용자 문제를 신속하게 해결하는 성과를 거두었습니다. **AWX 지원 봇의 기술 스택 및 구성** - **LLM 및 프레임워크:** OpenAI의 GPT 모델을 메인 엔진으로 사용하며, LangChain 프레임워크를 통해 전체적인 워크플로를 관리합니다. Slack과의 연동은 Bolt for Python을 활용했습니다. - **임베딩 모델:** 다국어 지원 및 문장 비교 성능이 뛰어난 'paraphrase-multilingual-mpnet-base-v2' 모델(SBERT)을 선택하여 글로벌 임직원의 다양한 언어 문의에 대응합니다. - **벡터 데이터베이스:** 사내에서 PaaS 형태로 제공되어 접근성이 높은 OpenSearch를 사용하며, 텍스트 데이터를 고차원 벡터로 변환하여 저장하고 검색합니다. **RAG 및 벡터 검색을 통한 답변 정확도 향상** - **LLM의 한계 극복:** 학습되지 않은 최신 정보 부재나 허위 정보 생성(Hallucination) 문제를 해결하기 위해, 질문과 관련된 신뢰할 수 있는 컨텍스트를 LLM에 함께 전달하는 RAG 기법을 적용했습니다. - **벡터 검색 원리:** 사용자의 질문을 임베딩하여 벡터화한 뒤, 벡터 DB 내에서 의미적으로 유사한 문장들을 k-NN(최근접 이웃) 방식으로 검색하여 최적의 참고 자료를 추출합니다. - **유사도 기반 추출:** 단순 키워드 매칭이 아닌 의미적 유사성을 판단하므로, 'Buy'와 'Purchase'처럼 단어는 달라도 맥락이 같은 정보를 정확히 찾아낼 수 있습니다. **봇 워크플로 및 데이터 활용 전략** - **사용자 상호작용:** 사용자가 Slack으로 문의하면 봇이 사내 위키와 과거 Slack 스레드 데이터를 검색합니다. 추출된 데이터를 바탕으로 LLM이 1차 답변을 제공하며, 해결되지 않을 경우에만 '관리자 호출' 버튼을 통해 담당자를 연결합니다. - **데이터 소스 다각화:** 공식 가이드 문서뿐만 아니라 실제 사용자들이 겪었던 문제와 해결책이 담긴 'Slack 문의 스레드 데이터'를 함께 인덱싱하여 실무적인 답변이 가능하도록 구성했습니다. - **리소스 최적화:** 봇의 자동 응답을 통해 단순 반복 문의에 대한 관리자의 수동 대응 시간을 줄이고, 개발 조직이 서비스 운영 본연의 업무에 더 집중할 수 있는 환경을 조성했습니다. RAG 기반 시스템을 구축할 때 가장 중요한 것은 신뢰할 수 있는 데이터 소스의 확보입니다. LY의 사례처럼 공식 문서와 실제 상담 이력을 병행 활용하면 LLM이 훨씬 구체적이고 실무에 유효한 답변을 생성할 수 있습니다. 운영 중인 서비스의 문의 대응 리소스가 부담된다면, 익숙한 벡터 DB와 오픈소스 임베딩 모델을 조합한 RAG 봇 도입을 적극 추천합니다.

RAGAIPythonvector-db+5

google·2025년 5월 13일원문

검색 확대 생성에 대한 깊이 있는 통찰: 충분한 맥락의 역할 (새 탭에서 열림)

검색 증강 생성(RAG) 시스템의 성능을 최적화하기 위해 단순히 질문과 '관련된' 정보를 찾는 것을 넘어, 답변을 내기에 '충분한 문맥(Sufficient Context)'이 제공되었는지를 판단하는 새로운 관점을 제시합니다. 연구팀은 문맥의 충분성을 측정하는 자동 평가 도구(autorater)를 개발하여 RAG 시스템의 실패 원인을 분석하고 할루시네이션(환각)을 줄일 수 있는 방법론을 입증했습니다. 이를 통해 최신 대규모 언어 모델(LLM)이 충분한 정보 환경에서 어떻게 작동하는지 규명하고, 실제 서비스인 Vertex AI RAG 엔진에 해당 기술을 적용하여 정확도를 개선했습니다. **충분한 문맥의 정의와 필요성** * **관련성 vs 충분성**: 기존 RAG 연구는 질문과 문맥의 '관련성'에 집중했으나, 관련성이 높더라도 정답을 도출하기 위한 핵심 정보가 빠져 있으면 LLM은 잘못된 답변을 내놓을 위험이 큽니다. * **충분한 문맥**: 질문에 대해 확정적인 답변을 제공하는 데 필요한 모든 정보가 포함된 상태를 의미합니다. * **불충분한 문맥**: 질문과 관련은 있지만 정보가 불완전하거나, 결론을 내릴 수 없거나, 모순되는 정보가 포함된 경우를 말합니다. **LLM 기반 자동 평가 도구(Autorater)의 설계 및 성능** * **평가 메커니즘**: 질문과 검색된 문맥 쌍을 입력받아 해당 문맥이 답변에 충분한지 여부를 'True/False'로 분류하며, 체인 오브 쏘트(CoT) 및 1-샷 프롬프팅을 통해 성능을 최적화했습니다. * **높은 분류 정확도**: Gemini 1.5 Pro를 활용한 이 방식은 별도의 미세 조정 없이도 전문가가 직접 레이블링한 데이터와 비교했을 때 93% 이상의 높은 일치율을 보였습니다. * **기존 방식과의 비교**: 정답 키워드 포함 여부를 확인하는 방식이나 기존의 자연어 추론(NLI) 모델 기반 방식보다 Gemini를 활용한 프롬프팅 방식이 뛰어난 문맥 이해력을 바탕으로 더 정교한 판단을 내리는 것으로 나타났습니다. * **효율적 대안**: 계산 자원의 효율성이 필요한 경우, Gemini보다는 다소 성능이 낮지만 미세 조정된 FLAMe(PaLM 24B 기반) 모델이 대안이 될 수 있음을 확인했습니다. **RAG 시스템 성능 분석 및 실무적 통찰** * **SOTA 모델의 특성**: Gemini, GPT, Claude와 같은 최신 모델들은 충분한 문맥이 주어지면 정답률이 매우 높지만, 문맥이 불충분할 때 "모른다"고 답하며 할루시네이션을 방지하는 능력에는 차이가 있었습니다. * **성능 최적화 도구**: 이번 연구의 개념은 Google Cloud Vertex AI RAG 엔진의 'LLM Re-Ranker' 기능으로 구현되었습니다. 이는 검색된 스니펫을 질문과의 관련성 및 충분성에 따라 재정렬하여 nDCG와 같은 검색 지표 및 전체 시스템 정확도를 높입니다. * **실패 분석**: RAG 시스템의 실패는 단순히 검색 품질의 문제뿐만 아니라, 충분한 정보가 있음에도 모델이 이를 제대로 추출하지 못하거나 불충분한 정보에서 억지로 답을 지어내는 과정에서 발생함을 확인했습니다. RAG 시스템의 신뢰도를 높이기 위해서는 단순히 더 많은 문서를 검색하는 것보다, 검색된 결과가 질문에 답하기에 '충분한지'를 먼저 검증하는 단계가 필수적입니다. 개발자는 고성능 LLM을 활용한 자동 평가 단계를 파이프라인에 추가하거나, 리랭커(Re-ranker)를 도입하여 문맥의 질을 관리함으로써 할루시네이션을 획기적으로 줄일 수 있습니다.

RAGAI대규모 언어 모델gemini+5

microsoft·2025년 3월 3일원문

마이크로소프트 엔지 (새 탭에서 열림)

마이크로소프트는 자사 엔지니어들이 대규모 AI 애플리케이션을 구축하는 실제 방법론을 공유하기 위해 'How Microsoft engineers build AI' 비디오 시리즈를 새롭게 공개했습니다. 첫 번째 에피소드에서는 'Copilot for Azure' 내의 'Ask Learn' 플러그인 개발 사례를 통해 검색 증강 생성(RAG) 기술을 안정적으로 구현하고 확장하는 핵심 전략을 다룹니다. 이를 통해 개발자들은 기업 내부 데이터와 대규모 언어 모델(LLM)을 결합하여 정확하고 맥락에 맞는 AI 서비스를 구축하는 실질적인 통찰력을 얻을 수 있습니다. ### RAG 기술의 핵심과 활용 차별화 * RAG(검색 증강 생성)의 기본 개념을 정립하고, 모델의 가중치를 직접 수정하는 파인튜닝(Fine-tuning) 기술과 비교하여 RAG가 가진 차별적 우위를 설명합니다. * Copilot in Azure뿐만 아니라 Microsoft Security Copilot, Dynamics 365 Business Central 등 마이크로소프트의 주요 제품군에 RAG가 실제로 어떻게 적용되어 비즈니스 가치를 창출하는지 사례를 제시합니다. * 단순한 이론을 넘어, 실제 서비스 환경에서 LLM이 고유 데이터에 접근하여 답변의 신뢰도를 높이는 메커니즘을 상세히 다룹니다. ### 엔지니어링 단계에서의 도전 과제와 해결책 * RAG 시스템 구축 시 직면하는 주요 난관인 콘텐츠 선택, 데이터 전처리(Preprocessing), 그리고 성능 평가(Evaluation) 과정을 체계적으로 관리하는 방법을 공유합니다. * 플러그인이 사용자에게 최신 상태의 정확한 정보를 실시간으로 전달할 수 있도록 보장하는 혁신적인 엔지니어링 솔루션을 소개합니다. * 프로토타이핑 단계에서 흔히 발생하는 실수들을 짚어보고, 이를 방지하기 위한 데이터 관리 및 운영상의 베스트 프랙티스를 제안합니다. ### Ask Learn 플러그인 구현 사례 분석 * Azure 개발자들이 작업 흐름을 방해받지 않고 몇 초 만에 답을 얻을 수 있도록 설계된 'Ask Learn'의 실제 작동 시연을 포함하고 있습니다. * 제품 관리자(PM)와 수석 소프트웨어 엔지니어링 매니저 등 실제 개발 주역들의 인터뷰를 통해, 대규모 스케일에서 RAG 솔루션을 안정화하기 위해 사용된 구체적인 기술 스택과 의사결정 과정을 공개합니다. * 사용자의 질문 의도에 가장 적합한 문서를 검색하고 이를 기반으로 맥락에 맞는 답변을 생성하는 구체적인 워크플로우를 학습할 수 있습니다. 성공적인 AI 애플리케이션 구축을 위해서는 Microsoft Learn의 관련 문서와 가이드를 참고하는 것이 좋습니다. 또한, 현재 무료로 제공되는 GitHub Copilot이 포함된 Visual Studio IDE를 활용하면 RAG 기반 앱 개발을 더욱 효율적으로 시작할 수 있습니다.

RAGAI대규모 언어 모델머신러닝+4

figma·2024년 10월 24일·3분 읽기큐레이션 요약

Figma에서 AI 기반 검색을

디자이너들은 새로 작업하기보다 기존 디자인을 찾아 재활용하는 경우가 많지만, 스크린샷만 가지고 원본 파일을 찾기는 어려웠습니다. Figma는 이 문제를 해결하기 위해 시각 검색과 의미 검색을 결합한 AI 검색을 출시했고, 검색 결과를 디자인 작업에 바로 활용할 수 있도록 했습니다. 초기에는 다음 컴포넌트를 추천하는 ‘디자인 자동완성’을 개발했지만, 사용자 연구를 통해 기존 작업을 찾고 변형하는 일이 더 근본적인 문제라는 결론에 도달했습니다. ## 기존 디자인을 찾기 어려운 문제 - 디자이너들은 원하는 디자인의 원본 파일을 찾기 위해 Slack에 동료에게 질문하거나 여러 파일을 직접 확인해야 했습니다. - 특히 파일명이나 컴포넌트 이름을 모른 채 스크린샷만 가지고 검색해야 하는 상황이 큰 문제였습니다. - Figma 내부에서도 디자인 요소를 찾는 데 상당한 시간이 소요되고 있다는 사실을 수백 건의 Slack 메시지를 통해 확인했습니다. - 이러한 문제를 해결하기 위해 Figma는 Config 2024에서 AI 기반 검색 기능을 공개했습니다. ## 시각 검색과 의미 검색 - **시각 검색(Visual search)** - 스크린샷, 선택한 프레임, 간단한 스케치 등을 입력해 유사한 디자인과 컴포넌트를 찾습니다. - 정확한 파일명이나 텍스트를 몰라도 이미지의 시각적 특징을 기반으로 검색할 수 있습니다. - **의미 검색(Semantic search)** - 사용자의 텍스트 질의를 AI가 이해하고 관련 디자인을 검색합니다. - 컴포넌트의 정확한 이름이나 설명을 몰라도 의도와 문맥에 맞는 결과를 찾을 수 있습니다. - 검색 결과는 단순히 파일을 여는 데 그치지 않고, 디자인을 미리 보거나 현재 프로젝트에 삽입하는 방식으로 활용할 수 있습니다. ## 디자인 자동완성에서 AI 검색으로 전환 - Figma는 2023년 6월 3일간의 AI 해커톤을 열었고, 20개의 프로젝트가 완성됐습니다. - 그중 하나가 작업 중인 화면을 분석해 다음에 필요할 컴포넌트를 추천하는 **디자인 자동완성** 프로토타입이었습니다. - 예를 들어 온보딩 화면을 만들 때 “Get started” 버튼을 추천하는 방식입니다. - 이 기능은 디자이너가 반복적인 작업에서 벗어나 사용자 문제와 같은 고차원적인 사고에 집중하도록 돕는 것을 목표로 했습니다. - 프로토타입의 가능성이 확인되면서 제품 로드맵에 포함됐고, 실제 제품화를 위한 개발이 시작됐습니다. ## RAG를 활용한 검색 기반 AI - Figma는 디자인 자동완성의 품질을 높이기 위해 검색 인프라를 함께 구축했습니다. - **Retrieval-Augmented Generation(RAG)**은 LLM이 답변을 생성하기 전에 관련 사례를 검색해 참고하도록 하는 방식입니다. - 자동완성 기능이 사용자가 작업 중인 화면과 유사한 기존 디자인을 찾으면, 그 사례를 바탕으로 더 적절한 다음 컴포넌트를 추천할 수 있다고 판단했습니다. - 즉, AI가 무작정 새로운 디자인을 생성하는 것이 아니라 Figma에 축적된 실제 디자인 사례를 검색하고 이를 추천의 근거로 활용하는 구조입니다. ## 사용자 연구가 바꾼 제품 방향 - Figma는 내부 팀에 프로토타입을 공유하고 디자이너들을 대상으로 사용성 연구를 진행했습니다. - 반복적인 테스트 과정에서 디자이너들이 작업을 완전히 새로 시작하지 않는다는 패턴을 발견했습니다. - 디자이너들은 과거의 탐색 결과와 기존 작업을 다시 찾아보고, 이를 변형하거나 조합해 새로운 결과물을 만듭니다. - 이 때문에 “다음에 무엇을 추천할까?”보다 “이미 존재하는 작업 중 무엇이 유용한가?”를 찾는 일이 더 근본적인 요구로 드러났습니다. - 이러한 관찰이 디자인 자동완성 중심의 방향을 AI 검색 중심으로 전환하는 계기가 됐습니다. Figma의 사례는 AI 기능을 먼저 만들고 사용자를 설득하기보다, 실제 업무에서 반복되는 불편을 관찰한 뒤 제품 방향을 조정해야 한다는 점을 보여줍니다. 특히 검색과 생성 AI를 결합하면 기존 자산을 재활용하면서도 더 정확한 추천을 제공할 수 있으므로, 조직 내 디자인 자산이 많을수록 시각·의미 검색과 RAG 기반 활용을 함께 고려할 만합니다.

원문 읽기(새 탭에서 열림)

RAG대규모 언어 모델semantic-searchai-search+2