[SK네트웍스 Family 엔코아AI캠퍼스] AI 머신러닝 캠프 1기_9월 5주차 회고

About this offer

9월 5주차를 시작하며 지난주에는 RAG의 검색 품질을 높이는 방법을 배웠다면 이번 주에는 검색부터 답변 검토까지 전체 흐름을 연결하는 방법을 배웠다. 그래프와 벡터 검색을 함께 사용하는 방법부터 LangGraph의 조건 분기, 사람의 검토를 받는 HITL, 장기 기억, CRAG와 Self-RAG까지 다뤘다. 수업 내용을 TIL로 정리하고 과제를 풀면서 각 단계가 어떤 역할을 하는지 이해하려고 했다. 수업 외에는 정처기 실기 개념 회독과 문제 풀이도 함께 진행했다. FACTS 그래프와 벡터 검색 벡터 검색으로 시작점을 찾고, 그래프 관계로 범위를 넓히고, 전문 검색 결과와 비교한다. VectorRetriever : 의미가 비슷한 줄거리 찾기 VectorCypherRetriever : 그래프 관계까지 확장하여 같은 배우가 나온 다른 영화 찾기 복합 질문은 관계 조건과 줄거리 조건으로 먼저 나눈다. 관계와 연도는 그래프로 후보를 거르고, 줄거리는 벡터·전문 검색으로 순위를 매긴 뒤 합친다. LangGraph LLM에게 모든 일을 한 번에 시키는 대신, 작업을 작은 Node로 나누고 State로 데이터를 주고받으며 Edge로 실행 순서를 관리한다. State: 노드들이 공유하는 데이터 Node: 실제 작업을 하는 함수 Edge: 다음에 실행할 노드로 가는 연결 State 정의 → Node 함수 정의 → StateGraph 생성 → 노드 등록 → Edge 연결 → compile → invoke 워크플로우는 미리 정한 순서대로 실행하고, Agent는 모델이 상황에 따라 도구, 행동 등을 선택한다. 검토·수정 사이클 한 번에 생성하고 끝내지 않고 먼저 초안을 작성한 후 문제를 찾고, 문제를 고쳐 다시 확인한다. 초안 작성 → 검토 → 기준 미충족 시 수정 → 다시 검토 많이 반복한다고 결과가 좋아지는 것은 아니기 때문에 검토 횟수 상한 을 둔다. 체크포인터 현재 상태와 실행 기록을 저장하는 장치 InMemorySaver: 메모리에 저장 SQLite 파일 DB: 커널을 종료해도 남음 thread_id : 대화·작업을 구분하는 기준 체크포인터는 상태를 저장한다. 멀티턴 대화가 가능하려면 상태에 대화 목록이 저장되어 있어야 하고, LLM의 프롬프트에도 대화 목록을 넣어야 한다. HITL Human-in-the-loop, AI 작업 흐름 중간에 사람이 판단 하는 방식 interrupt() 로 그래프를 멈추고 사람에게 검토를 요청한다. approve: 이 문서로 확정 edit: 수정 후 다시 사람 검토 reject: 이 문서는 확정하지 않고 종료 사람이 선택한 값은 Command(resume=...) 로 그래프에 전달한다. 재개하면 검토 노드의 처음부터 다시 실행된다. 스트리밍 중간 진행 상황을 확인하거나, 최종 응답을 다 완성해서 받는 것이 아니라 생성할 때마다 받기 위한 용도 messages: 생성되는 글자의 조각별로 얻을 수 있음 updates: 어떤 노드가 어떤 State를 바꿨는지 보여줌 values: 초기 상태와 단계별 전체 State를 얻음 custom: 직접 만든 진행 상황, 상태 메시지를 전달 Store와 Mem0 Store는 내가 정리한 기억을 직접 저장하는 도구이고, Mem0는 대화에서 기억할 만한 사실을 추출하는 과정까지 도와주는 기억 관리 도구다. Store는 namespace로 기억 공간을 나누고, key로 기억 한 건을 구분한다. 체크포인터: 현재 대화의 상태 저장 Store: 여러 대화에서 재사용할 장기 기억 저장 Runtime context: 사용자 ID 등 실행 정보 전달 장기 기억에서 항상 참고할 프로필은 통째로 읽고, 과거 경험은 관련된 것만 찾는 게 효율적이다. 컨텍스트 엔지니어링 LLM에 주입할 컨텍스트를 결정하는 것 컨텍스트는 LLM이 답변을 만들 때 받는 모든 정보 로, 시스템 지시, 현재 질문, 이전 대화, 장기 기억, 출력 형식, 요약 등이 포함된다. 무엇을 넣을지 얼마나 넣을지 입력 토큰 예산 안에서 어떻게 구성할지 정보를 많이 넣으면 비용과 응답 지연이 늘어나고, 오래된 조건이 섞이거나 중요한 내용이 누락될 수 있다. 미들웨어 에이전트를 실행할 때 정해진 시점에 공통 처리를 붙이는 기능 “모델 호출 전에는 항상 입력 길이를 조절한다”와 같은 규칙을 노드마다 반복하지 않고 한 곳에 적용할 수 있다. before_model: 모델 호출 전 오래된 대화 요약 wrap_model_call: 입력 예산 계산, 대화 트리밍 after_agent: 요청 종료 후 장기 기억 갱신, 실행 결과 기록 CRAG 검색 결과를 평가하고 부족한 근거를 보완 하는 방법 내부 검색·평가 → 필요하면 검색어 수정·내부 재검색 → 그래도 부족하면 웹 검색·재평가 관련성은 문서 단위로, 충분성은 질문 전체 단위로 본다. 원질문은 바꾸지 않고 검색어만 교정한다. 일부 근거가 있으면 부분 답변으로 활용하고, 근거가 전혀 없을 때는 확인 불가로 끝낸다. Self-RAG 수업에서는 CRAG 프로세스에 답변 검토와 수정 노드를 추가했다. 답변 초안 생성 → 근거성·유용성 검토 → 미통과 시 수정 → 다시 검토 생성된 답변을 원질문과 근거 문서에 대조하고, 검토 의견은 반드시 다음 수정 노드에 전달해야 한다. 검토 한도까지 통과하지 못하면 보류하고 사람의 확인을 받는다. FEELINGS 이번 주도 개념을 이해하는 것과 직접 코드로 작성하는 것 사이에 차이가 느껴졌다. State, Node, Edge의 역할은 알겠는데, 조건 분기와 검토 단계가 늘어나면서 어떤 값이 어디로 전달되는지 따라가는 것이 어려웠다. 과제를 풀면서 막혔던 부분도 새로운 개념만은 아니었다. 모델 응답을 리스트로 반환해야 하는데 문자열의 첫 글자만 꺼내거나, 저장 함수의 반환값을 조회한 값처럼 사용하기도 했다. 기능을 이해했다고 생각했지만 실제로 어떤 데이터를 주고받는지는 놓치고 있었다. 그래도 TIL에 오류와 수정 이유를 함께 정리하면서 헷갈린 지점을 구체적으로 볼 수 있었다. 아직 혼자 전체 흐름을 작성하는 것은 어렵지만, 무엇을 다시 확인해야 하는지는 조금씩 명확해졌다. FINDINGS 가장 크게 배운 점은 함수를 작성하기 전에 그 함수가 어떤 역할을 하고, 어떤 값을 받아 무엇을 반환하는지 먼저 이해해야 한다는 것이다. LangGraph에서 State가 갱신되지 않았던 문제도 결과를 반환하는 것만 생각하고, 어느 필드에 넣어야 하는지 확인하지 않아 생겼다. 기억도 목적에 따라 구분해야 한다는 것을 알게 되었다. 현재 대화의 상태를 이어가는 체크포인터와 사용자 선호를 저장하는 장기 기억은 역할이 달랐다. 저장한 정보를 전부 넣기보다는 현재 질문에 필요한 내용을 골라 전달하는 과정도 중요했다. CRAG와 Self-RAG 실습에서는 관련 문서를 찾았다고 답변할 준비가 끝나는 것은 아니라는 점을 배웠다. 질문 전체에 답할 근거가 충분한지 확인하고, 생성한 답변도 그 근거와 맞는지 다시 검토해야 했다. 검토를 반복하는 것뿐 아니라 언제 멈추고 사람의 확인을 받을지도 정해야 한다는 점이 기억에 남았다. FUTURE 다음에는 코드를 보기 전에 질문이 들어와 답변이 나갈 때까지의 흐름을 먼저 그려보려고 한다. 그다음 각 노드가 읽는 값과 바꾸는 값을 적고, 내부 함수를 확인하는 순서로 공부하고 싶다. TIL에는 이번 주처럼 오류와 해결 이유를 함께 남기되, 자주 헷갈리는 입력·반환 형식을 중심으로 정리하려고 한다. 특히 수정한 코드는 다시 직접 작성해보면서 같은 실수를 줄이고 싶다. CRAG와 Self-RAG는 아직 코드만 보고 전체 흐름을 따라가기 어려워서, 수업에서 쓴 예제를 다시 보려고 한다. 어떤 경우에 재검색을 하고, 어떤 경우에 답변을 수정하는지부터 구분해보고 싶다.