벨루가 블로그

간단하게 적용 가능한 RAG 활용 사례 : LLM & RAG 프로젝트 by 벨루가 개요: RAG(Retrieval-Augmented Generation)는 대규모 언어 모델(LLM)에 외부 데이터 검색 기능을 결합하여, 더 정확하고 최신 정보를 제공하는 기술입니다. 단순히 학습된 내용에 의존하지 않고, 필요한 순간 관련 자료를 검색해 근거를 포함한 답변을 생성합니다. 이 글에서는 RAG를 활용한 10가지 프로젝트를 A흐름도로 표현하고 간단한 설명을 덧붙였습니다. 각 흐름도는 데이터 수집부터 검색, 응답 생성까지의 경로를 직관적으로 보여주며, 개발자와 기획자 모두가 이해하기 쉽게 구성해 봤습니다. 정말 간단하지만 어떻게 하냐에 따라 결과는 크게 바뀔수도 있다는 점 꼭 고려하면 좋겠습니다. 1) 개발자 문서/코드 어시스턴트 설명: 개발 문서와 소스 코드를 임베딩 후 검색, 재랭킹하여 LLM이 코드 예시와 함께 답변. 2) 계약/법률 문서 분석 설명: 법률 문서를 OCR, 조항 분석 후 검색. 근거 인용과 해석을 제공. 3) 의료 지식 QA 설명: 최신 의료 자료를 표준화하여 검색하고, 근거 기반 설명 제공. 4) 맞춤형 학습 튜터 설명: 학습 자료를 구조화해 검색, 개인화된 튜터링 제공. 5) 뉴스 요약 & QA 설명: 다중 뉴스 소스를 분석·요약, QA 기능 제공. 6) TripPlanner AI — 여행 일정 생성기 설명: 여행 데이터와 사용자의 제약 조건을 기반으로 일정 최적화. 7) ShopAdvisor — e커머스 고객 어시스턴트 설명: 제품 및 정책 데이터를 검색하여 고객 질문에 답변. 8) 이력서 코치

이번 글에서는 벨루가 RAG 평가 결과를 공유하고자 합니다. 벨루가의 RAG 시스템은 실제 업무에서 유용함을 보여주어 좋은 피드백을 받고 있으나, 객관적이고 정량적인 성능 검증을 위해 체계적인 평가를 진행하였습니다. 🤖전문적인 용어들은 벨루가 챗봇에 질문할 수 있습니다. 평가 개요 평가 데이터셋 Hugging Face의 allganize/RAG-Evaluation-Dataset-KO (금융 도메인, 60개 샘플) 롯데이노베이트 제공 데이터셋 (행정 도메인, 110개 샘플) 💡 참고: 두 데이터셋의 정답 데이터 스타일이 상이하여 점수 차이가 발생할 수 있습니다. 평가 설정 평가 지표: RAGAS의 4가지 핵심 지표 (answer-relevancy, faithfulness, context-precision, context-recall) 평가 모델: gpt-4.1 검색 문서 개수: top-4 *평가를 위한 문서 학습은 vision이 아닌 기본 PDF 학습으로만 진행하였습니다.* 올거나이즈 데이터셋(finance) 60개 평가 결과 Model faithfulness answer relevancy context precision context recall gpt-4.1 0.8410

우연히 알게 된 Contextual AI의 CEO인 다우어 킬라(Douwe Kiela)의 발표 내용을 접하면서, 실제로 그동안 벨루가 서비스를 운영하며 겪은 다양한 포인트와 90% 이상 공감되어 이 자리에 옮겨 봅니다. 킬라는 최근 AI 엔지니어 서밋에서 "운영 환경에서의 RAG 에이전트: AI 프론티어에서 배운 10가지 교훈"을 주제로 의미 있는 발표를 진행하며, 기업용 AI 시스템 구축에서 얻은 중요한 교훈과 통찰을 공유했습니다. 기업들이 AI 투자를 확대하는 반면, 여전히 많은 CIO들이 ROI를 실현하는 데 어려움을 겪고 있습니다. 실제로 포브스 연구에 따르면 기업의 75%는 아직 AI에서 실질적인 가치를 얻지 못하고 있으며, 맥킨지의 분석은 AI가 글로벌 경제에 4.4조 달러의 잠재적 부가가치를 제공할 수 있다고 전망했습니다. 그러나 현실은 ROI 실현이 쉽지 않다는 것입니다. 킬라는 두 가지 역설을 소개했습니다. 모라벡의 역설: AI가 인간에게 어려운 일은 쉽게 해내지만, 인간에게 쉬운 일은 여전히 어렵습니다. AI 컨텍스트 역설: LLM이 복잡한 작업에서는 뛰어나지만, 올바른 컨텍스트에서 인간의 전문성을 활용하는 데는 여전히 한계가 있습니다. 발표에서 강조된 운영 환경에서의 RAG 에이전트의 10가지 교훈은 다음과 같습니다: 전체 시스템이 중요: 좋은 AI 모델만으로는 부족하며, 효율적인 시스템 구성이 핵심입니다. 기업의 전문성 활용: AI는 일반적 문제보다는 기업 특화 문제 해결에서 더 강력합니다. 대규모 데이터가 경쟁력: 많은 데이터를 효과적으로 활용하는 능력이 중요합니다. 파일럿과 실제 서비스의 차이: 실제 서비스 운영의 복잡성을 초기에 고려해야 합니다. 빠른 출시가 중요: 완벽함을 기다리기보다 신속하게 출시하고, 사용자 피드백으로 개선해야 합니다. 엔지니어의 업무 자동화: 반복적이고 지루한 작업을 최소화하여 엔지니어가 중요한 일에 집중하도록 해야 합니다. AI를 쉽게 사용 가능하게: 기존 업무 프로세스와 AI의 통합을 원활하게 하여 사용성을 높여야 합니다. 즉각적 체감 결과 제공: 사용자들이 즉시 가치를 느낄 수 있는 사례를 만들어야 합니다.

