우연히 흥미로운 영상을 보게 되었습니다. 해당 영상에서는 2개의 논문을 토대로 실험을 하는데 상당히 설득력이 있어 정리해 보았습니다. 저도 어떻게 하면 md 파일을 잘 활용할지 꽤 고민 중인데 영상과 논문을 보고 "이거 뭐 점점 더 어려워지네" 라는 생각이 들었습니다. 결과적으로는 도움이 되는 가이드라인을 제시해 주어서 인상 깊었습니다. 당신의 CLAUDE.md와 AGENT.md를 당장 삭제해야 하는 이유 🗑️ (최신 AI 연구 결과) 최근 AI 개발자들 사이에서 Cursor rules, AGENT.md, CLAUDE.md 같은 프로젝트 컨텍스트(Context) 파일을 길고 꼼꼼하게 작성하는 것이 일종의 '필수 작업'처럼 여겨지고 있습니다. 프로젝트 구조, 사용 스택, 코딩 컨벤션 등을 에이전트에게 미리 알려주면 더 코딩을 잘할 것이라는 믿음 때문이죠. 하지만 유명 개발 유튜버 Theo(t3.gg)는 최근 영상에서 "당신의 CLAUDE.md를 당장 지워라"라고 강력하게 조언합니다. 그의 파격적인 주장은 단순한 느낌이 아니라, 최근 발표된 두 편의 흥미로운 AI 연구 논문에 의해 명확히 뒷받침됩니다. 과연 우리는 AI에게 너무 많은 것을 알려주려다 오히려 AI를 망치고 있는 것은 아닐까요? 📉 연구 1: AGENT.md는 정말 도움이 될까? (arXiv:2602.11988) 첫 번째 논문 "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?"의 결과는 꽤 충격적입니다. 연구진이 SWE-bench 등 실제 GitHub 이슈 해결 환경에서 코딩 에이전트를 테스트한 결과, 컨텍스트 파일은 에이전트의 성공률을 오히려 떨어뜨리는 경향이 있었습니다. LLM이 자동 생성한 컨텍스트 파일: 성공률 하락 및 추론 비용(Cost) 20% 이상 증가. 개발자가 직접 작성한 파일: 성공률 향상이 4% 내외로 매우 미미함. 왜 이런 일이 발생할까요? AI 에이전트에게 불필요하게 많은 지시사항이 주어지면, 에이전트는 과도하게 탐색(Exploration)하고 불필요한 테스트를 진행하며 '오버씽킹(Overthinking)'을 하게 됩니다. Theo 역시 영상에서 이를 증명합니다. 아무 컨텍스트 파일 없이 에이전트에게 질문했을 때 1분 11초가 걸렸지만, 초기화(init)된 CLAUDE.md 파일이 있을 때는 오히려 1분 29초로 작업 속도가 느려졌고 토큰 사용량(비용)만 20%가량 증가했습니다. 심지어 문서가 업데이트되지 않아 과거의 아키텍처를 가리키고 있다면, 에이전트는 끊임없이 잘못된 방향으로 삽질을 하게 됩니다. 💡 연구 2: 그렇다면 무엇을 알려줘야 하는가? (arXiv:2602.12670) 그렇다면 AI에게 아무런 가이드도 주지 말아야 할까요? 두 번째 논문 "SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks"는 이에 대한 해답을 줍니다. 이 논문은 단순한 레포지토리 구조 요약이 아니라, 특정 작업을 수행하기 위한 절차적 지식(Procedural knowledge)인 '스킬(Skills)'의 효과를 측정했습니다. 결과는 놀라웠습니다. 인간이 직접 큐레이션한 핵심 '스킬' 문서를 제공했을 때 에이전트의 문제 해결 성공률은 평균 16.2%p나 크게 향상되었습니다. (24.3% 40.6%) 심지어 적절한 스킬을 부여받은 작은 모델이, 스킬이 없는 거대 모델을 압도하는 결과도 보여주었습니다. 하지만 여기에도 중요한 조건이 있습니다. 스스로 만들게 하지 마라: LLM에게 스스로 스킬을 생성하라고(Self-generated) 지시한 경우, 성능 향상은커녕 성공률이 평균 1.3%p 하락했습니다. 다다익선이 아니다 (Less is More): 23개의 핵심적이고 간결한 스킬을 제공했을 때 가장 효과적이었습니다. 방대하고 포괄적인 문서(Comprehensive docs)는 에이전트의 인지 과부하를 일으켜 오히려 성능을 떨어뜨렸습니다.

