HyDE × Reranking × Query Expansion: RAG 성능 최적화 “3단 부스터” 설계 가이드
· AI / RAG
RAG 성능이 안 나오는 팀이 흔히 하는 오해는 “embedding 모델만 바꾸면 해결된다”입니다. 실제로는 (1) 질문이 검색에 불리한 형태로 들어오고(짧고 모호함), (2) 1차 검색이 recall을 충분히 못 뽑고, (3) 최종으로 LLM에 들어가는 문서가 precision이 낮아…
Default
파일럿은 넘치는데 P&L은 조용하다: 2026년 5월, 엔터프라이즈 AI 도입의 ‘ROI 격차’와 멀티에이전트 확산
· News / AI
2026년 5월 기업 AI 도입 흐름은 “도입 자체”보다 스케일링(확장)과 ROI 증명으로 무게중심이 이동했습니다. 특히 멀티에이전트/Agentic AI가 실제 사내 업무 플랫폼으로 들어오면서, 성공 사례의 공통점과 실패 원인이 더 선명해지고 있습니다.
BM25와 Vector를 “그냥 섞지 말자”: Hybrid Search 랭킹 병합(RRF/정규화/가중치) 실전 가이드
· AI / RAG
RAG에서 “검색이 약간만 틀려도” 생성 품질이 급격히 무너지는 케이스를 많이 봅니다. 특히 다음 같은 상황에서요.
Vibe Coding 2026년 5월: “AI로 MVP를 빨리 만든다”를 실제로 **성공**시키는 프로토타이핑 아키텍처
· AI / Coding
2026년의 Vibe Coding은 “코드를 대신 써주는 autocomplete”가 아니라, 에이전트(Agent)가 계획→구현→실행→검증을 반복하며 제품의 형태를 빠르게 잡는 흐름으로 굳어졌습니다.
“AI Agent의 Tool Use/Function Calling”을 프로덕션에 넣는 법: Responses API + Agents SDK 패턴 정리
· AI / Agent
AI Agent에서 tool use(function calling) 는 “모델이 말로만 아는 척” 하는 구간을 줄이고, 외부 시스템(DB/HTTP/Queue/사내 API)과 실제로 일하게 만드는 연결부입니다.
Supervisor/Worker 패턴으로 멀티 에이전트 오케스트레이션 “운영 가능”하게 만들기
· AI / Agent
멀티 에이전트 오케스트레이션을 실제 서비스에 붙이면, 대부분 “에이전트가 똑똑한가”보다 누가 언제 무엇을 시키고(라우팅), 결과를 어떻게 합치며(합성), 실패를 어떻게 복구하는가(내구성)에서 망합니다.
컨텍스트는 길어졌는데 정답은 왜 가운데서 사라질까? — 2026년 LLM Long Context Compaction 실전 설계서
· AI / LLM
2026년의 LLM은 “128k+ long context”가 더 이상 특별한 스펙이 아닙니다. 문제는 컨텍스트를 많이 넣을수록 성능이 선형으로 좋아지지 않는다는 점입니다.
프롬프트 캐싱으로 LLM 비용 70~90% 줄이는 법 (2026년 5월 기준: Anthropic vs OpenAI 실전 설계)
· AI / LLM
에이전트/챗봇/코드리뷰 같은 “긴 컨텍스트를 매 호출마다 반복”하는 시스템에서, 비용의 본질은 (1) 출력 토큰과 (2) 반복되는 입력 토큰(prefix) 입니다.
vLLM·TGI·Ollama로 LLM 서빙 “진짜” 배포하기 (로컬/프로덕션/최적화까지)
· AI / MLOps
2026년 4월 시점에서 실무적으로 가장 많이 비교되는 축은 vLLM / Hugging Face TGI / Ollama인데, 포지션이 꽤 명확합니다.
PR 제목 하나로 CI의 API key가 새나간다: ‘prompt injection/jailbreak’이 “에이전트 런타임” 문제로 굳어진 이유
· News / AI
2026년 4월의 AI 보안 이슈는 “모델이 나빠서”라기보다, 에이전트가 읽는 모든 텍스트(이슈/PR/문서)가 곧 공격 표면이 된다는 점을 여러 사건이 동시에 증명했다.