어제(2025/4/15) OpenAI에서 GPT-4.1 모델이 출시 되면서 벨루가에서도 빠르게 업데이트를 할 수 있게 되었습니다. 이번 모델에서 가장 특별한 부분은 사실 API 사용자들만 사용가능하다는 부분이라고 할 수 있는데요. 목적이 매우 명확하고 실제 적용 후에도 의도가 잘 이해가 되었습니다. 특히 속도와 지시 프롬프트를 잘 따르는 부분이 상당히 인상적이었습니다. 그리고 발표 영상에서 언급한 GPT-4.1 만의 프롬프트 방법을 언급 하길래 좀 찾아본 결과 Cookbook 도 발견하게 되었습니다. Cookbook 가이드를 참고해서 현재 실 사용 중인 챗봇에 적용을 해 보았고 품질과 속도 개선을 바로 체감할 수 있었습니다. 그럼 간단하게 OpenAI의 GPT-4.1 프롬프팅 가이드를 소개하고, 이를 기반으로 우리 서비스의 RAG(검색 및 생성) 파이프라인에 바로 적용할 수 있는 고객 문의 템플릿 예시를 공유해 봅니다. 😃 이 가이드는 GPT-4.1이 코드 작성, 명령 수행, 긴 문맥 처리 능력에서 크게 향상된 점을 중심으로, 에이전트(Agentic) 워크플로우와 체인 오브 쏘트(Chain of Thought) 기법 등을 이용해 보았고, 이어서, 실제 업무에 바로 활용할 수 있도록 RAG 기반 고객 문의 프롬프트 템플릿을 개선하여 변수 선언과 참조 방식을 정리해 보았습니다. 📌 GPT-4.1 프롬프팅 가이드 요약 (아래 출처 참고) 1️⃣ 명확하고 구체적인 지시 핵심 포인트: GPT-4.1은 지시 사항을 매우 충실히 따릅니다. 따라서 원하는 동작을 끌어내기 위해서는 구체적이고 명확한 문장을 작성하는 것이 중요. 추가 지시: 원하는 결과가 나오지 않을 경우, 간단하게 재지시하거나 추가 정보를 제공하여 보완 가능. 2️⃣ 에이전트(Agentic) 워크플로우 지속성: 고객의 문제가 완전히 해결될 때까지 작업을 지속하도록 지시하게 작성 . 도구 활용: 모르는 부분은 검색이나 문서 요약 등 적절한 도구를 활용하여 보충. 계획 및 평가: 도구 호출 전후에 명확한 계획과 평가 단계 지시를 포함시켜 체계적인 문제 해결을 유도. 3️⃣ 도구 호출 (Tool Calls)

최근 추론 모델 프롬프팅에 대한 문의가 꽤 있어 간단하게 OpenAI의 공식 문서 토대로 정리해 보았습니다. 출처: https://platform.openai.com/docs/guides/reasoning-best-practices 추론 모델(reasoning models)을 효과적으로 프롬프팅하는 방법 이러한 모델들은 간단하고 직접적인 프롬프트가 가장 우수한 성능을 보인다. 일부 프롬프트 엔지니어링 기법(예: 모델에 "단계별로 생각하라"고 지시하는 것)은 성능 향상을 가져오지 못하거나 오히려 방해가 될 수 있다. 아래의 모범 사례를 참고하거나 프롬프트 예시로 시작하라. 개발자 메시지는 새로운 시스템 메시지이다: o1-2024-12-17 버전부터, 추론 모델은 시스템 메시지 대신 개발자 메시지를 지원하며, 모델 명세서에서 설명하는 명령 체계(chain of command) 동작에 부합한다. 프롬프트를 간단하고 직접적으로 유지하라: 모델은 짧고 명료한 지시 사항을 이해하고 응답하는 데 뛰어난 성능을 보인다. 생각 흐름(chain-of-thought) 프롬프팅을 피하라: 이 모델은 내부적으로 추론 과정을 수행하기 때문에, "단계별로 생각하라" 또는 "추론을 설명하라"와 같은 프롬프팅은 불필요하다. 명확성을 위한 구분자(delimiters)를 사용하라: 모델이 입력(input)의 구성 요소를 명확하게 해석하도록, 마크다운(markdown), XML 태그(tag), 구획(section) 제목 등과 같은 구분자를 사용하여 입력의 서로 다른 부분을 명확히 표시하라. 제로샷(zero-shot) 방식부터 시도하고, 필요하면 퓨샷(few-shot)을 사용하라: 추론 모델은 종종 좋은 결과를 내기 위해 예시가 없는(zero-shot) 프롬프트를 사용하는 것으로 충분하다. 따라서 먼저 예시 없이 프롬프팅을 시도하라. 보다 복잡한 출력 요구사항이 있다면, 입력과 원하는 출력의 예시 몇 가지를 프롬프트에 포함하면 도움이 될 수 있다. 이때 예시가 지시사항과 아주 밀접하게 일치하도록 주의하라. 예시와 지시사항이 불일치하면 성능이 저하될 수 있다. 구체적인 지침(guidelines)을 제시하라: 모델의 응답을 명시적으로 제약하고자 하는 사항이 있으면(예: "500달러 이하의 예산을 갖는 해결책을 제안하라"), 프롬프트에 이러한 제약 사항을 명확히 명시하라. 최종 목표(end goal)에 매우 구체적이 되어라: 지시사항에서 성공적인 응답을 얻기 위한 구체적인 매개변수(parameters)를 제시하고, 모델이 성공 기준(success criteria)을 만족할 때까지 반복하여 추론하도록 명확히 지시하라. 마크다운(Markdown) 형식: o1-2024-12-17 버전부터, API에서의 추론 모델은 기본적으로 마크다운 형식(markdown formatting)을 사용하여 응답하지 않는다. 모델이 마크다운 형식을 사용하여 응답하기를 원한다면, 개발자 메시지(developer message)의 첫 번째 줄에 "Formatting re-enabled"라는 문자열을 포함하라.

최근 개인적 그리고 실제 사용자들의 피드백을 바탕으로 Anthropic의 Claude Sonnet 3.7, OpenAI의 GPT-4.5, 그리고 Perplexity 서비스의 장단점을 정리해 보았습니다. 명확한 특성과 장단점을 제공하여 이를 토대로 적용해보면 도움이 될것 같습니다. Anthropic의 Claude Sonnet 3.7: 추론 능력을 강화한 하이브리드 모델 OpenAI의 GPT-4.5: 대화 능력과 감정적 이해력이 뛰어난 모델 Perplexity: 즉각적인 대응과 정보 접근이 뛰어남 Claude Sonnet 3.7: 강력한 추론 능력, 뛰어난 가성비 실제 사용자들은 Claude Sonnet 3.7의 뛰어난 추론 능력과 가성비를 높게 평가하고 있습니다. 특히 긴 문서 분석이나 복잡한 코딩 작업에서 탁월한 성능을 보였으며, 사용자가 신속하고 정확한 응답을 받을 수 있었습니다. 장점: 복잡한 문제 해결과 코드 분석에서 뛰어난 성능 발휘 경쟁 모델 대비 저렴한 가격 구조로 높은 가성비 제공 기업 환경에서 계획 수립과 데이터 분석 업무에 탁월 단점: 실시간 정보 접근이 제한적이며 최신 정보 업데이트가 필요 지나치게 상세한 답변으로 답변이 다소 장황해질 수 있음 GPT-4.5: 감성적 소통 능력은 우수하나 비용은 높음 GPT-4.5는 자연스러운 대화 능력과 사용자와의 감정적 교감 측면에서 뛰어난 평가를 받았으나 높은 가격 대비 체감 성능 개선 폭이 적다는 사용자 의견도 있었습니다. 장점: 감성적인 교감을 기반으로 사용자 맞춤형 대화 가능 기업 환경에서 문서 분석 및 복잡한 계획 수립에서 우수한 성능

