Text-to-SQL 2차 개선
기존 방식의 문제점
스키마 과다 로드 문제
•
강의 예제: 이커머스에서 26개 테이블 사용
•
실제 쿼리에서는 3개 테이블만 사용 (items, orders, products)
•
전체 스키마를 가져오지만 실제로는 일부만 필요
•
실제 서비스에서는 100개, 200개 테이블과 더 많은 컬럼 존재
토큰 사용량 증가 문제
•
스키마가 복잡해지면 컨텍스트가 가득 참
•
토큰 한계 초과 가능성
•
불필요한 토큰 사용으로 비용 증가
•
처리 시간 증가 및 사용자 경험 악화
개선 방향
2단계 접근법
1.
테이블 목록 먼저 가져오기 (이름, 설명, 컬럼 정보)
2.
사용자 질문 기반으로 필요한 테이블만 선별
3.
선별된 테이블의 스키마만 가져오기
4.
토큰 사용량 감소 및 효율성 향상
구현 단계
1단계: 테이블 목록 가져오기
•
PostgreSQL에 쿼리 추가 (암기 불필요)
•
테이블명, 설명, 컬럼 정보 추출
•
초기에는 테이블 설명이 비어있음 (의도적)
2단계: 테이블 설명 추가
•
Comment on table 스크립트 실행
•
테이블에 설명 추가 (예: address → 배송 주소, 결제 주소 구분)
•
AI가 테이블 용도를 더 정확히 파악할 수 있도록 컨텍스트 제공
3단계: 테이블명 추출 LLM 체인
•
26개 테이블명을 한 번에 처리
•
이전처럼 루프 대신 전체 데이터를 한 번에 처리
•
코드 노드를 사용하여 결합
4단계: n8n 노드 구성
•
노드 복사 및 붙여넣기 활용
•
PostgreSQL과 LLM 체인 간 연결 재구성
•
코드 재사용으로 26개에서 1개로 출력 감소
5단계: 테이블 선별 LLM 설정
•
시스템 프롬프트에 테이블 설명 포함
•
사용자 질문과 관련된 테이블명만 추출 요청
•
GPT-4.1 사용 (어려운 작업이므로)
•
문자열 대신 리스트 반환 필요
6단계: JavaScript 처리
•
테이블명을 문자열 리스트로 변환
•
JavaScript map 메서드 사용
•
각 항목을 문자열로 변환 후 따옴표로 감싸기
•
WHERE 조건에 사용할 수 있도록 튜플 형태로 래핑
결과 및 트레이드오프
장점
•
실제 서비스에서 더 확장 가능한 구현
•
토큰 사용량 감소
•
스키마 로드 최적화
단점
•
기존 방식보다 처리 시간 증가
•
더 많은 작업 단계 필요
다음 단계
•
Text-to-SQL 워크플로우를 Slackbot에 연결
•
Slack에서 답변을 받을 수 있도록 구현
