문서 청킹(Chunking)으로 RAG 성능을 2배 올리는 법: 2026년 기준 Overlap vs Semantic Chunking 실전 분해 전략
· AI / RAG
RAG에서 “검색이 약하다”는 증상은 대개 retriever나 embedding 모델 문제가 아니라 문서를 어떤 단위로 쪼개서(indexing) ‘검색 가능한 최소 증거 단위’로 만들었는지에서 시작합니다.
Default
arXiv가 던진 경고: “에이전트는 똑똑해졌지만, 아직 믿고 맡길 단계는 아니다”
· News / AI
2026년 7월 arXiv에서는 LLM agent를 “더 잘 만들기”보다 “제대로 재기” 위한 벤치마크/평가 프레임워크 논문이 유독 많이 눈에 띄었습니다. 공통 결론은 단순합니다. 성공률은 생각보다 낮고, 길고 현실적인 워크플로우로 갈수록 급격히 무너진다는 것—이게 실무에 직격탄입니다.
MMLU·HumanEval 점수에 속지 않는 법: LLM 벤치마크 해석과 “내 서비스에 맞는 평가” 설계
· AI / LLM
LLM을 프로덕션에 붙일 때 진짜 어려운 건 “모델이 똑똑한가?”가 아니라 내 워크로드에서 실패하지 않는가입니다. 그런데 2026년 7월 기준으로도 많은 팀이 여전히 MMLU(지식/추론)와 HumanEval(코딩) 같은 전통 벤치마크 점수로 모델을 고릅니다.
Supervisor가 팀장이고 Worker가 실무자라면, 2026년형 Multi‑Agent Orchestration은 “대화형 LLM을 분산 시스템처럼 운영”하는 문제를 다룹니다
· AI / Agent
2026년 7월 기준 multi-agent orchestration에서 supervisor/worker 패턴이 다시 주목받는 이유는 명확합니다. 단일 agent + tools로는 다음이 잘 안 풀립니다.
FastAPI로 LLM API 서버 “진짜” 스트리밍(SSE) 구축하기 — 끊김/버퍼링/취소까지 엔드투엔드로 잡는 법
· Backend / API
LLM API 서버에서 “스트리밍”은 단순히 yield로 토큰을 흘려보내는 문제가 아닙니다. 실무에서는 다음이 같이 터집니다.
LLM Structured Output: JSON mode만으론 부족한 “Schema 강제”의 현실적 제약과 함수 호출 설계법
· AI / LLM
프로덕션에서 LLM을 “파서 앞에 세우는” 순간, 실패의 대부분은 모델 지능이 아니라 인터페이스 계약(contract) 에서 터집니다.
에이전트가 “검색→검증→재검색”을 반복하게 만드는 Agentic RAG 구현 패턴 (2026년 7월 업데이트)
· AI / Agent
전통적인 RAG는 대개 1회 검색(top-k) + 1회 생성으로 끝납니다. 문제는 실무에서 질문이 조금만 복잡해져도 “첫 검색이 틀리면 답 전체가 틀리는” 구조가 된다는 겁니다. 예를 들어:
오픈소스 LLM/VLM 2026년 7월 판도: “가중치 공개”는 늘었는데, **라이선스가 더 중요해졌다**
· News / AI
2026년 7월에도 Llama·Mistral·Qwen 계열을 중심으로 “open weights(가중치 공개)” 흐름은 이어졌지만, 실무 관점에선 모델 성능보다 라이선스/배포 조건이 더 큰 리스크 변수로 떠올랐습니다.
Cursor·Copilot·Windsurf, “에이전트 코딩” 실전 운영법: 규칙(Rules)·스킬(Skills)·브라우저·MCP로 생산성 올리기
· AI / Coding
2026년 7월의 AI 코딩 도구들은 더 이상 “autocomplete 잘해주는 플러그인”이 아니라, 작업을 분해하고(Plan) → 여러 파일을 수정하고 → 테스트/검증까지 반복하는 agentic workflow가 중심입니다. 문제는 여기서부터입니다.
컨텍스트 윈도우로는 부족하다: AI Agent 장단기 메모리 & Long-term 상태 관리 구현 가이드
· AI / Agent
2026년 7월 기준, “에이전트가 똑똑해지면 된다”는 기대는 대부분 깨졌습니다. 실제 장애는 모델 성능보다 state(상태) 관리에서 터집니다. 대표 증상은 아래와 같습니다.