타임트리

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의 각 부분을 독립적으로 작업해야 할 때..

대화 기록 요약 추가멀티턴을 위해 대화 기록을 저장해두고, 모델 호출 시 프롬프트에 삽입하는 것은 채팅 관련 서비스에서 필수적인 기능 중 하나이다. 하지만 대화가 길어질수록 여러 제약이 따르는데, 예를 들면 Context length를 초과하게 되거나, Input token의 증가로 호출 비용이 증가하는 등의 문제가 있다. 그래서 일반적으로 대화 기록을 효과적으로 관리하는 방법을 사용한다.대표적으로 아래와 같은 방법들들이 있다.Vector DB Integration: 대화 이력을 임베딩 벡터로 저장하고, 유사도 검색으로 관련 대화 가져오는 방법. 맥락 검색 정확도가 높으나, 임베딩/검색 과정에서 추가 리소스 필요Sliding Window: 최근 K개의 대화를 저장해 최신 대화에 집중 가능하나, 과거 맥락..

병렬 노드 실행을 위한 브랜치 생성앞서 포스팅까지는 LangGrpah에서 하나의 노드에서 다른 여러 노드로 조건부로 분기하는 conditional_edge까지 다루고 있다. conditional_edge는 여러 노드 중 하나만 선택한다. 그런데, 만약 여러 프로세스를 동시에 처리가 필요한 경우를 생각해보자. 예를 들어, 리포트를 생성하고자 할 때 여러 관점(우호적/중립적/부정적)에서 각 LLM이 특정 주제에 대해 조사하도록 시키는 작업을 만들고자 한다. 이때 주황 박스로 표시한 부분은 순차적으로 처리하기보다는 병렬 처리를 통해 전체 그래프 작업의 속도 향상이 가능하다.다행히도 LangGraph는 Node의 병렬 실행을 기본적으로 지원한다. LangGraph에서 병렬 처리는 fan-out과 fan-in ..