최근 화두인 "Agent", "Agentic" 에 우리는 어떻게 만들지라는 고민을 계속하다가 몇가지 정리해 봅니다. 처음에는 프롬프트 체이닝으로도 할 수 있는게 많을 것 같은데(자율을 부여하면 현재 지식으로는 처리 속도가 느릴것 같아서) 라는 생각을 하다가도 일단 어차피 부딛혀 봐야 할 것 같아 좀더 생각해 보기로함. Agent 는 이미 많은 지식들이 공유되고 있어서 Agentic Ai 에 대해 어떤 모습을 할지 생각해봄. 우선 구조와 작동 원리를 OODA(관찰, 상황판단, 결정, 행동) 순환 구조가 필수적일것 같다는 생각을 해봅니다. (현재 기준으로는) 1. 왜 Agentic AI인가? 기존에 많이 쓰이던 Agent Ai는 주어진 명령이나 외부 사건이 있어야만 반응하는 “반응형” 구조를 갖추는 경우가 많습니다. 반면 Agentic AI는 스스로 학습하고 목표를 설정하여 필요할 때 능동적으로 움직이는 “자율형” 특성을 지니므로, 복잡한 상황에서도 보다 유연하고 주도적으로 문제를 해결해야 겠죠? 2. Agentic AI와 OODA 순환 구조 Agentic AI는 군사·산업 현장에서 널리 알려진 OODA 순환 구조를 기반으로 작동. 관찰(Observe): 실시간 데이터 수집, 감지 상황판단(Orient): 수집된 정보의 맥락 분석, 윤리·규제 측면 검토 결정(Decide): 위험 평가, 시뮬레이션을 통한 최적 해법 탐색 행동(Act): 실제 행동 실행, 피드백 결과 반영 이 과정을 반복하면서 스스로 상황에 적응하고 계속 학습하며, 예측 불가능한 문제에도 유연하게 대처할 수 있어야 인정 받지 않을까요? 3. Agentic AI의 특징을 간단히 보면... 핵심 원칙 자율 운영, 목표 지향성, 맥락 인지, 자기 개선

이 글에서는 Google의 AI 백서 "에이전트"를 간결하게 분석하고 요약하여 핵심 인사이트를 도출하고자 합니다. AI 모델과 AI 에이전트의 주요 차이점 AI 모델과 AI 에이전트는 AI 환경에서 서로 구별되지만 상호 연결된 구성 요소입니다. 대규모 언어 모델(LLM)과 같은 모델은 학습 데이터를 기반으로 응답이나 예측을 생성하도록 설계되었지만, 에이전트는 특정 목표를 달성하기 위해 자율적으로 행동함으로써 이 기능을 확장합니다. 에이전트는 모델을 외부 시스템 및 환경과의 상호 작용을 가능하게 하는 도구와 통합하여 정적인 지식과 동적인 실제 응용 프로그램 간의 격차를 해소합니다. 또한 에이전트는 단일 턴 예측에서 작동하는 모델과 달리 반복적인 추론 및 다단계 문제 해결을 가능하게 하는 오케스트레이션 레이어를 특징으로 합니다. 이러한 기능 덕분에 에이전트는 복잡한 작업에서 적응력이 뛰어나고 능동적이며 효과적입니다. AI 에이전트의 일반적인 아키텍처 (출처: Julia Wiesinger, Patrick Marlow, Vladimir Vuskovic의 "Agents") 아래는 여러 측면에서 주요 차이점을 비교한 것입니다. 지식 범위 AI 모델: 학습 데이터에 제한됨. AI 에이전트: 도구를 사용하여 외부 시스템을 통해 지식 확장. General Architecture Of An AI Agent (Source: “Agents” by Julia Wiesinger, Patrick Marlow and Vladimir Vuskovic) 컨텍스트 처리 AI 모델: 단일 추론, 세션 기록 관리 부족. AI 에이전트: 다중 턴 상호 작용을 위해 세션 기록 유지. 도구 통합 AI 모델: 기본 도구 구현 없음. AI 에이전트: 실제 상호 작용을 위한 기본 통합 도구. 추론 능력 AI 모델: 기본 논리 레이어 없음, 사용자 정의 프롬프트에 의존.

RAG Orchestration & Grounding, 왜 중요할까요? 안녕하세요! 오늘은 인공지능 분야에서 요즘 가장 뜨거운 화두 중 하나인 RAG(Retrieval-Augmented Generation) 개념을 조금 더 쉽고 부드럽게 풀어보고자 합니다. RAG는 간단히 말해, 외부 지식(문서, 데이터베이스 등)을 ‘검색(Retrieval)’해 와서 LLM(Large Language Model)의 답변 생성(Generation)에 반영하는 방식인데요. 이렇게 하면, 모델이 맥락이나 사실 관계를 더 정확하게 반영할 수 있어요. 그런데 RAG를 더 효과적으로 활용하려면, Orchestration(오케스트레이션)과 Grounding(그라운딩)이라는 두 개념을 반드시 짚고 넘어가야 합니다. 둘 다 RAG 시스템을 구축하고 운영하는 데 필수적인 요소이지만, 초점과 역할이 조금 달라요. 오늘은 이 둘이 무엇이고, 왜 중요한지를 이야기해 보겠습니다. RAG Orchestration: RAG 시스템의 ‘지휘자’ 먼저 RAG Orchestration부터 살펴볼게요. 말 그대로 **‘오케스트라를 지휘하는 것’**을 떠올리시면 좋습니다. 오케스트라에는 다양한 악기와 연주자가 있잖아요? 이들을 조화롭게 연주하게 만들어야 아름다운 음악을 들을 수 있죠. RAG도 마찬가지로, 검색 단계, 프롬프트 엔지니어링, LLM 호출, 결과물 후처리 등 여러 단계를 효율적으로 관리해야 원하는 답변을 얻어낼 수 있습니다. 1) 어떤 검색 전략을 쓸 것인가? 키워드 검색을 쓸지, 의미론적 검색(벡터 검색)을 쓸지, 혹은 둘을 혼합할지 정하는 과정입니다. 예를 들어, 간단한 사실확인에는 키워드 검색이 효율적일 수 있지만, 맥락이 복잡한 질문에는 의미론적 검색이 더 유리하겠죠. 2) 검색 결과, 어떻게 처리할까? 검색해 온 문서들이 모두 유의미한 것은 아닐 겁니다. 관련성이 낮은 문서는 제거하고, 핵심 내용만 추려서 요약하거나, 여러 문서에서 중요한 정보를 통합하는 등 **결과물을 ‘가공’**해줘야 합니다. 3) 프롬프트 엔지니어링: LLM에 정보를 ‘어떻게’ 넣을까? 검색된 정보를 LLM에 건네줄 때, 어떤 형식으로 전달할지 결정하는 과정입니다. 예를 들면 “이 문서를 참고해서, 질문에 답변해 줘”처럼 간단히 할 수도 있고, “이런 질문이 있으니, 이 문서들의 내용 중 핵심만 추려서 구체적으로 답해줘”처럼 구체적으로 지시할 수도 있죠. 4) LLM 호출 및 후처리 어떤 LLM을 쓸지, 생성 파라미터(예: temperature, top-k 등)를 어떻게 설정할지도 중요한 결정사항입니다. 답변이 생성된 뒤에는 검토, 요약, 재구성, 품질평가 등 추가 작업을 수행하여 최종 결과를 만들어냅니다. 이 모든 과정을 **‘조율’**하고, 상황에 따라 최적의 방법을 적용하는 것이 RAG Orchestration입니다. 부엌에서 요리할 때 재료 준비 → 손질 → 조리 단계를 체계적으로 관리하는 셰프의 모습과도 비슷하다고 볼 수 있어요. RAG Grounding: ‘사실에 기반한’ 답변을 책임지는 방법 이번엔 RAG Grounding에 대해 알아볼게요. Grounding은 말 그대로 ‘답변이 실제로 뿌리를 내리고 있는가’를 확인하고, 그 근거를 명확히 제시하는 것을 뜻합니다. LLM이 아무리 똑똑해 보여도, 때로는 환각(hallucination)처럼 존재하지 않는 정보를 만들어내기도 하죠. 이럴 때 Grounding이 큰 역할을 합니다.

