dev-lee 님의 블로그

1. 이번 단계에서 달라지는 것LLM이 모르는 "사내·최신 데이터"를 RAG로 끌어와 추론에 반영하는 식사 추천 에이전트를 만듦.③편까지의 에이전트는 곱셈처럼 자체적으로 풀 수 있는 도구만 썼음. 이번에는 LLM이 모르는 정보를 다룸. RAG(Retrieval-Augmented Generation)를 도구로 차용해 다음 문제를 해결함.할루시네이션 방지 — 존재하지 않는 식당을 지어내지 않도록, 실제 데이터를 검색해 근거로 제공함.내부 데이터 접근 — LLM이 모르는 private 데이터(보안 이슈로 학습되지 않은 정보)를 보완함.최신 정보 부재 해소 — 학습 시점 이후의 정보를 외부에서 가져옴.설계 방향은 다음과 같음.전체 의사결정 — LangGraph가 담당함.부분 체인 — 프롬프트 → LLM 추론은 ..

1. 이번 단계에서 달라지는 것한 번 질의하면 잊어버리던 에이전트에, 대화를 이어 기억하는 단기기억을 추가함.②편의 에이전트는 매 질의가 "새 채팅창"이었음. 이전 대화를 기억하지 못해 같은 맥락을 반복 설명해야 했음. 이번에는 Checkpointer를 붙여 대화 상태를 저장하고, thread_id로 사용자별 기억을 관리함.MemorySaver — 상태를 저장하는 단기기억 저장소. 현재는 RAM 기반(프로그램 종료 시 삭제)임.checkpointer 옵션 — compile 시 기억 공간을 그래프에 연결함.thread_id — 대화 세션을 구분하는 식별자. 같은 id면 기억이 누적됨.그래프 구조 자체는 ②편과 동일하다. 바뀐 건 "상태를 저장하고 다음 호출에 다시 불러온다"는 점뿐이다.2. 메모리 생성`M..

1. 이번 단계에서 달라지는 것고정된 단방향 흐름에서 벗어나, LLM이 "직접 답할지 / 도구를 쓸지"를 스스로 판단하는 구조로 발전시킴.①편의 그래프는 경로가 코드에 박혀 있었다. 이번에는 add_conditional_edges로 분기를 주고, LLM이 도구 호출 여부를 결정하게 만든다. 핵심 추가 요소는 다음과 같음.LLM 노드 — AWS Bedrock 모델을 호출해 추론하는 "판단 노드"임.Tool 노드 — 실제 기능(여기서는 곱셈)을 수행하는 "행동 노드"임.조건부 엣지 — LLM의 응답이 도구 호출인지 텍스트인지에 따라 경로가 갈림.①편이 직선 도로였다면, 이번 단계는 LLM이 갈림길에서 핸들을 잡는 구조다.2. 준비 — 모델과 환경변수Bedrock LLM 객체를 만들고 `.env`에서 모델 정..

1. LangGraph 개요LLM 워크플로우를 "상태를 공유하는 노드들의 그래프"로 표현하는 프레임워크임.LangChain이 호출을 직선으로 잇는 체인 구조라면, LangGraph는 노드를 자유롭게 연결하고 조건·순환까지 표현할 수 있는 그래프 구조다. 첫 단계에서는 가장 단순한 형태인 단방향 그래프부터 시작함.1.1 핵심 3요소State(상태) — 모든 노드가 공유하는 전역 메모리. 데이터를 담는 그릇 역할을 함.Node(노드) — 작은 단위의 Task. 단순한 함수 하나로 구성됨.Edge(엣지) — 노드 간 실행 순서(방향성)를 지정하는 연결선임.노드는 "무엇을 할지", 엣지는 "어떤 순서로 흐를지"를 담당한다고 보면 된다.2. 상태 정의공유 메모리의 형태를 `TypedDict`로 규정함.상태는 그래..