타임트리

사용자 요구 사항 기반으로 메타 프롬프트 생성하기이번에는 프롬프트를 생성하도록 돕는 챗봇을 만들어보자. 챗봇은 먼저 사용자로부터 요구사항을 수집한 뒤, 이를 바탕으로 프롬프트를 생성하고 사용자 입력에 따라 이를 수정한다. 이 과정은 두 개의 별도 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의 답변이 필요한지 여부는 고려..

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 ..

LLM에 Tool을 binding 해서 LLM이 tool_calls를 생성했을 때, 적절한 arguments를 사용해 해당 tool을 실행하도록 하는 ToolNode에 대해 자세히 알아보자. 방금 작성한 그대로 로직을 작성할 수도 있지만(참고 - [LangGrpah] Tool Binding), LangGraph는 ToolNode를 사전 정의(pre-built)해서 제공한다. 내부적으로는 LLM에게 tool의 목록을 전달하고 (bind_tools), LLM이 사용자의 질문을 기반으로 tool 실행이 필요하다고 판단하면 해당 tool의 이름과 arguments를 반환한다. 그러면 해당 tool과 arguments로 함수를 실행하게 된다. 이때 tool list를 갖고, LLM이 반환한 tool_calls를 ..

메세지 삭제 방법일반적으로 State에는 messages라는 키로 리스트에 메세지 이력을 append 해가며 이력을 관리하게 된다.때로는 메세지를 삭제할 필요가 있을 수 있다. config별로 대화 내역을 쌓게 되는데, 내용이 너무 길어지면 컨텍스트가 너무 길어질 수 있다. 이외에도 필요없는 이력은 삭제하고 싶을 수 있다.이를 위해 RemoveMessage라는 reducer를 사용할 수 있다. RemoveMessage에 동일한 ID를 갖는 메세지를 자동으로 삭제해준다.간단한 웹 서치 그래프 정의먼저 간단하게 web search를 모방하는 search 함수를 tool로 정의하고 이를 binding한 LLM을 사용하여 그래프를 만들어보자. # web search graph 구축from typing impor..