안녕하세요! 오늘은 MS Excel을 이용해서 가장 기본적인 RAG 파이프라인을 이해 할 수 있게 OpenAI의 GPT API를 활용하여 사용자 정의 함수를 만드는 과정을 공유하려고 합니다. 이 포스트에서는 GPTChat, GPTEmbedding, 그리고 벡터 검색을 위한 함수들을 만드는 방법을 단계별로 설명하겠습니다. 완성 파일 보기 및 다운로드 안녕하세요! 오늘은 MS Excel에서 OpenAI의 GPT API를 활용하여 사용자 정의 함수를 만드는 과정을 공유하려고 합니다. 특히 벡터 검색을 위한 TopKSimilarEmbeddings 함수를 만드는 방법을 상세히 다뤄보겠습니다. 목차 시작하기 전에 필요한 준비물 함수 1: GPTChat 함수 만들기 함수 2: GPTEmbedding 함수 만들기 함수 3: CosineSimilarity 함수 만들기 함수 4: TopKSimilarEmbeddings 함수 만들기 함수 사용 예시 주의 사항 마무리 시작하기 전에 OpenAI의 GPT API를 Excel에서 활용하면 다양한 자연어 처리 기능을 스프레드시트 내에서 직접 사용할 수 있습니다. 이를 통해 데이터 분석, 텍스트 생성, 임베딩 벡터 계산 등 다양한 작업을 자동화할 수 있습니다. 필요한 준비물 OpenAI API 키: OpenAI 계정에서 발급받을 수 있습니다.

사용한 논문 Strategic Chain-of-Thought: Guiding Accurate Reasoning in LLMs... AI 모델 Gemini 1.5 Pro와 Sonnet-3.5의 논문 요약 성능 비교 평가 (벨루가 요약 템플릿 사용) 이번 글에서는 해당 논문의 요약을 두 가지 AI 모델인 Gemini 1.5 Pro와 Sonnet-3.5를 통해 생성하고, 그 결과를 비교 평가해보았습니다. < 테스트 결과 요약 > Gemini 1.5 Pro 한글 요약 Gemini 1.5 Pro는 논문의 핵심 내용을 충실하게 반영하여 SCoT의 필요성, 작동 방식, 그리고 실험 결과까지 상세하게 설명하였습니다. 특히 SCoT의 두 단계 접근 방식인 전략 도출과 전략 적용에 대한 설명이 명확하며, 실험 결과에서 구체적인 수치(예: GSM8K 데이터 세트에서 21.05% 향상)를 제시하여 신뢰성을 높였습니다. 영어 요약 영어 요약에서도 논문의 주요 내용을 체계적으로 전달하였습니다. 문제점, 솔루션(SCoT의 도입), 핵심 특징, 실험 결과, 결론 순으로 논리를 전개하여 읽는 이로 하여금 내용을 쉽게 이해할 수 있도록 하였습니다. Sonnet-3.5 한글 요약 Sonnet-3.5의 한글 요약은 핵심 요약, 주요 특징, 방법론, 실험 결과, 결론으로 구성되어 있습니다. 전체적으로 중요한 포인트를 잘 짚어주고 있으나, 설명이 다소 간략하여 깊이 있는 이해를 위해서는 추가적인 정보가 필요할 수 있습니다. 영어 요약 영어 요약에서는 각 섹션별로 상세한 내용을 담아 개념의 정의, 방법론, 실험 결과, 분석, 장점, 한계점, 미래 연구 방향까지 폭넓게 다루었습니다. 이를 통해 논문의 내용을 깊이 있게 전달하고 있습니다. 비교 평가 내용의 정확성 및 포괄성 Gemini 1.5 Pro: 한글과 영어 모두에서 논문의 핵심 개념과 실험 결과를 정확하게 전달하고 있습니다. 특히 실험 결과에서 구체적인 수치를 제시하여 정보의 신뢰성을 높였습니다.

들어가며 최근 OpenAI 의 o1-preview 가 나오면서 Chain-of-Thought 에 대한 관심이 새롭게 증가하는 것 같습니다. 이미 벨루가에서는 서비스 초기(2023년 6월) 부터 RAG 기본 프롬프트를 수십번 바꿔가며, 보다 범용적인(누가 어떤 목적으로 사용할지 모르기 때문에) 프롬프트를 만들기를 시도했고 2023년 말 부터 프롬프트의 기본 구조와 템플릿 골격이 만들어 진것 같습니다. 지금은 이를 기반한 범용적인 프롬프트 적용하고 있지만 모든 모델에서 일관성을 가지게 하기 위해 정말 백번이상 수정을 한것 같습니다. o1이 나오면서 프롬프트 체이닝 방식으로 설계했던 것처럼 모델 자체가 추론 생성하는 과정을 보며 다시한번 CoT와 관련된 프롬프트를 검색하던 중 SCoT 라는 논문을 https://arxiv.org/abs/2409.03271 우연히 발견! 음.... 너무 우리꺼랑 너무 비슷한데 라고 느끼며, 글을 적어 보기로 합니다. (음 이런 류의 논문도 적을 수 있구나! 라고 혼자 한 10초는 멍하게 있었던 것 같네요). SCoT (Strategic Chain-of-Thought) 간단 소개 사실 이 기법은 프롬프트 엔지니어링이 복잡한 요청(수학)을 해결하는데 매우 좋은 해결책을 예시로 보여주고 있습니다. 그런데 구조적 부분을 살펴보면 응용할 수 있는 좋은 점들이 있습니다. 위 예시를 보면 Role 과 Workflow 그리고 룰 Initialization(재확인?: 초기화로 해석되는거지만 사실 한번더 짚어 주는 부분이 강하여 재확인으로 표현) 그리고 제공 되는 정보의 변수 영역이 있습니다. 이를 토대로 RAG Chatbot의 prompt template 에 살작 응용해 보겠습니다. (참고로 전 아무 근거 없이(근거는 전문가 분들이 만들어 주실꺼라) 경험치로 Zero-shot을 선호하여 Zero-shot 만 다루겠습니다. ) Zero-shot SCoT template # Role A highly skilled {mathematician and algorithm expert}. 설명: 역할을 사용자가 챗봇의 명칭을 이용하게 충분히 변수화 가능하겠죠? # Workflow Analyze the problem and identify any relevant mathematical formulas, or approaches that might be helpful, and select the approaches that can solve the problem.