Anthropic 의 새로운 글을 읽고 간단히 정리해 봅니다. https://lnkd.in/gc5REJWW 과거 Prompt Chaining 때와 비슷하게 결국 작게 시작해서 빌드업 하는 방식인 부분이 크게 공감이 됩니다. 핵심은 단순히 "복잡한 에이전트를 만드는 것"이 아니라, "실제로 작동하고 검증 가능한 시스템을 구축하는 것"에 초점이 맞춰져 있습니다. 단순함에서 시작하라 (Keep it Simple) 처음부터 수많은 도구와 복잡한 워크플로우를 가진 에이전트를 만들지 마세요. 단순한 프롬프트나 단일 단계의 워크플로우로 시작해 성능이 확실히 개선될 때만 복잡성을 추가해야 합니다. 저희 내부에서도 항상 강조하는 부분인데 한번에 다 만들려고 하면 시간이 더 걸립니다. 설계가 단순할수록 에이전트가 왜 실패했는지 파악하기 쉽고 디버깅이 용이합니다. 장문의 프롬프트를 작성해 보았다면 아마 앞뒤 모순으로 어디서 문제가 발생했는지 파악하기 어려워 많은 시간을 소모한 경험이 있었을 겁니다. '경로'가 아닌 '결과'를 평가하라 (Evaluate Results, Not Paths) 에이전트가 문제를 해결하기 위해 어떤 과정을 거쳤는지(사고 과정)보다, 최종적으로 올바른 결과(코드 패스, 파일 수정 등)를 냈는지를 우선적으로 평가해야 합니다. 일부 동의 하지 않는 분들도 있겠지만 최적화는 일단 원하는 결과 후에 다듬는게 개인적으로 훨씬 효과적이었습니다. 글에서는 에이전트가 사람이 예상하지 못한 독창적인 방식으로 정답에 도달할 수 있기 때문이라고 설명하지만, 꼭 그렇지 않더라도 최근 reasoning 모델도 사용하는 경우 과정을 강제하면 오히려 성능이 저하될 수 있습니다. 실제 실패 사례에서 시작하라 (Start with Real Failures) 이거 좀 중요하다고 생각합니다. 임의의 성공 사례보다 실제 실패했던 20~30개의 구체적인 사례를 수집하여 평가 데이터셋(Evals) 또는 분석을 토대로 수정하는것을 항상 권장합니다. 결국 작은 데이터셋으로 시작해 에이전트의 동작을 하나씩 교정해 나가는 것이 수백 개의 모호한 테스트보다 훨씬 효과적입니다. 도구 설계의 중요성 (ACI: Agent-Computer Interface) 에이전트가 사용하는 도구(API 등)의 이름과 설명을 매우 명확하게 작성해야 합니다. 마치 주니어 개발자에게 업무 지시를 내리는 것처럼 상세해야 합니다. 기본으로 제공되는 description 이나 명칭으로는 안되는 경우가 꽤 발생합니다. 예를들면, 인터넷 검색도 현재 에이전트의 도메인 정보도 제공하여 어떤 인터넷 검색인지를 명시하는 등의... 그리고 항상 잘못된 인자를 넣거나 실수하기 어렵도록 도구의 입출력 구조를 단순화하고 제약 사항을 두어야 합니다. 일관성 확보에도 이 부분이 꽤 중요합니다. 투명성 확보 (Make Reasoning Visible) 설계시에도 어떤 계획을 세우고 어떤 도구를 선택했는지 어떤 결과를 만드는지 초기부터 꼼꼼히 확인하면서 현재 에이전트를 이해하며 구현하시기 발바니다. 이는 신뢰도를 높일 뿐만 아니라, 에이전트가 '환각(Hallucination)'에 빠지는 지점을 정확히 짚어낼 수 있게 합니다.

