지난번 Claude Skill 에 대한 글을 적고나서, 문득 의문이 들어서 이번에 어떤 상황에 현재 나오는 다양한 방법들(플러그인, 훅, 스킬, /명령, MCP, 서브에이전트 등)을 선택할지에 대한 고민이 되었습니다. 좀 개인적인 해석일 수 있지만 나름 정리를 해 봅니다. 에이전트 스킬(Agent Skills)이란? 에이전트 스킬은 단순한 단일 기능이 아니라, 반복되는 워크플로우에 대해 에이전트가 자율적으로 적용할 수 있도록 "도메인 특화 전문 지식(domain-specific expertise)"을 패키징하는 기능정도로 해석 할 수 있습니다. 그럼 MCP는? 이라고 바로 머리속에 스쳐지나갔지만 이전 글에 언급했듯이 결국 외부 연동은 MCP이고 좀도 맞춤형, 반복적인건 스킬을 사용하자로 이해 했습니다. 그런데 MCP만 있는게 아니고 "/명령"나 서브에이전트도 있고 한데 스킬이 이들을 대체하기 보다는 뭔가 구성을 해서 원하는 지침에 맞게 적용이 되게 하는 수단으로 적합하지 않을까 생각해 봤습니다. 이러면, 훨씬더 유용한 접근이겠구나 즉, 다른것들을 조합하는 더 높은 수준의 구성 계층(compositional level)이라는 점 정도로 정리를 해봅니다. 조금더 개인적인 생각으로 사용 사례를 적어보면, 잘못된 사용 예: Git 워크 트리를 '생성'하는 단일 작업을 스킬, 서브 에이전트, 슬래시 커맨드로 각각 만드는 것. (어떤 것을 써야 할지 혼란만 줌) 올바른 사용 예: Git 워크 트리를 '생성', '삭제', '목록 조회'하는 등 관련 작업 묶음(문제 세트)을 하나의 'Git 워크 트리 관리자' 스킬로 만들어, 에이전트가 상황에 맞게 자율적으로 호출하게 하는 것. 그래도 다른 것들과 비교하면? 기능 (Feature) 트리거 (Trigger) 컨텍스트 효율성 (Context Efficiency) 컨텍스트 유지 (Persistence) 모듈성 (Modularity) Agent Skills 에이전트 자율 호출 높음 (점진적 공개). (MCP처럼 전부 로드하는게 아니라, 메타데이터 skill.md 지침 리소스 순으로 필요할 때만 컨텍스트를 점진적으로 사용) (점진적 공개). (MCP처럼 전부 로드하는게 아니라, 메타데이터 skill.md 지침 리소스 순으로 필요할 때만 컨텍스트를 점진적으로 사용) 유지됨 높음 (전용 디렉토리 구조)

Anthropic의 새로운 업데이트가 눈낄을 끌어 좀 자세히 살펴 보았습니다. 간단히 요약하면: 반복적인 사용성을 대응하기위한 꽤 강력한 업데이트! 라고 이야기 할 수 있을 것 같습니다. MCP 가 외부 애플리케이션쪽이라면 Claude Skill 은 "보고서 양식은 이걸로 해주고, 우리 회사 로고 꼭 넣어주고, 글씨체는 이걸로..." 매번 같은 지시를 내리는 것은 번거롭고, 결과물도 미묘하게 달라져 답답함" 을 좀 해결 할 수 있는 도구로 제시 되고 있습니다. 전체 구성을 보면, 공식 문서에서 잘 매우 잘 설명하고 있습니다. Https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills 뭔가 어렵게 보이지만 Claude skill의 경우 SKILL.md 핵심 지시 다루는 가장 중요한 파일과 resources/ : 일종의 참고 자료실 역할 scripts/ 라는 계산이나 코드 처리를 저장하는 구성으로 되어 있습니다. 어떻게 사용자에게 위 3가지를 이용하여 맞춤으로 답변하는지는를 좀 다시 표현하면, 같은 흐름을 보여줍니다. 개인적으로 Anthropic에서 사용자이 평소 자주 겪는 AI 활용을 위한 문제들을 해결하기 위해, 똑똑한 접근방식을 구현했다고 생각이 됩니다. 직접 Skill Generator로 기존 Claude 직접 만들수도 있게 되어 있는 부분도 인상적입니다.