우연히 Garnter의 연구를 보게 되었습니다. Source: Gartner Data & Analytics Summit Conference (2024), How to Make Your Data AI-Ready and Why It Matters. 여기서 전 현재 가장 많은 관심을 가지고 있는 생성형 AI 부분을 좀더 살펴보고 싶었습니다. 미디엄에 이를 잘 정리해 주신 분(Do Not Use LLM or Generative AI For These Use Cases)이 있는데요. 이를 토대로 다시 정리를 해보고자 합니다. 현재 우리에게 가장 많이 알려진 ChatGPT, Claude, Gemini, Midjourney, 등은 모두 생성형 AI 분야 입니다. 그리고 많은 분들이 이를 어떻게 활용할지 데이터는 어떻게 준비할 지 고민일 것입니다. 사실 생각보다 정말 내가 원하는 기술과 데이터는 꽤 손이 많이 가는게 현실인데 시행 착오도 많을 수 있어 방향을 확인하는데 도움이 될 것 같습니다. Gartner 연구에 따르면 AI 기술 적용 사례를 12가지로 나누고 있습니다. 예측/추정 가장 일반적인 사용 사례 중 하나입니다. 어떤 제품을 판매하고 있고 판매 데이터와 판매 활동과 관련될 수 있는 다른 기능들을 모두 수집했다고 가정해 보겠습니다. 그런 다음 머신러닝 알고리즘을 사용하여 향후 판매량을 예측할 수 있습니다. 자율 시스템 AI를 사용하여 우리를 위해 지능적으로 무언가를 수행하는 자율 시스템을 구축할 수도 있습니다. 한 가지 예로 AI 기술이 내장된 드론을 사용하여 송전선로의 일상적인 점검을 수행하는 것을 들 수 있습니다. 계획 때로는 상호 의존성과 제약이 많은 복잡한 시스템에서 작업해야 할 때가 있습니다. 계획 사용 사례는 이점을 극대화하고 영향을 최소화할 수 있는 최선의 계획을 찾는 것입니다. 예를 들어, 도시 지역의 교통 데이터를 분석하기 위해 AI를 사용할 수 있습니다. 그런 다음 도로 프로젝트를 진행 중인데 알고리즘이 일일 교통량에 미치는 영향을 최소화하기 위해 언제 어디서 작업해야 하는지 알려준다고 가정해 보겠습니다. 의사 결정 인텔리전스 이 유형의 사용 사례는 인사이트와 예측을 제공하여 의사 결정 프로세스를 개선하는 것을 목표로 합니다. 자율 시스템과의 차이점은 이 사용 사례군은 자동으로 의사 결정을 내리는 것이 아니라 사람이 의사 결정을 내릴 수 있도록 돕는다는 것입니다. 이는 일반적으로 특정 선호도나 기업가 정신을 고려해야 하는 결정이기 때문입니다. 추천 시스템 널리 적용되고 성숙한 사용 사례 유형입니다. 이 사용 사례는 사용자가 구매할 만한 제품이나 좋아할 만한 음악을 추천하는 것입니다. 세분화 / 분류 때때로 우리는 우리가 다루는 대상의 특성을 모를 때가 있습니다. 따라서 엔티티를 여러 범주나 수준으로 분류하여 인사이트를 얻을 수 있는지 확인하고자 합니다. 예를 들어, 대출 신청자의 속성에 따라 저위험, 중위험, 고위험으로 분류하기 위해 AI를 사용할 수 있습니다. 지능형 자동화 이 유형의 사용 사례는 AI와 자동화 기술을 결합하여 제조와 같은 일부 비즈니스 프로세스를 개선하는 것을 목표로 합니다. 최근 화두 중 하나인 '디지털 트윈'이 여기에 속합니다. 예를 들어, 제조 공장의 모든 센서 데이터로 모델을 학습시켜 며칠 전에 조업이 시작될 때 미리 경고를 보낼 수 있습니다. 인식 이 사용 사례 유형은 일반적으로 시각, 소리 및 기타 환경 데이터와 같은 감각 데이터에 의존하는 경우를 말합니다. 예를 들어, 도로에 설치된 카메라가 운전 위반 행위를 감지하는 것이 이 사용 사례 유형에 속합니다. 이상 징후 감지 때때로 프로세스가 잘못되었지만 우리가 인지하지 못하는 경우가 있습니다. 예를 들어, 전력망은 수백 개의 발전기로부터 에너지를 공급받을 수 있습니다. 그 중 하나가 다운되면 쉽게 알아차릴 수 있습니다. 하지만 그 중 10개가 동시에 변동한다면 알아차리기 어려울 것입니다. AI는 이러한 미묘한 이벤트를 감지하여 관제실에 알릴 수 있습니다. 대화형 사용자 인터페이스 이 사용 사례군은 최근 제너레이티브 AI 기술의 성장으로 인해 화제가 되고 있는 분야이기 때문에 친숙하게 느껴질 수 있습니다. 이 사용 사례 자체는 콜센터나 고객 지원 센터의 챗봇에 의해 잘 정의될 수 있습니다. 인공지능은 수많은 제품 문서를 사용하여 학습하고, 문제가 발생했을 때 고객의 질문에 답할 것입니다. 일반적으로 간단한 지원 티켓에 대해서는 사람의 개입이 필요하지 않습니다.

