타임트리

FastAPI에서 알아보는 동기와 비동기 처리의 차이FastAPI를 통해 동기(Synchronous)와 비동기(Asynchronous) 처리의 차이점에 대해 알아보자. 실제 코드 예제와 함께 이 두 가지 처리 방식의 동작 원리를 자세히 살펴본다.동기와 비동기의 기본 개념동기 처리 (Synchronous)여러 개의 스레드를 사용하여 작업을 병렬(Parallelism)로 처리각 요청마다 새로운 스레드가 할당됨→ FastAPI에서는 def로 정의하면 호출 시 내부적으로 ThreadPoolExecutor를 활용해 관리되어 여러 스레드에 동시 처리 가능 (병렬성)비동기 처리 (Asynchronous)단일 스레드에서 이벤트 루프를 통해 동시성(Concurrency)을 구현I/O 작업 중에 다른 작업을 처리할 수 있..

최근 LangGraph를 활용하여 멀티 에이전트를 구축하는 사례가 증가하고 있다. 이를 어떻게 배포하는 게 좋을까 구글링을 해보면 대부분  streamlit 등을 이용한 방법이 나온다. 그런데 이를 실제 서비스로 제공하기 위해서는 백엔드와 프론트엔드가 분리된 구조에서 배포하는 방법을 이해하는 것이 중요하다. 이번 글에서는 FastAPI를 활용하여 LangGraph 애플리케이션을 서빙하고, Docker를 이용해 손쉽게 배포하는 방법을 다룬다.1. 프로젝트 구조프로젝트의 디렉토리 구조는 아래와 같다../├── Dockerfile├── graph.png├── main.py├── requirements.txt├── graph│ ├── edges.py│ ├── graph.py│ └── nodes.py└..

LangGraph 글 중 [LangGraph] 요구사항 연속적으로 수집하기 (prompt generation) 를 FastAPI로 스트리밍 방식으로 서빙해보려다 문제가 발생해서 한참 헤맸다.  위 구조에서 information_gather 노드는 Pydantic model로 정의된 tool의 4가지 변수를 모두 채울 때까지 사용자에게 재질문하고, 모든 정보를 획득했다면 도구를 호출한다. 즉, 해당 노드는 일반적인 답변(content)을 뱉을 수도 있고, tool_calls를 반환할 수도 있는 상황이다. 먼저 일반적인 답변을 뱉는 상황을 살펴보자. (gather_chain은 이전 글 참조)from langchain_core.messages import HumanMessagemessages = [HumanM..

사용자 요구 사항 기반으로 메타 프롬프트 생성하기이번에는 프롬프트를 생성하도록 돕는 챗봇을 만들어보자. 챗봇은 먼저 사용자로부터 요구사항을 수집한 뒤, 이를 바탕으로 프롬프트를 생성하고 사용자 입력에 따라 이를 수정한다. 이 과정은 두 개의 별도 State로 나뉘며, LLM이 State 전환 시점을 결정한다.핵심은 반복적으로 사용자에게 질문을 하여 사전에 정의한 요구사항을 모두 수집한다는 점! 이 개념은 사용자로부터 수집해야 하는 정보가 필요한 서비스의 경우로 확장 가능하다. 예를 들어, LLM 기반 검색 시스템을 구축할 때 필요한 요구사항 수집 등에서 유용하게 사용될 것 같다. 만약 다양한 회의록을 검색하는 챗봇을 구축한다고 가정해보자. 이때 정확한 회의록을 찾기 위해서는 회의가 진행된 연도, 부서, ..

Adaptive RAG일반적인 RAG (흔히 말하는 Naive RAG 혹은 Advanced RAG)의 경우, 개발자가 전체적인 흐름을 정의하게 된다. 그리고 해당 흐름은 고정되어 있다. 아래와 같은 그래프의 경우 일반적인 RAG의 흐름이다. 아래 흐름에서는 우선 문서를 검색해서 가져온다. 그리고 문서의 연관성을 판단한 뒤, 만약 질문과 연관있는 문서가 retrieve되지 않았다면, 쿼리를 재작성하고 새로 작성된 쿼리로 문서를 가져온다.  다시 생각해보면, 위 흐름은 고정되어 있기 때문에 질문이 들어오면 해당 질문을 토대로 무조건 문서를 가져오게 된다. 즉, 벡터스토어로부터 문서를 검색하는 선택지 이외의 web search가 필요한지 여부 혹은 바로 LLM의 답변이 필요한지 여부는 고려하지 않는다. 이럴 ..

Agentic RAG 일반적인 RAG (흔히 말하는 Naive RAG 혹은 Advanced RAG)의 경우, 개발자가 전체적인 흐름을 정의하게 된다. 그리고 해당 흐름은 고정되어 있다.  아래와 같은 그래프의 경우 에이전트를 사용하지 않은 RAG의 흐름이다. 아래 흐름에서는 우선 문서를 검색해서 가져온다. 그리고 문서의 연관성을 판단한 뒤, 만약 질문과 연관있는 문서가 retrieve되지 않았다면, 쿼리를 재작성하고 새로 작성된 쿼리로 문서를 가져온다.   다시 생각해보면, 위 흐름은 고정되어 있기 때문에 질문이 들어오면 해당 질문을 토대로 무조건 문서를 가져오게 된다. 즉, 벡터스토어로부터 문서를 검색하는 선택지 이외의 web search가 필요한지 여부 혹은 바로 LLM의 답변이 필요한지 여부는 고려..

subgraph를 추가할 때, 메모리를 추가하면 언제든지 subgraph의 state를 확인하고 업데이트할 수 있다. 이를 활용하면 human-in-the-loop 패턴도 다양하게 사용 가능하다.그래프를 중단하고 사용자에게 state를 보여준 뒤, 사용자가 작업 수행 여부 결정subgraph를 rewind 해서 문제 재현 또는 방지사용자가 subgraph 작업 전 state 수정을 통해 제어1. subgraph 정의먼저 특정 도시의 날씨를 가져올 수 있는 간단한 subgraph를 정의하자. 그리고, weather_node 전에 그래프를 중단하도록 compile하자.with_structured_output 메서드는 LLM의 출력을 사전 정의된 pydantic 모델 타입으로 변환(pydantic이 아닌) 함..

LangGraph에서는 하나의 graph를 다른 graph에서 노드로 사용할 수 있다. 모듈화라는 측면에서 보았을 때, 특정 작업이나 기능 단위로 독립적인 graph를 구축하면 이들의 조합으로 하나의 큰 작업을 처리하는 parent graph를 생성 가능하다. 이처럼 subgraph를 사용한다면 다음과 같은 장점이 있다.멀티 에이전트 시스템 구축: 각 에이전트 subgraph가 독립적으로 작동하면서 parent graph에서 유기적으로 결합노드 재사용: 여러 graph에서 동일한 작업이 필요한 경우, 이를 subgraph로 정의해 두면 한 번 작성한 subgraph를 여러 parent graph에서 쉽게 재사용 가능.독립적인 작업 분리: 서로 다른 사람이 graph의 각 부분을 독립적으로 작업해야 할 때..