Text-to-SQL 파인튜닝에 관련된 핵심 주제 및 관련 레퍼런스를 정리하는 공간입니다.
Topic 1. 병렬 처리를 통한 SQL 질문 생성
•
Use case: SQL 생성 목적에 따라, 별도의 분기를 생성하여 그래프를 실행한다 > 전체 그래프 실행 시간을 단축시킬 수 있다.
•
핵심 키워드
◦
병렬 실행(Parallel execution)
▪
팬아웃(Fan-out): 하나의 노드로부터 여러 개의 노드를 생성하는 과정
▪
팬인(Fan-in): 여러 노드의 실행 결과를 취합한 후, 하나의 노드에 전달하는 과정
•
고려 사항: 노드가 접근하는 각 상태 값은 reducer 함수를 통해 관리된다. 따라서, 취합된 SQL 질문을 저장하는 변수에 대해 별도의 reducer 함수를 구현해야할 수도 있다 (예: 중복 데이터 제거).
•
레퍼런스
◦
An agent for interacting with a SQL database (SQL 쿼리 생성 및 평가 에이전트 튜토리얼)
Topic 2. 멀티턴
•
Use case: SQL 구문 생성 및 검증이 한 cycle에 끝나지 않고, 여러 cycle을 수행해야 할 수 있다. 예를 들어, SQL 검증 시 특정 기준을 만족하지 못하는 경우, 다시 SQL 구문을 생성하여 평가를 수행해야 한다. > Loop 구현 시 멀티턴 방식을 생각해볼 수 있다.
•
레퍼런스
◦
▪
해당 튜토리얼에서는, Interrupt / Command 기반 Human-in-the-loop를 통해, 여행지와 숙박 시설을 추천하는 agent 구현을 다룸
Topic 3. 메모리 스토어
•
Use case: SQL 쿼리 생성을 위해 필요한 정보를 저장
◦
SQL 쿼리 생성을 위해 병렬적으로 노드를 실행할 때(superstep), 필요한 정보가 있음
▪
테이블 이름 / 설명
▪
각 테이블에 속한 컬럼 정보(이름, 용도, 자료형 등)
◦
위에 언급한 정보는 공통적으로 필요한 정보이므로, 한 개의 Store에 정보를 저장함.
▪
Graph state에 스키마 정보를 저장하지 않아도 되므로, in-memory 리소스를 최소화할 수 있음(병렬 처리를 수행하는 노드마다 스키마 값을 소유하는 상황을 방지할 수 있음).
▪
스키마 정보를 JSON 형식으로 전처리하고, Store(예: PostgreStore)에 저장하는 과정을 수행해야 함.
Topic 4. 함수형 API(베타 버전)
•
Use case: 데이터셋 생성 그래프를 구성하는 노드를 테스트할 수 있음(입출력 형식, 에러 발생 확인 등)
◦
Unit test
▪
예시: 쿼리 생성, 쿼리 검증
◦
Integration test
▪
예시: 쿼리 생성 + 쿼리 검증
•
특징: 코드의 변경을 최소화하면서, persistence / memory / human-in-the-loop 등 LangGraph의 주요 기능을 애플리케이션에 통합할 수 있음.
•
주요 키워드:
◦
entrypoint 데코레이터 → 그래프 진입점을 명시
◦
task 데코레이터 → entrypoint, task 또는 State graph 노드 내부에서 실행되는 함수에 적용 가능함. 비동기 실행과 체크포인팅 등의 기능을 지원함
•
주의 사항: entrypoint 데코레이터가 적용된 함수의 입/출력 값과, task 데코레이터가 적용된 함수의 출력 값은 JSON 직렬화가 가능해야함(JSON-Serializable) > 체크포인팅 기능을 사용하기 위함.
•
참고: 함수형 API와 그래프 API의 비교
항목 | 함수형 API | 그래프 API |
흐름 제어 | 그래프 구조를 고려하지 않기 때문에, 전체 코드 작성량을 줄일 수 있음 | 그래프 구조를 low-level로 관리하므로, 복잡한 분기 처리가 가능함 |
상태 관리 | 상태 관리 코드가 필요하지 않음 | 그래프 상태를 나타내는 클래스의 각 멤버 변수마다, reducer 함수를 구현해야 함 |
체크포인팅 | Entrypoint에 있는 checkpoint를 갱신하는 방식 → 한 개의 checkpoint로 관리 | 각 superstep 마다, 별도의 checkpoint를 관리함 |
시각화 | 미지원 | 지원 |
•
레퍼런스
Topic 5. 그래프 반복 횟수 제한
•
Use case: SQL 쿼리 생성 및 검증에 대한 loop 횟수 제한
◦
생성된 쿼리를 정답 쿼리와 비교할 때, 검증 지표에 대한 기준을 충족하지 못할 수 있음
◦
이 경우, 쿼리 생성과 검증 작업을 다시 수행해야 함
◦
이때, 반복 횟수를 제한하지 않는다면 다음과 같은 문제가 발생할 수 있음
▪
API call 횟수에 따른 금전적 비용 증가
▪
시간이 많이 지남에도, SQL 쿼리 생성을 못할 수 있음
◦
위에 언급한 문제를 방지하기 위하여, superstep(노드) 호출에 ‘recursion limit’을 부여할 수 있음.
Topic 6. 멀티 에이전트
•
Use case: SQL 쿼리 생성과 검증
◦
쿼리를 생성하는 과정 / 쿼리를 검증하는 과정을 각각의 Agent로 생각할 수 있음
◦
각 파트에서 실행해야 할 로직이 구분되기 때문
▪
쿼리 생성 에이전트: 데이터베이스 메타데이터와 사용자의 질문을 참고하여, 적합한 SQL을 생성
▪
쿼리 검증 에이전트: SQL 구문 검증 및 DB에서 해당 쿼리 실행 결과를 검증해야 함
◦
한 개의 그래프에서 데이터 생성과 검증을 수행할 지, 아니면 서브그래프(Subgraph)를 도입하여 각 에이전트를 구축할 지는 성능을 보고 판단
◦
만약, 멀티 에이전트를 사용한다면 Supervisor 개념을 도입할 것
▪
쿼리 생성 및 쿼리 검증에 대한 서브그래프를 생성하고, Supervisor가 상황에 맞게 그래프를 호출하는 방식