우리가 업무나 일상에서 작성하는 보고서에서 복잡한 구조의 표들은 많은 경우 AI에 그대로 이해되기 어렵습니다. 이런 경우 따로 엑셀이나 스프레드 시트 등에서 해당 내용을 AI가 이해할 수 있는 구조로 정리하여 학습 시키면 해당 정보를 정확하게 이해하여 답변하게 하실 수 있습니다. (가장 뛰어난 GPT4-o 모델의 경우도 표의 구조를 제대로 이해하지 못하고 캐롯 손보 등의 내용을 누락하여 잘못 작성하는 것을 볼 수 있습니다.) 그렇다면, 벨루가에 문서 학습을 잘 시키기 위해서는 어떻게 데이터를 정리해야할까요? 기존의 문서관리 글에서도 정리되어 있지만, 그동안 많이 받은 질문들을 토대로 FAQ를 정리해보았습니다!:) Q1: 데이터를 어떻게 구조화해야 하나요? PDF를 그대로 학습시키고 싶으실 경우, 글자 크기에 유의해주세요. 제목은 큰 글씨로 작성해야지 주제라는 것을 이해합니다. 빈 행과 열이 있어서는 안됩니다. 빈칸도 되도록 아님, 해당 없음 등으로 채워두시는게 좋습니다. 엑셀 파일에서 대분류에 너무 지엽적인 키워드가 들어가게 되면, 해당 표의 모든 내용에 관련 태그가 붙게 됩니다. 대분류에는 지나치게 상세한 키워드 대신 일반적인 키워드(예: 분류, 구분, 주제)를 사용하세요. 병합 된 셀이 있으면 이해하기 어렵습니다. 꼭! 병합된 셀은 풀어서 내용을 중복 입력하세요. 첫 번째 행은 반드시 대분류로 채우세요. 표의 구분/대분류가 변경될 경우 새로운 시트를 만드세요. Q2: 데이터 길이에 제한이 있나요? 내용이 많이 긴 pdf, docs 파일의 경우 시트에 청크 단위로 질문과 답변들의 정리가 필요합니다. len() 함수를 사용해 작성한 글자 수를 확인하실 수 있습니다. 시트에서 각 행이 2000자를 넘지 않도록 주의하세요. 긴 내용은 주제를 나누어 똑같은 태그로 나누어 입력하셔도 좋습니다. 시트 개수에는 제한이 없으므로 필요시 여러 시트를 만들어 사용하세요.

안녕하세요! 여러분:) 저번 주부터 벨루가에 합류하여 벨루가의 소식을 전해드리고 있는 스태프_벨루벨루입니다🐣 벨루가의 6/25 최신 업데이트 소식을 통해 카카오톡 채널 커머스카드 기능도 추가했다는 소식을 전해드렸습니다. 그리고 이번에 벨루가 자체 카카오톡 채널도 오픈하게 되어 벨루가 챗봇을 카카오톡에서도 써보실 수 있게 되고, 카카오톡 채널 소식을 통해 더 활발히 공유드릴 수 있게 되었습니다🎉🎉 💌벨루가 카카오톡 채널을 오픈했습니다!! 벨루가랑 친구하실 분~?🙋‍♂️🙋🙋‍♀️💞 벨루가 카카오톡 친구 추가를 해주시면, 앞으로 벨루가의 중요한 소식들과 이벤트들을 놓치지 않으실 수 있습니다🙌 👇아래의 링크를 눌러서 지금 바로 친구추가 해주세요🤗👇

최근 검색 증강 생성(RAG: Retrieval Augmented Generation)에 대한 관심이 급증하고 있습니다. 이 기술에 대한 기대와 함께 실망도 많습니다. 문서나 데이터를 나누는 방법에서부터 임베딩 방법, 그 외 전처리 및 후처리 등 다양한 방법이 문제 해결에 적용될 수 있습니다. 하지만 일반적인 RAG 기술을 적용할 때는 생각보다 만족스러운 결과를 얻지 못하는 경우가 많습니다. 이번 글에서는 벡터 데이터베이스와 그래프 데이터베이스의 차이를 예시를 통해 가볍게 설명해 보고자 합니다. 대규모 언어 모델(LLM)을 핵심 애플리케이션에 도입하려는 경우, LLM의 예측 불가능한 특성으로 인해 부정확한 추론이나 명백한 오류 같은 문제가 발생할 수 있습니다. 이는 정확성, 설명 가능성, 신뢰성을 중시하는 기업들에게 큰 문제로 다가옵니다. 이러한 문제를 극복하기 위해 검색 증강 생성이 주요 고려 사항이 됩니다. 지식 그래프와 벡터 데이터베이스는 검색 증강 생성을 구현하기 위한 잠재적인 솔루션으로 주목받고 있습니다. 그렇다면 LLM에 보다 정확하고 신뢰할 수 있으며 설명 가능한 기반을 제공하는 것은 무엇일까요? LLM 기반 구축을 위해 지식 그래프와 벡터 데이터베이스 중 하나를 선택할 때 고려해야 할 몇 가지 핵심 요소를 살펴보겠습니다. 복잡한 질문에 대한 답변 질문의 복잡성이 높을수록 벡터 데이터베이스가 빠르고 효율적으로 결과를 반환하기 어려워집니다. 쿼리에 더 많은 주제를 추가하면 데이터베이스가 원하는 정보를 찾기 힘들어집니다. 예를 들어, 지식 그래프와 벡터 데이터베이스 모두 "우리 회사의 CEO는 누구인가?"라는 질문에 쉽게 답변할 수 있지만, "지난 12개월 동안 최소 두 명의 구성원이 투표를 기권한 이사회 회의는 무엇인가?"와 같은 질문에는 지식 그래프가 벡터 데이터베이스보다 더 빠르게 답변할 수 있습니다. 벡터 데이터베이스는 벡터 공간 내 주제들의 유사성을 기반으로 답을 찾을 가능성이 높지만, 지식 그래프는 관계를 통해 정확한 정보를 찾아 반환합니다. 완전한 응답 얻기 벡터 데이터베이스는 유사성 점수 및 사전 정의된 결과 제한에 의존하기 때문에 답변을 반환할 때 불완전하거나 관련 없는 결과를 제공할 가능성이 있습니다. 예를 들어, "윤선도가 쓴 모든 책을 나열하시오"라는 질문에 벡터 데이터베이스는 다음과 같은 결과를 반환할 수 있습니다. 불완전한 제목 목록 (사전 정의된 제한이 너무 낮음): 예를 들어, 결과 제한이 3으로 설정되어 있고 윤선도가 쓴 책이 10권이라면, 벡터 데이터베이스는 3권의 책 제목만 반환하고 나머지 7권은 누락됩니다. 윤선도의 모든 제목과 다른 저자의 일부 제목 (사전 정의된 제한이 너무 높음): 반대로, 결과 제한이 20으로 설정되어 있고 윤선도가 쓴 책이 10권이라면, 벡터 데이터베이스는 윤선도의 모든 책 10권과 함께 다른 저자의 책 10권을 추가로 반환할 수 있습니다. 이는 사용자가 원하는 정보 외에 불필요한 정보까지 포함되어 검색 결과의 정확성을 떨어뜨립니다. 사용자 또는 개발자가 모든 가능한 쿼리에 대한 사전 정의된 제한을 알 수 없기 때문에 벡터 데이터베이스만으로 정확한 답변을 얻는 것은 쉽지 않습니다. 그래서 결과를 이용해 LLM에 보내어 다시 응답을 생성합니다. 반면, 그래프 데이터베이스를 사용한 지식 그래프는 엔티티가 관계에 의해 직접 연결되므로 각 엔티티마다 관계 수가 다릅니다. 지식 그래프는 정확한 답변만 검색하여 반환합니다. 이 경우 지식 그래프 쿼리는 윤선도가 쓴 모든 책만 반환하고 다른 것은 반환하지 않습니다. 다만, 그래프 데이터베이스의 단점은 초기 데이터베이스를 잘 구축해야 한다는 점입니다. 신뢰할 수 있는 응답 얻기 벡터 데이터베이스는 두 개의 사실 정보를 연결하여 부정확한 추론을 할 수 있습니다. 예를 들어, "제품 관리 팀에는 누가 있습니까?"라는 질문에 벡터 데이터베이스는 제품 팀이 생성한 문서(사실)에 대한 빈번한 댓글 액세스 권한(사실)이 있는 사람이 제품 팀에 속한다고 잘못 추론하여 결과에 이름을 반환할 수 있습니다. 그래프 데이터베이스로 구현한 지식 그래프는 노드와 관계를 사용하여 조직 내 사람들의 관계를 식별하기 때문에 제품 팀에 속한 사람만 반환합니다. 지식 그래프 쿼리는 연결된 정보의 흐름을 따라가므로 응답이 일관되게 정확하고 설명 가능합니다. 벡터 데이터베이스의 장단점 장점: 고차원 벡터 공간에서의 유사성 검색에 강점이 있습니다. 다양한 종류의 데이터를 빠르게 검색하고 분석할 수 있습니다.

