Moxie of Dev

LLM 기반 검색 성능 강화 기법 (5) - HyDE

개요HyDE(Hypothetical Document Embeddings)는 사용자 질의로 직접 검색하는 대신, LLM이 질의에 대한 가상의 답변 문서(hypothetical document)를 먼저 생성하고 그 문서의 임베딩으로 실제 문서를 검색하는 기법이다. "Precise Zero-Shot Dense Retrieval without Relevance Labels" 논문에서 제안되었으며, 관련성 레이블 없이도 제로샷 밀집 검색의 성능을 끌어올리는 방법으로 주목받았다.본 글은 LLM 기반 검색 성능 강화 기법 시리즈의 마지막 다섯 번째 글이다. 앞선 기법들이 모두 질의를 변형(재작성, 확장, 분해, 추상화)하는 접근이었다면, HyDE는 질의를 답변 형태로 바꾸어 검색한다는 점에서 발상이 다르다.설명밀집 ..

개요Step-Back Prompting은 구체적인 세부 사항을 담은 원본 질문에 바로 답하는 대신, 그 질문의 배후에 있는 상위 개념이나 일반 원리를 묻는 한 단계 추상화된 질문(step-back question)을 먼저 생성하고, 이를 통해 확보한 개념·원리를 근거로 원본 질문을 추론하는 기법이다. Google DeepMind의 "Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models" 논문에서 제안되었으며, RAG 파이프라인에서는 추상화된 질문으로 검색을 수행하여 더 일반적이고 안정적인 근거 문서를 확보하는 용도로 활용된다.본 글은 LLM 기반 검색 성능 강화 기법 시리즈의 네 번째 글이다. 3편의 Decompositi..

개요Decomposition(질의 분해)은 하나의 복합 질문을 LLM으로 여러 개의 하위 질문(sub-question)으로 분해하고, 각 하위 질문에 대해 검색과 답변을 수행한 뒤 그 결과를 종합하여 원본 질문에 답하는 기법이다. 다중 홉(multi-hop) 추론이 필요한 질문이나 여러 사실의 비교·결합이 필요한 질문은 하나의 질의로 검색하면 필요한 근거를 모두 확보하기 어렵다. Decomposition은 문제를 풀 수 있는 단위로 나누어 검색의 부담을 줄인다.본 글은 LLM 기반 검색 성능 강화 기법 시리즈의 세 번째 글이다. 2편의 Multi Query가 동일한 질문을 다른 표현으로 변주하는 기법이라면, Decomposition은 서로 다른 내용을 묻는 하위 질문들로 쪼갠다는 점에서 구분된다.설명"A..

개요Multi Query(다중 질의 생성)는 하나의 사용자 질의를 LLM으로 여러 개의 서로 다른 관점의 질의로 확장하고, 각 질의로 검색을 수행한 결과를 병합하여 검색 재현율(recall)을 높이는 기법이다. 단일 질의는 하나의 표현 방식과 하나의 임베딩 지점만을 가지므로, 관련 문서가 다른 어휘로 작성되어 있으면 검색에서 누락될 수 있다. Multi Query는 동일한 의도를 다양한 표현으로 변주하여 이 한계를 극복한다.본 글은 LLM 기반 검색 성능 강화 기법 시리즈의 두 번째 글이다. 1편에서 다룬 Query Reformulation이 하나의 질의를 하나의 더 나은 질의로 바꾸는 1:1 변환이라면, Multi Query는 하나의 질의를 여러 질의로 늘리는 1:N 확장이라는 점에서 구분된다.설명밀집..

개요Query Reformulation(질의 재작성)은 사용자가 입력한 원본 질의를 검색에 더 적합한 형태로 고쳐 쓰는 기법이다. RAG(Retrieval-Augmented Generation) 파이프라인에서 검색 품질은 최종 답변의 정확도를 좌우하는데, 사용자 질의는 검색에 최적화된 형태가 아닌 경우가 많다. Query Reformulation은 검색을 수행하기 전에 LLM을 활용하여 질의 자체를 개선함으로써 이 문제를 해결한다.본 글은 LLM 기반 검색 성능 강화 기법 시리즈의 첫 번째 글로, Query Reformulation만을 다룬다.설명RAG 시스템의 기본 구조는 Retrieve-then-Read이다. 사용자 질의를 검색기(retriever)에 전달하여 관련 문서를 찾고, 검색된 문서를 근거로..