Spec Kit과 Claude Code로 근태관리 시스템 구축하기 AI 시대에 가장 뜨거운 격전지는 단연 AI 코딩 분야입니다. Cursor, GitHub Copilot, Claude Code 등 수많은 도구들이 쏟아지며 개발자들의 업무 방식을 근본적으로 바꾸고 있습니다. 그동안 이런 도구들을 미뤄왔던 저는 이번 연휴를 활용해 본격적으로 AI 코딩의 세계에 뛰어들어 보기로 했습니다. 시작: GitHub Spec Kit과의 만남 여러 도구를 살펴보던 중 GitHub에서 공개한 Spec Kit이 눈에 들어왔습니다. 공식 문서를 읽어보니 이 도구의 핵심 아이디어는 명확했습니다. AI가 코딩할 때 필요한 컨텍스트를 체계적으로 작성하고 관리하는 것, 즉 'Spec-Driven Development'를 지원하는 프레임워크였습니다. Spec Kit의 작동 방식은 다섯 가지 핵심 명령어로 구성됩니다. 먼저 /constitution은 개발의 헌법이라 할 수 있는 가이드라인과 정책을 정의합니다. 프롬프트 엔지니어링으로 비유하자면 시스템 프롬프트와 같은 역할입니다. 다음으로 /specify는 사용자 스토리와 제품 요구사항을 입력하는 단계입니다. /plan에서는 기술 스택과 아키텍처를 정의하고, /tasks로 구체적인 할 일 목록을 생성합니다. 마지막으로 /implement가 실제 코딩을 실행하는 명령어입니다. 준비: 개발 환경 구축 VS Code를 열고 Spec Kit을 설치하면서 동시에 오랜만에 Node.js도 다시 설치했습니다. 무엇을 만들지 고민하다가 회사에서 실제로 사용할 수 있는 근태 및 휴가 관리 웹 앱을 Flutter로 개발하기로 결정했습니다. 기술 스택은 4~5년 전 Firebase를 사용해본 경험은 있지만 이번에는 Supabase를 선택했고, 최근 출시된 Claude Code 2.0도 함께 활용해보기로 했습니다. GitHub Copilot도 보조 도구로 옆에 띄워두었습니다. 실전: Constitution부터 Implementation까지 첫 단계인 /constitution 작성부터 막막했습니다. 무엇을 어떻게 적어야 할지 감이 잡히지 않아 ChatGPT에게 Spec Kit 링크와 제가 사용할 스택, 만들려는 기능을 설명하고 도움을 받았습니다. "Use Dart best practices", "Follow Flutter material design guidelines" 같은 Do와 Don't 항목들로 구성된 constitution을 완성할 수 있었습니다. 다음은 /specify 단계였습니다. 제가 생각하는 근태 및 휴가 관리 시스템의 요구사항을 입력했습니다. 여기서 인상 깊었던 점은 Spec Kit이 자동으로 /research를 실행하며 필요한 정보를 조사하고 계획을 수립하는 과정이었습니다. 시스템이 모호한 부분에 대해 clarify를 요청하면서 정책에 대한 명확화를 요구했고, 제가 답변을 제공하자 마일스톤과 태스크들이 체계적으로 생성되었습니다. 마치 바이브 코딩에서 강조하는 PRD(Product Requirements Document)가 자동으로 만들어지는 느낌이었습니다. 개발 과정: 순탄함과 도전 재미를 붙이고 집중하기 시작했습니다. Claude Code를 실행하고 생성된 태스크 목록을 살펴보니 Supabase 계정 생성, API 키 발급, 환경 설정 등 사전 작업이 필요했습니다. 이 부분에서 상당한 시간이 소요되었지만, 막히는 부분은 GitHub Copilot에게 물어가며 하나씩 해결해 나갔습니다. 환경 설정을 마치고 Claude Code에 /tasks milestone 2를 지시하자 본격적인 코딩이 시작되었습니다. 처음에는 최소 배포 버전(MVP)을 목표로 하고 관찰 위주로 진행했습니다. 로컬 환경에서 배포가 가능한지 확인하고 실행해봤는데, 놀랍게도 바로 작동했습니다. 더 나아가기 전에 GitHub 리포지토리를 생성하고 브랜치 전략을 세워 GitHub Actions와 GitHub Pages까지 설정하도록 지시했습니다. 제가 직접 설정하지 못한 일부 부분을 제외하고는 모든 과정이 부드럽게 진행되었습니다. 데이터베이스 연결, 비즈니스 로직 구현, 그리고 인증 시스템까지 예상보다 훨씬 빠르게 완성되어 가는 모습에 점점 더 흥미가 생겼습니다. 한계와 배움 하지만 개발을 진행할수록 Spec Kit이 자동으로 생성한 태스크 목록의 한계도 드러나기 시작했습니다. 특히 작지만 사용자 경험에 중요한 디테일한 요소들이 누락되는 경우가 많았습니다. 완성도를 높이기 위해서는 Spec Kit의 자동 태스크 생성에 의존하기보다는, 비즈니스 로직을 구체적으로 설명하고 계산 방식과 프로세스를 상세히 기술해야 했습니다. 언어 설정(한글/영문), 데이터 검증 규칙, 예외 처리 같은 부분들은 수동으로 명확히 지정해줘야 했고, 후반부로 갈수록 더 많은 시간을 프롬프트 작성에 투자하게 되었습니다.