최근 웹 애플리케이션에서 실시간 기능의 중요성이 점점 더 커지고 있는 것을 체감하고 있는 중에 벨루가도 SSE(Server-Sent Events) 을 적용하여 AI 답변을 제공하면 어떨까를 고민하며 프로젝트를 진행해보고 그 경험을 공유하고자 합니다. 지금도 벨루가는 스트리밍 방식으로 AI답변을 제공하고 있지만 단순 텍스트를 스트리밍하고 있는 구조로 되어 있어 클라이언트 개발자의 부담이 크며 유지보수 또한 쉽지 않은 구조로 이루어져 있습니다. 모든 메타데이터(출처, 답변생성 프로세스등..)를 답변과 함께 텍스트로 전달 되기 때문입니다. SSE(Server-Sent Events)란 무엇인가? SSE(Server-Sent Events) 는 서버가 클라이언트(웹 브라우저)에 정보를 푸시하는 방식입니다. 웹에서는 보통 클라이언트가 서버에 요청(request)을 보내고 서버가 응답(response)을 반환하는 구조인데, SSE는 이와 반대로 서버에서 초기 연결 후 계속해서 데이터를 클라이언트에게 보낼 수 있게 해줍니다. 이 기술은 특히 뉴스 피드, 실시간 알림, 또는 챗봇과 같은 애플리케이션에 매우 유용합니다. 이미지 출처: Exploring SSE (Server-Sent Events): Real-Time Updates for Your Applications! SSE의 선택 이유 WebSocket과 같은 다른 기술들도 고려했지만, SSE를 선택한 이유는 서버 설정이 간단하고, 양방향이 아닌 클라이언트와의 단방향 통신만 하면 되기 때문입니다. SSE는 HTTP를 사용하기 때문에 기존 웹 인프라와의 호환성도 뛰어나다는 장점이 있습니다. 구현 과정 API 서버 Python의 FastAPI 프레임워크를 사용하여 서버를 구축했습니다. 이 서버는 사용자로부터 질문을 받아 OpenAI의 GPT-3.5 모델에 전달하고, 생성된 응답을 실시간으로 사용자에게 스트리밍하는 역할을 합니다. 챗봇 서버 생성: FastAPI를 사용하여 웹 서버를 구축하고, CORS 설정을 통해 모든 출처에서의 접근을 허용했습니다. GPT-3.5 연동: 사용자의 입력을 받아 처리한 후, 생성된 텍스트를 실시간으로 스트리밍하기 위해 SSE를 구현했습니다. 스트리밍 로직: sse_generator 함수는 GPT 모델로부터 받은 데이터를 yield를 통해 클라이언트에 전송하고 await asyncio.sleep(0) 을 사용하여 이벤트 루프의 블로킹을 방지하고 다른 네트워크 태스크에 CPU 자원을 제공해서 클라이언트가 실시간으로 데이터를 받을 수 있도록 구현했습니다. 클라이언트 서버 웹 클라이언트는 React를 사용하여 구현했습니다. React를 선택한 이유는 특별한 이유가 있다기 보다는 벨루가 클라이언트가 React로 개발되어 있기 때문입니다. React는 동적인 UI를 구축하기에 적합하며, 컴포넌트 기반의 구조 덕분에 유지보수와 코드 관리가 용이하다는 장점이 있고 무엇보다 중요한건 Server-Sent Events(SSE) 를 활용하여 서버로부터의 스트리밍 데이터를 효과적으로 처리할 수 있다는 것입니다.

대화형 마케팅(Conversational Marketing, CM)은 고객과의 실시간 대화를 통해 관계를 구축하고, 고객의 요구를 즉시 파악하여 개인화된 경험을 제공하는 마케팅 접근 방식입니다. 이 전략은 전통적인 마케팅의 일방적인 커뮤니케이션을 벗어나, 고객과의 쌍방향 대화를 통해 신뢰와 충성도를 증진시키는 데 중점을 둡니다. 다음은 대화형 마케팅의 몇 가지 주요 특징과 예시를 포함하여 설명합니다. 대화형 AI나 AI 챗봇을 활용한 마케팅은 고객 서비스와 상호작용의 효율성을 높이는 동시에 개인화된 경험을 제공하여 고객 만족도를 크게 향상시킬 수 있습니다. AI 챗봇은 실시간으로 대화하면서 고객의 질문에 답하고, 필요한 정보를 제공하는 등 다양한 역할을 수행합니다. 여기에 AI 챗봇을 활용한 마케팅 전략에 대해 자세히 설명드리겠습니다. 1. 실시간 고객 지원 설명: AI 챗봇은 고객이 언제든지 원하는 정보를 즉시 얻을 수 있도록 도와줍니다. 이는 고객의 문의에 빠르게 응답하고, 만족도를 높이는 데 기여합니다. 예시: 웹사이트에 방문한 고객이 제품에 대해 궁금한 점을 챗봇에게 질문하고, 챗봇이 데이터베이스에서 즉시 관련 정보를 찾아 답변합니다. 2. 개인화된 추천 제공 설명: AI 챗봇은 고객의 이전 대화 내용, 구매 이력, 선호도를 분석하여 맞춤형 제안을 할 수 있습니다. 예시: 고객이 온라인 쇼핑몰에서 노트북을 검색할 때, 챗봇이 사용자의 구매 이력과 선호도를 분석하여 최적의 노트북을 추천합니다. 3. 구매 과정 최적화 설명: AI 챗봇은 고객의 구매 결정 과정을 돕고, 각 단계에서 필요한 정보를 제공하여 구매를 촉진합니다. 예시: 고객이 결제 과정에서 어려움을 겪을 때, 챗봇이 즉시 도움을 제공하며 결제 완료를 돕습니다. 4. 고객 참여 유도 설명: AI 챗봇은 대화를 통해 고객 참여를 유도하고, 이를 통해 고객의 의견을 수집하거나 피드백을 받습니다. 예시: 챗봇이 고객에게 최근 구매 제품에 대한 만족도 조사를 실시하고, 이를 바탕으로 서비스 개선에 활용합니다. 5. 장기적 관계 구축 설명: AI 챗봇은 정기적으로 고객에게 유용한 정보를 제공하고, 고객의 요구에 꾸준히 응답함으로써 신뢰 관계를 구축합니다. 예시: 챗봇이 고객의 생일이나 기념일에 맞춰 특별 할인 정보나 축하 메시지를 보내 관계를 강화합니다. AI 챗봇을 이용한 대화형 마케팅은 기업이 고객과의 지속적인 상호작용을 통해 더욱 신속하고 효과적으로 응대할 수 있게 도와줍니다. 이를 통해 고객 경험을 향상시키고, 브랜드 충성도를 높이는 데 크게 기여할 수 있습니다.