개요WBS(Work Breakdown Structure, 작업 분류 체계)는 프로젝트의 총 범위를 계층적으로 분해하여 관리 가능한 단위로 구조화한 산출물 지향 도구이다. PMBOK 지침에서 WBS는 프로젝트 팀이 프로젝트 목표를 달성하고 요구된 인도물을 산출하기 위해 수행해야 하는 전체 작업 범위의 계층적 분해로 정의되며, 하위 수준으로 내려갈수록 작업 정의가 상세해진다. WBS는 계층 수준, 워크 패키지, 통제 계정, WBS 사전으로 구성되며 부모-자식 관계에 기반한다. 범위 관리의 기준선(scope baseline)을 형성하는 핵심 산출물이므로, 원가 산정·일정 개발·자원 배분·성과 측정 등 후속 프로세스의 입력으로 기능한다.설명WBS는 프로젝트 전체를 최상위 노드로 두고, 이를 주요 인도물 또는 단..

개요AI/LLM 분야에서 Tool과 MCP는 자주 함께 언급되어 혼동되기 쉬운 용어다. 그러나 두 개념은 서로 경쟁하는 대체재가 아니라, 다루는 층위가 다른 개념이다. 한 줄로 요약하면 Tool은 모델이 호출하는 개별 '기능(함수)'이고, MCP는 그러한 기능과 데이터를 표준화된 방식으로 연결하는 '프로토콜(규격)'이다. 본 글은 두 개념의 정의와 특징, 그리고 핵심 차이를 사실에 근거해 정리한다.설명Tool (도구, function calling)LLM 자체는 텍스트를 생성하는 능력만 가진다. 날씨 조회, 데이터베이스 검색, 메일 발송과 같이 외부 세계와 상호작용하는 작업은 스스로 수행하지 못한다. 이를 해결하기 위해 개발자는 함수의 이름, 입력 인자, 설명을 모델에 명세로 제공한다. 모델은 필요하다고..

개요Claude를 단순한 대화형 챗봇을 넘어 특정 업무에 특화된 도구로 확장하는 방법에는 크게 세 가지가 있다. 스킬(Skills), 커넥터(Connectors), 플러그인(Plugins)이 그것이다. 세 가지는 이름이 비슷하고 기능이 일부 겹치기 때문에 혼동하기 쉽지만, 실제로는 서로 다른 문제를 해결하며 경쟁하는 대안이 아니라 하나의 스택을 이루는 층(layer)에 가깝다. 본 글은 각 개념의 정의와 작동 방식, 등장 시점, 그리고 실제 사용 예시를 사실에 기반해 정리한다.세 기능은 모두 비교적 최근에 등장했다. 그 뿌리가 되는 MCP(Model Context Protocol)는 2024년 11월에 공개되었고, 스킬은 2025년 10월 16일, 플러그인은 2026년 1월 30일에 각각 도입되었다. 2..

개요TimescaleDB는 시계열(time-series) 및 이벤트 데이터를 효율적으로 저장하고 분석하기 위해 설계된 PostgreSQL 확장(extension)이다. 별도의 전용 데이터베이스 엔진이 아니라 표준 PostgreSQL 위에서 동작하므로, 기존 PostgreSQL의 기능과 SQL 문법을 그대로 활용하면서 시계열 워크로드에 특화된 성능을 얻을 수 있다.2025년 9월 25일 PostgreSQL 18이 정식 출시(GA)되었고, 한 달여 뒤인 2025년 10월 29일 TimescaleDB 2.23이 출시되면서 PostgreSQL 18에 대한 완전한 지원이 도입되었다. 본 글은 TimescaleDB의 기본 개념과 특징을 정리하고, PostgreSQL 18 환경에서 이를 설치·사용하는 방법을 다룬다...

개요LangGraph와 FastAPI로 구성된 백엔드에서 HITL(Human-in-the-Loop)을 구현할 때 핵심 과제는 상태 보존과 재개(resume) 이다. HTTP는 stateless이지만 HITL은 본질적으로 "그래프 실행을 중간에 멈췄다가 사람의 입력을 받아 다시 이어서 실행하는" stateful 패턴이기 때문이다. 본 포스팅은 이 간극을 메우는 방법을 LangGraph의 interrupt()와 Command(resume=...) 메커니즘을 중심으로 정리한다.설명HITL이 동작하기 위한 세 가지 필수 요소가 존재한다.첫째, Checkpointer 이다. interrupt가 발생하면 LangGraph는 영속성 계층(persistence layer)을 사용해 그래프 상태를 저장하고, 재개될 때까..