본문 바로가기

AI32

7-1. [프리뷰]: 설계가 코드를 만날 때 6주차까지 쓴 문장들은 전부 선언이었다. 그런데 코드를 한 줄 쓰기 전에 먼저 해야 할 일이 있다. 이번 주에 무슨 일이 일어나는지를 정확히 이해하는 것이다. "trend_scanner는 항상 가장 먼저 호출된다", "루프백 3회 초과 시 탈출한다", "메타데이터에 used_tools가 반드시 포함된다." 이것들은 아직 증명되지 않은 명제다. 7주차는 그 명제들이 코드 위에서 실제로 참인지 확인하는 주다. 선언에서 검증으로. 이 전환이 7주차의 핵심이다. 에이전트 구조를 읽는 세 개의 레이어 구현에 들어가기 전에 프레임워크를 한 번 더 짚고 가는 것이 유익하다. 에이전트 시스템을 설계하고 구현할 때 발생하는 혼란 대부분은 이 세 레이어를 구분하지 않아서 생긴다.Tool / Capability .. 2026. 5. 15.
6-4. [리뷰]: 설계의 중요성을 다시 한번 짚었다 6주차가 끝나는 시점에 설계서를 쓰고, 피드백을 받고, 고쳤다. 이번 글에서는 내가 무엇을 놓쳤고 무엇을 맞게 짚었는지 확인해본다. 6주차는 코드를 한 줄도 쓰지 않은 주였다. 1주차부터 5주차까지는 "어떻게 만드는가"를 배웠다. 6주차는 처음으로 "무엇을 왜 만드는가"를 먼저 결정하도록 요구받았다. 그 순서의 전환이 이번 주의 핵심이었다. "경로를 미리 그릴 수 있으면 Workflow, 그릴 수 없으면 Agent." 강의 전반을 관통한 메시지는 설계서를 쓰면서 스스로 도달했다고 생각한 것과 정확히 일치했다. 이 한 문장이 6주차 설계의 분기점이었다. OpenAI의 에이전트 가이드 서두도, Anthropic의 에이전트 설계 원칙도, 모두 이 질문에서 시작한다. 어떤 문서를 읽든 가장 앞에 나오는 경.. 2026. 5. 15.
6-3. AI Agent 설계 피드백: Agent는 예외 처리기다 피드백의 핵심을 한 문장으로 압축하면.. 멘토님의 피드백은 세 가지였다. 그러나 그 세 가지는 결국 하나의 원칙으로 수렴된다. "Agent 구간과 고정 Workflow 구간을 나눠두면 설계가 더 선명해질 것 같습니다." 이 한 문장이 이번 설계 수정의 전부였다. 나머지 두 피드백(데이터 출처 명확화, 성공 판정 기준의 케이스화)도 따지고 보면 이 원칙의 파생이다. 경계가 불분명한 시스템은 어디서 무슨 일이 일어나는지 추적하기 어렵고, 추적하기 어려운 시스템은 검증할 수 없다. 피드백 1: Workflow와 Agent의 경계는 설계의 기초다 원본 설계가 놓친 것초안 설계서 전체를 "ReAct 에이전트"로 묶어놨는데, 정작 대부분의 실행은 순서가 고정되어 있었다. trend_scanner를 먼저 실.. 2026. 5. 15.
6-2. AI Agent 설계: 자율성은 어디에 배치해야 하는가? 5주차 회고에 이런 한계가 존재했다. "메타데이터 필터링으로 올해 문서를 찾아냈는데, 청크 상단에 작년 소제목이 박혀 있어서 LLM이 답변을 포기했다. Faithfulness 0.0. 프롬프트로는 고칠 수 없었다." 이 한계는 단순하다. RAG는 검색의 품질을 최대화하는 구조이다. 하지만 검색이 아무리 정밀해도, 시스템이 실행 중에 스스로 다음 행동을 바꿀 수 없다면 즉, 런타임 판단 능력이 없다면 특정 종류의 문제는 구조적으로 풀리지 않게 된다. 이번 AI Agent는 해당 질문과 같은 점에서 시작할 수 있다. 에이전트는 무엇이고, 언제 써야 하며, 어떻게 설계해야 하는가? 설계의 첫 분기점: Workflow인가, Agent인가 에이전트를 설계하기 전에 반드시 통과해야 하는 지점이 하나 있다.. 2026. 5. 7.
6-1. [프리뷰]: AI 에이전트의 정의와 패러다임의 변화 지난 주차까지 우리는 '데이터'를 어떻게 정확하게 찾아서 전달할 것인지에 집중했다. 하지만 실무에서는 단순히 정보를 찾는 것만으로는 해결되지 않는 복잡한 과업이 산재해 있다. 6주차의 핵심 주제인 AI 에이전트는 이러한 한계를 극복하고 AI가 직접 행동을 취하는 능동적인 시스템을 지향하는 것이다. 1. AI 에이전트란 무엇인가? AI 에이전트는 단순히 똑똑한 챗봇이 아니다. 에이전트를 정의하는 핵심 키워드로 사용자 요청(User Request), 언어 모델(LM), 그리고 자율적 행동(Autonomous Action)의 결합을 꼽는다. 기존의 소프트웨어가 개발자가 미리 정해놓은 경로(Execution Path)를 따라 정적으로 움직였다면, AI 에이전트는 런타임(Runtime)에 언어 모델이 스스.. 2026. 5. 4.
5-6. [리뷰]: 차별점은 검증하고 설명하는 능력 골든 데이터셋의 본질 지난 5주 차 실습을 통해 우리는 RAG 시스템이 단순히 '문서를 검색하고 답변을 생성하는' 파이프라인을 넘어, 각 단계별로 치밀한 측정과 통제가 필요한 복합 시스템임을 확인했다. 우리가 직면했던 이러한 기술적 허들들이 실무 현장에서도 동일하게 겪고 있는 가장 핵심적인 화두임을 짚는다. 1. "PoC 비용은 폭락했고, 검증 비용은 폭등했다" 생성형 AI 모델들의 발전 속도는 경이로운 수준이다. 최근 화제가 된 DeepSeek 모델을 알아보자. 프론티어 모델급 성능을 보이며 특히 코드 분야에서 압도적인 효율을 자랑하지만, 약 840GB에 달하는 가중치를 자체 서버에 띄우기 위해서는 서버 인프라 구축에만 약 10억 원, 월 운영 비용으로 1억 원 가까이 소요된다는 현실적인 한계가 존.. 2026. 5. 3.
5-5. [심화] RAG 평가: Custom Metric 만들기 (YearAccuracy) 우리는 앞선 과정에서 Ragas 프레임워크를 도입해 시스템을 평가했다. 하지만 로그를 살펴보다 보니 한 가지 심화적으로 할 수 있는 부분이 생겼다. 바로 Ragas의 기본 채점기(4대 메트릭 + Answer Correctness)는 문장의 "의미(Semantic)"를 파악하는 데는 탁월하지만, 정작 이번 다년도 문서 실습의 핵심인 "연도 숫자(2025 vs 2026)를 정확히 구분했는가?"에 대해서는 모른다. 즉, 답변에 타겟 연도가 정확히 포함되었는지, 혹시 다른 연도와 섞어서 대답하지는 않았는지 기계적으로 채점하는 나만의 평가 지표를 직접 만들어 본다. 1. 커스텀 Judge 설계: YearAccuracy 클래스 구현 Ragas는 파이썬 객체 지향 설계를 잘 따르고 있어서, SingleTurn.. 2026. 4. 27.
5-4. RAG 평가: 성적표 분석 및 딥다이브 (4가지 가설은 맞았을까?) CSV 파일을 열어 Ragas 4대 메트릭과 Answer Correctness 점수를 확인했다. 사람이 수동으로 채점할 때는 대충 맞았다고 넘어갈 수 있는 부분들을 AI Judge는 소수점 단위로 낱낱이 파헤쳤다. 실제 추출된 basic_ragas_scores.csv 데이터를 바탕으로 우리가 세운 가설을 검증해 본다. 가설 검증 1. 사람의 채점(4주차)과 Ragas의 채점(5주차)은 일치할까? 가설트렌드는 일치하겠지만, Ragas(Answer Correctness)가 훨씬 보수적으로 점수를 깎을 것이다. 실제 결과가설이 적중하였다. [q20] 교차 비교 문항 (노숙인 진료시설 유효기간)- LLM 답변: "2025년의 노숙인 진료시설 지정 유효기간은 2025년 3월 22일부터 2026년 3월 21.. 2026. 4. 26.
5-3. RAG 평가: Ragas 자동 평가 파이프라인 구축 데이터셋 준비를 마치고 수동 채점이 아닌, Ragas라는 체계적인 프레임워크를 통해 Basic RAG와 Advanced RAG의 성능을 객관적인 숫자로 뽑아내는 과정을 기록한다.4주차 RAG 파이프라인(Basic / Advanced) 재사용 및 Ragas 입력 스키마 매칭Ragas 4대 메트릭 + AnswerCorrectness 자동 평가 파이프라인 구축[Troubleshooting] BM25 필터링 누수 해결 (Post-Filtering)[Troubleshooting] 평가 모델 비용 및 Rate Limit 최적화 1. [트러블슈팅 1] BM25 필터링 누수 원천 차단 (Post-Filtering) Advanced RAG를 구성할 때 한 가지 치명적인 문제가 있었다. 벡터 DB(Chroma)는 쿼.. 2026. 4. 26.
5-2. RAG 평가: 확장 골든 데이터셋(v2) 구축 첫 번째 단계로, Ragas 프레임워크가 요구하는 표준 규격에 맞춰 기존 데이터를 고도화했다. 데이터셋 확장: 4주차 20문항을 바탕으로 ground_truth와 ground_truth_contexts 필드 추가.정밀도 향상: 단순 단답형이 아닌, 평가 모델(심판)이 인지하기 쉬운 완전한 문장 형태로 정답 정제.근거의 객관화: 벡터 DB의 검색 결과와 별개로, PDF 원본에서 직접 정답의 근거가 되는 문단을 발췌하여 삽입. 1. 왜 '확장'이 필요한가? (Ground Truth vs Context) Ragas로 RAG를 평가하려면 단순히 "질문-답변" 세트만으로는 부족하다. 시스템의 '검색 능력'과 '생성 능력'을 분리해서 평가해야 하기 때문이다.ground_truth (기대 정답): "이게 정답.. 2026. 4. 26.
5-1. RAG 평가: 감(Intuition)에서 데이터(Data)로 5주차 과정인 'LLM/RAG 시스템 평가'를 시작한다. 4주차에서 Advanced RAG를 통해 성능을 한계까지 끌어올렸다면, 5주차는 만든 시스템이 "진짜로 좋은지"를 숫자로 증명하고 정밀 진단하는 단계이다. 2025년과 2026년의 의료급여 데이터를 넘나들며 하이브리드 서치와 리랭킹을 적용한 RAG를 만들기 위해 노력하였다. 하지만 한 가지 의문이 남아있다. "내가 수동으로 확인한 20문제 말고, 수백 수천 개의 질문에서도 우리 AI가 잘 작동할까?" 이 질문에 답하기 위해서는 'LLM Evaluation'이 필요하다.RAG 시스템 평가의 필연성과 어려움 이해하기.Golden Dataset과 LLM-as-a-Judge의 개념 정립.Ragas 프레임워크의 4대 메트릭 분석 및 진단 체계 구축. 1.. 2026. 4. 26.
4-6. [리뷰]: Naive RAG의 한계 → Agentic RAG로 4주차 Advanced RAG 실습이 끝났다. 이전 포스팅들에서 경험했듯, 수천 자의 텍스트를 그냥 벡터 DB에 쑤셔 넣고 "비슷한 거 찾아줘"라고 하는 방식(Naive RAG)은 실무에서 철저히 실패한다. 연도를 헷갈리고, 고유 명사를 무시하며, 중요한 정보는 뒤로 밀려나기 일쑤였다는 것이다. 이번에는 마주한 이 실패가 '당연한 현상'임을 짚으며, 이를 해결하기 위한 실무 레벨의 거대한 아키텍처를 살펴보자. 1. 번외: Claude 3 Opus 4.7 업데이트와 AI 발전 속도 본격적인 리뷰에 앞서, 새로운 소식이 있었다. 바로 Claude 3 Opus 4.7 업데이트이다. 단순히 코딩 벤치마크만 올랐다고 발표되었지만, 실제 실무 챗봇에 적용해 본 결과 성능이 비약적으로 체감될 만큼 향상되었다고.. 2026. 4. 25.
4-5. Advanced RAG: Re-ranking (Cohere Rerank) 70%였던 Basic RAG의 한계를 하이브리드 서치와 필터링으로 90%까지 끌어올렸다. 하지만 여전히 해결되지 않은 2문제(q06, q20)가 발목을 잡고 있었다. 이 마지막으로, 리랭킹(Re-ranking)을 도입하여 컨텍스트의 순도를 극한으로 높여보는 시도를 기록해본다.Cohere Rerank API 연동 및 리랭커 설정Hybrid Search 결과물을 리랭킹하여 Top-3 선별Advanced RAG 최종 정답률 측정 (전수 조사)Basic vs Advanced 성능 비교 및 기여도 분석 1. [Step 2-3] Re-ranking: 검색 결과의 '질서'를 다시 세우기 하이브리드 서치로 가져온 5~10개의 청크 안에는 정답이 분명 들어있었다. 하지만 문제는 '순위'였다. 정답 청크가 3~4위에.. 2026. 4. 19.
4-4. Advanced RAG: Hybrid Search와 메타데이터 필터링 지난 포스팅에서 Basic RAG가 2025년과 2026년이라는 정보 앞에서 얼마나 무력하게 무너지는지 확인했다. 특히 벡터 검색이 숫자와 고유 명사를 뭉뚱그려 처리하는 바람에 발생한 대환장의 '연도 혼동'은 실무 RAG의 가장 큰 숙제이기도 하다. 오늘부터는 이 문제를 해결할 Advanced RAG의 핵심 기법들을 하나씩 적용해 보겠습니다. 첫 번째 해결 방안은 Hybrid Search와 Metadata Filtering이다.Hybrid Search (Vector + BM25) 구현ChromaDB 환경에 맞는 EnsembleRetriever 구성연도 혼동 원천 봉쇄를 위한 Metadata Filtering 적용 1. [Step 2-1] Hybrid Search: 유연함에 정교함을 더하기 벡터 검색.. 2026. 4. 19.
4-3. Basic RAG: 다년도 인덱싱, 파이프라인 연결 지난 포스팅에서 20개의 까다로운 골든 데이터셋을 만들며 평가 기준을 세웠다. 이제 그 목표를 달성할 엔진을 조립할 시간이다. 4주차 실습의 핵심인 '다년도 문서 처리'를 위해 인덱싱 전략부터 생성 파이프라인까지의 구현 과정을 기록한다. 질문 → 임베딩 → 벡터 검색 (Top-K) → 검색된 청크를 컨텍스트로 구성 → LLM 생성 → 답변 Step 1-1. 인덱싱 (Indexing): 두 해의 지식을 하나로 합치고, 꼬리표 달기 단순한 인덱싱이 아니다. 이번 실습의 핵심은 '메타데이터 필터링'을 위해 각 정보에 연도별 꼬리표를 다는 것이다.2025년, 2026년 PDF를 각각 로드하고 청킹각 청크의 메타데이터에 source_year 필드 추가 (예: {"source_year": "2025"})두.. 2026. 4. 19.
4-2. RAG의 기준 세우기: 다년도 골든 데이터셋 구축 지난 3주차에 하나의 PDF를 다루는 '네이티브 RAG'를 맛봤다면, 이번에는 실무에서 가장 흔히 마주하는 난관인 '다년도 문서(Multi-year Documents) 처리'를 기반으로 실습해볼 차례이다. 그리고, 3주차에서는 RAG Indexing 파이프라인(PDF → 청킹 → 임베딩 → 벡터 저장소)을 구축하고, Golden Dataset으로 검색 품질을 확인했다. 하지만 검색된 청크를 실제로 LLM에게 전달하여 답변을 생성하는 단계는 아직 구현하지 않았다.오늘부터는 그 가설을 검증하기 위한 실제 구현에 들어간다. 이번 실습의 가장 큰 챌린지는 "비슷하지만 다른 2025년과 2026년의 지식을 어떻게 혼동 없이 찾아낼 것인가"이다. 4주차 실습 목표Basic RAG 완성: 2025/2026 두 해의.. 2026. 4. 19.
4-1. Advanced RAG: Hybrid Search, Re-ranking, 메타데이터 필터링 3주차에서는 '네이티브 RAG(Naive RAG)'를 통해 부족함을 느껴보았다. 그리고, 데이터 정제를 통해 이를 극복하는 과정을 거쳤다. 이제 4주차에서는 그 한계를 완전히 뛰어넘어 실무 수준의 정교한 시스템을 구축하는 '어드밴스드 RAG'의 이론적 배경을 정리해 보겠다. 즉, 단순한 벡터 유사도 검색만으로는 특정 고유 명사나 복잡한 조건부 검색에서 한계가 있음을 뼈저리게 느꼈으니, 이번 주차는 그 한계를 넘어가 검색 성능을 한층 더 끌어올리는 고도화 기술들을 파헤쳐 볼 것이다. [Pre-Retrieval]: 1. 어드밴스드 RAG(Advanced RAG)란? RAG는 기술적 성숙도에 따라 세 단계로 진화한다. 우리는 지금 두 번째 단계인 Advanced RAG로 진입한다.단계 핵심 특징 한계N.. 2026. 4. 19.
3-6. [리뷰]: RAG의 본질: "답변을 잘하는 AI" vs "지식을 잘 찾는 AI" AI Agent 과정의 3주차는 지난 1, 2주차와는 패러다임이 완전히 다른 시간이었다. 지금까지 우리가 프롬프트 엔지니어링(Prompt Engineering)을 통해 "모델에게 어떻게 질문할 것인가"를 고민했다면, 이번 주차는 컨텍스트 엔지니어링(Context Engineering)이라는 새로운 영역으로 진입한 것이다. 2025~2026년 AI 서비스의 핵심 역량은 단순히 좋은 프롬프트를 짜는 것이 아니라, 모델이 원하는 행동을 생성할 가능성이 가장 높은 최적의 데이터(Context)를 어떻게 구성하고 제공하느냐에 있다. 1. 왜 다시 RAG인가? (The Return of RAG) 2주차까지 우리는 의료급여 본인부담률 표를 직접 시스템 프롬프트에 넣었다. 하지만 실무에서는 수천 페이지의 법령,.. 2026. 4. 18.
3-5. RAG 피드백: 청크의 품질 기술적으로 코드가 돌아가는 것(Running)과 실제로 유용한 시스템이 되는 것(Working)의 차이는 '데이터의 맥락(Context)'에 있다. 이 피드백을 통해 글을 작성해보겠다. 20%라는 다소 당황스러운 검색 성공률을 뚫고, PDFPlumber와 청킹 세분화 전략으로 정답을 찾아냈던 지난 기록에 이어, 오늘은 RAG 시스템의 심장인 '청크(Chunk)의 품질'에 대해 깊이 있게 회고해 보려 한다. 우리는 흔히 "검색이 성공했다"는 결과에만 집착하기 쉽지만, 그 너머에 있는 'LLM이 답변하기에 충분한 데이터인가?'라는 본질적인 질문을 던져본다. 1. 청크 안의 데이터 형태 청크 안에 데이터만 달랑 들어있는 상황의 위험성을 경고한다. ❌ 나쁜 청크의 예시 (맥락 없음)없음 10% 1,00.. 2026. 4. 7.
3-4. RAG 검색 품질 검증: AI는 필요한 지식을 잘 찾아올까? 실습의 고비이자 RAG의 성능을 결정짓는 가장 중요한 검증 단계인 [Step 3: 검색 품질 확인] 과정을 진행한다. 이 단계는 우리가 구축한 지식 저장소(Chroma DB)가 실제로 질문에 맞는 '바늘'을 잘 찾아내는지 냉정하게 평가하는 과정이다. 즉, 인덱싱 파이프라인을 통해 35개의 지식 조각(Chunk)을 저장소에 담았었고, 이제 이 저장소가 얼마나 쓸모 있는지 테스트할 시간이다. 직접 구축한 골든 데이터셋(Golden Dataset) 5문제를 활용해 벡터 검색을 수행하고, 모델이 정답의 근거가 되는 텍스트(evidence_text)를 제대로 포함한 청크를 가져오는지 확인해 보았다. 1. 검색 검증 방법론 검색 방식질문을 벡터화하여 Chroma DB에서 가장 유사한 상위 3개 청크(Top-.. 2026. 4. 3.

티스토리툴바