안녕하세요, 이번 글에서는 벨루가에서 최근 시작하게 된 추천 시스템 프로젝트에 대해 소개하려 합니다. 추천 시스템은 이제 우리 일상 속에 깊숙이 자리잡았습니다. 쇼핑몰에서 상품을 추천받기도 하고, 음악 스트리밍 서비스에서 새로운 아티스트를 발견하기도 하죠. 이런 추천 시스템은 크게 두 가지 상황에서 사용 될 수 있다고 보았습니다. 첫째는 사용자가 직접 추천을 요청하는 경우이고, 둘째는 사용자의 행동과 상황을 분석하여 자동으로 추천하는 경우입니다. 개인적으로는 후자에 더 관심이 있는데요, 사용자의 니즈를 예측하여 능동적으로 추천하는 시스템을 만들고 싶었습니다. 그리고 우리 벨루가에서 탬플릿화 또는 솔루션화 될 수 있게 설계를 하면 좋겠다고도 생각했습니다. 나아가 수많은 카페24, 고도몰, 네이버 스마트 스토어와 연결하여 사용할 수 있겠다는 생각도 해봅니다. 하지만 막상 프로젝트를 시작하려니 고민이 많이 됐습니다. 사용성을 이해하고 신용카드 관련 도메인 지식이 가지고 있는게 아니거든요. 이럴 때는 어떻게 해야 할까요? 저희는 데이터에서 힌트를 찾기로 했습니다. 데이터 확보가 용이한 것 부터 생각해보기로. 아니면 약간의 상상으로 데이터를 만들 수 있다면 최소한의 검증을 할 수 있다고 생각했죠. 그리고 당현히 벨루가 팀은 RAG(Retrieval-Augmented Generation)와 Graph DB를 활용하기로 했습니다. RAG는 정보 검색과 생성을 결합하여 정확한 답변을 만들어내는 강력한 도구입니다. 여기에 Graph DB를 결합하면 데이터 간의 복잡한 관계성을 더 잘 활용할 수 있죠. 물론 Graph DB를 사용하는 데는 비용과 성능 이슈가 있습니다. 그리고 GPT, Claude, Gemini, Llama 3, Cohere 등과 같은 언어 모델 API를 사용하는 것도 속도와 비용 면에서 부담이 될 수 있죠. 하지만 개인화된 추천의 가치를 생각한다면 이 정도 투자는 충분히 의미 있다고 생각했습니다. 그리고 앞으로 더욱더 개인화는 세계적인 흐름이 될 것이라 생각 하고 있습니다. 또 한 가지 고민은 Graph DB의 엔티티를 어떻게 구분할 것인가였습니다. 사람이 일일이 정의하는 것도 방법이지만, 언어 모델을 활용한 자동화도 생각해 볼 만합니다. 이를 통해 시스템의 효율성을 한층 높일 수 있을 것 같았죠. 벨루가팀은 이 프로젝트를 통해 신용카드 맛집 추천 시스템을 만들어 보려 합니다. 사용자의 위치 정보, 신용카드 정보, 맛집 정보 등을 종합하여 가장 혜택을 많이 받을 수 있는 맛집을 추천하는 거죠. 이를 통해 신용카드 사용률도 높이고, 사용자 경험도 개선할 수 있을 것이라 기대하고 있습니다. 사실 저 자신은 추천 시스템을 잘 활용하지 않는 편인데요, 그 이유는 추천이 제 취향과 잘 맞지 않기 때문이었습니다. 하지만 이번 프로젝트를 통해 진정으로 개인화된 추천 시스템을 만들어 본다면, 저 같은 사용자들의 만족도도 크게 향상시킬 수 있지 않을까요? 물론 이 여정이 순탄치만은 않을 것입니다. 주어진 시간은 3~4주 정도, 시행착오도 있을 테고, 예상치 못한 어려움도 만날 수 있죠. 하지만 그 과정에서 배우고 성장하는 것, 그것이 이 프로젝트의 가장 큰 의미라고 생각합니다. 작은 성공부터 하나씩 쌓아가다 보면, 분명 값진 결실을 맺을 수 있을 거예요. 프로젝트가 완성되는 그 날까지, 벨루가는 계속해서 도전하겠습니다. 이 블로그를 통해 그 여정을 여러분과 함께 나누고 싶네요. 앞으로의 이야기가 기대되시나요? 저도 마찬가지랍니다. 여러분도 각자의 분야에서 새로운 도전을 시작해 보시는 건 어떨까요? 언제나 여러분의 도전을 응원하겠습니다. 다음 글에서 다시 만나요, 감사합니다! 예상 되는 설계 방향

우리 서버 개발자분의 아이디어를 토대로 만든 맛집 추천 채널 벨루가에서 단답형 QnA 템플릿 사용 이유는 배고 픈데 대화할 시간이 없어서, 물으면 바로 답하게 하려고 제작 이유: 평소 벨루가 팀은 뭘 먹을지 참 어렵게 정해서 + 이미지 링클를 활용한 채팅 UI 노출 테스 뭔가 추천에 적절한 템플릿도 만들려고 양질의 데이터 보여주는 힘 요즘들어 더욱 느끼지만 양질의 데이터가 얼마나 중요한지 되세기에 적절한 케이스 여기 사용된 데이터는 크롤링으로 꽤 많은 양과 (개략 몇천개는 되는듯) 정형화 된 데이터를 수 너무 많아서 데이터 올리는데만 30분은 넘게 쓴것 같음 데이터 전체 약 38만 곳 데이터 구조 주소 | 장소 | 카테고리 |이미지 | 키워드 | 이름 |연략처 | 추천 | 리뷰 | 점수 | 리뷰내용