최근 "에이전트" 라는 단어가 매우 자주 사용되는데요. 프롬프트 엔지니어링 처럼 다양한 패턴들이 있고, 복잡하고 동적인 실제 사용을 위해서는 하나의 에이전트만으로는 부족한 경우가 많습니다. 그래서, 여러 에이전트와 도구를 효과적으로 조합하고 조율하는 "설계"가 필요하고 여기에는 일종에 패턴들이 있어 소개합니다. 이 글에서는 자주사용될 법한 에이전트 패턴을 살펴보고, 각 패턴의 작동 방식을 간단한 ASCII 흐름도로 표현해 보았습니다. . 1 도구 사용 패턴 (Tool Use Pattern) LLM의 내장된 지식만으로는 해결할 수 없는 작업을 위해 외부 API나 데이터베이스, 코드 실행기 등의 '도구'를 호출하여 사용합니다. 이를 통해 실시간 정보 검색, 복잡한 계산 등이 가능해지며 에이전트의 능력을 확장하는 가장 기본적인 패턴입니다. 2 검색 증강 생성 (RAG) 패턴 (Retrieval-Augmented Generation Pattern) LLM이 답변을 생성하기 전에, 먼저 외부 지식 베이스(예: 벡터 DB)에서 질문과 관련된 최신 정보를 검색하고, 이 정보를 참고하여 더 정확하고 신뢰성 높은 답변을 생성합니다. 환각(Hallucination) 현상을 줄이는 데 매우 효과적입니다. 3 ReAct 패턴 (Reason and Act Pattern) '추론(Reason)'과 '행동(Act)'을 결합한 패턴입니다. 에이전트는 다음 행동을 결정하기 위해 먼저 상황을 추론하고, 그에 따라 도구를 사용하거나 응답을 생성하는 행동을 취합니다. 이 과정을 반복하며 목표에 도달하는 강력한 패턴입니다. 4 라우터 패턴 (Router Pattern) 사용자의 요청이나 주어진 작업의 성격을 파악하여 가장 적합한 에이전트나 도구로 작업을 동적으로 전달합니다. 마치 교통경찰처럼 작업의 흐름을 제어하는 역할을 합니다. 5 계획 및 실행 패턴 (Plan-and-Execute Pattern) 복잡한 목표를 달성하기 위해 먼저 전체적인 계획을 세우고, 그 계획에 따라 하위 작업들을 순차적 또는 병렬적으로 실행하는 에이전트에게 위임합니다.

간단하게 적용 가능한 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에 보내어 다시 응답을 생성합니다. 반면, 그래프 데이터베이스를 사용한 지식 그래프는 엔티티가 관계에 의해 직접 연결되므로 각 엔티티마다 관계 수가 다릅니다. 지식 그래프는 정확한 답변만 검색하여 반환합니다. 이 경우 지식 그래프 쿼리는 윤선도가 쓴 모든 책만 반환하고 다른 것은 반환하지 않습니다. 다만, 그래프 데이터베이스의 단점은 초기 데이터베이스를 잘 구축해야 한다는 점입니다. 신뢰할 수 있는 응답 얻기 벡터 데이터베이스는 두 개의 사실 정보를 연결하여 부정확한 추론을 할 수 있습니다. 예를 들어, "제품 관리 팀에는 누가 있습니까?"라는 질문에 벡터 데이터베이스는 제품 팀이 생성한 문서(사실)에 대한 빈번한 댓글 액세스 권한(사실)이 있는 사람이 제품 팀에 속한다고 잘못 추론하여 결과에 이름을 반환할 수 있습니다. 그래프 데이터베이스로 구현한 지식 그래프는 노드와 관계를 사용하여 조직 내 사람들의 관계를 식별하기 때문에 제품 팀에 속한 사람만 반환합니다. 지식 그래프 쿼리는 연결된 정보의 흐름을 따라가므로 응답이 일관되게 정확하고 설명 가능합니다. 벡터 데이터베이스의 장단점 장점: 고차원 벡터 공간에서의 유사성 검색에 강점이 있습니다. 다양한 종류의 데이터를 빠르게 검색하고 분석할 수 있습니다.