<RAG용 웹 데이터 수집 검증 툴 공유> RAG를 하다 보면 웹사이트 구조(정적/동적), 태그 오류 등으로 인해 데이터가 제대로 임베딩되지 않아 엉뚱한 답변이 나가는 경우가 잦습니다. 가장 쉬운 접근법이지만, 동시에 가장 많은 변수가 숨어있는 곳입니다. ❌ 닫히지 않은 HTML 태그들 ❌ 난해한 동적(Dynamic) 렌더링 구조 ❌ 의미 없는 내비게이션/푸터 데이터 혼입 이런 노이즈들이 섞이면, 임베딩 벡터가 오염되고 결과적으로 챗봇이 엉뚱한 답변을 하게 됩니다. (Garbage In, Garbage Out의 전형적인 예시죠.) 무턱대고 임베딩하기 전에, "실제로 읽어들일 데이터 형태"를 미리 확인할 수 있는 간단한 툴을 만들어 깃허브에 올렸습니다. 웹 구조 때문에 RAG 성능 저하를 겪어보신 분들께 도움이 되었으면 합니다. 🔗 vcrawl 깃허브 바로가기 자주 추가로 Html Validator tool 도 공유합니다. 기본적인 이슈 체크에 유용해서.. https://validator.w3.org/

벨루가 팀이 지난 월(11/3) Veluga-SKT-Claude-Code-Hackathon에 참가하게 되었습니다. 처음 참가하는 헤카톤과 팀으로써도 처음 참가하여 쟁쟁한 팀들과 3시간 내에 Anthropic의 MCP 를 만드는 주제를 다루었습니다. 생각보다 매우 촉박했으나 30초를 마지막 데모영상과 피칭을 준비하는 시간이 계획데로는 작성이 안되어 입상은 하지 못했지만, 훌륭한 경험이자 상당히 즐거운 시간이었습니다. 저희는 Chat2Entity 라는 mcp 를 통해 비정형 및 대화 텍스트를 액션 아이템을 도출할 수 있게 도메인 특화된 추출 Entity 팩을 이라는 개념을 접목하여 심플하지만 유연하고 확장 가능한 도구라 만들었고, 다음은 데모 영상과 특징입니다. 좀 더 다듬어서 다른 분들도 쉽게 사용 가능하게 오픈소스화 예정입니다. 추가로 좋은 행사 주최한 SKT, Anthropic, Coxwave 측에 감사드립니다. Chat2Entity MCP Veluga-SKT-Claude-Code-Hackathon 본선 결과물 Chat2Entity는 Anthropic MCP를 기반으로 대화 데이터를 자동으로 구조화된 엔티티로 변환하는 오픈소스 서버입니다. Entity Pack(YAML 스키마)을 통해 코드 수정 없이 신규 도메인 적용이 가능하며, CRM·Jira 등 다양한 시스템과 즉시 연동됩니다. 🎥 Demo Video: https://lnkd.in/dESJhqFv 핵심 특징 대화 텍스트를 즉시 JSON 기반 엔티티로 변환 근거 문장 및 신뢰도 점수 포함한 검증 체계 Entity Pack 확장으로 신규 도메인 1일 내 추가 Claude 기반 구조화 출력으로 필드 누락 0% 효과 고객상담 자동화로 처리 시간 60% 단축 영업 미팅 인사이트 추출로 생산성 40% 향상

지난번 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.