현재 당면한 잔여 과업은 다음과 같다.
ⓐ 안정적인 Text-To-SQL
→ SQL 생성되나 정확도 낮음 (호기 매핑 실패 등)
ⓑ Vector 검색 최적화
→ 엉뚱한 문서 검색됨 (매뉴얼이 스키마 대신 나옴)
ⓒ 프롬프트 튜닝
→ 기본 구조는 있으나 페르소나/Few-shot 미적용
1. Text-To-SQL 안정화 (1순위)
1. Few-Shot 예시 추가
'질문-SQL 쌍'을 ChromaDB에 역으로 저장하기 (Few-Shot Embedding)
LLM이 SQL을 가장 잘 짜는 방법은 "선배들이 짜둔 올바른 SQL 예시"를 보는 것입니다.
구현 방법:
자주 묻는 질문과 그에 맞는 정답 SQL 문을 수십~수백 개 만들어 ChromaDB에 미리 저장해 둡니다.
실행 흐름:
사용자가 질문하면 ➔ ChromaDB에서 가장 유사한 과거 질문과 정답 SQL 예시 3개를 뽑아냅니다 ➔ 이 예시를 LLM에게 프롬프트로 주면서 "이 예시를 참고해서 실시간 DB용 SQL을 짜줘"라고 명령합니다. 이 방법을 쓰면 정확도가 비약적으로 상승합니다.
(*이전 게시글 참고)
2. Self-Correction 추가
(이전 게시글 참고)
3. DDL Comment 및 DB 메타데이터 제공
메타 데이터 추가
아무리 복잡한 재고,작업 관리 테이블이 복잡한 조인 관계를 맺고 있어도 llm이 알아서 분석하고 sql을 생성하게끔 하고 싶다. 최신 연구 결과를 토대로 LLM이 SQL 생성 최적화를 위한 스키마 표현 방식을 알아보고자 한다.
LLM을 데이터베이스(DB)와 연동할 때 스키마는 LLM이 데이터를 이해하고 올바른 쿼리(SQL)를 생성하기 위한 핵심 설계도 역할을 한다.
추가로, LLM 채팅 및 히스토리 기록용 스키마(MemoryDB)를 사용해 지속적으로 쿼리 퀄리티를 점검해볼 수 있다.
3-1. 스키마 제공 형태 비교
① TABLE 형태
- 컬럼명, 타입, COMMENT, FK/PK 관계 등 명시
② DDL(CREATE TABLE) 형태
- DDL+COMMENT 혼합
③ ②+{VIEW 정보}+{예시 데이터}+{샘플쿼리}
- 통틀어 현재로선 최고 성능*!
3-2. 메타데이터 제공
③ 과 같이 그냥 스키마를 제공하는 것을 넘어 실제 예시 데이터를 제공하도록 한다.
그런데도, DB 조회 성능이 여전히 시원찮다.
소스 데이터가 19.9KB인데, 14청크가 등록되어있다.
혹시, 청크 크기가 너무 커서 그런 건 아닐까?
토큰 : 단어/글자를 쪼갠 최소 단위 (평균 1단어 = 1~2토큰)
청크 : 여러 토큰을 묶은 검색 단위 이자 Chroma에 저장되는 단위
- withChunkSize(500) → withChunkSize(200) 로 바꿔보자
별 의미 없다.
애초에 schema.txt가 한 테이블당 글자 수가 500자 이상으로 한 청크내에 충분히 처리될 수 있는 크기이다.
대신에 VIEW 스키마를 포함시켰더니 훨씬 나아졌다.
애초에 VIEW가 필요한 JOIN을 다 해줬기 때문이다.
2. Vector 검색 최적화 (2순위)
이제 정적 RAG 데이터의 벡터 검색 최적화를 수행해보고자 한다.
2-1. 인덱싱 최적화
① 청크 크기 및 Overlapping 조절
문서 크기, 문서 내 정보의 크기에 따라 청킹의 단위를 적절히 조절해야 한다.
2-2. 검색(Retrieval) 및 쿼리 최적화
① 쿼리 확장
② ReRanking
2-3. Hybrid Search : 벡터의 한계 극복
3. 프롬프트 튜닝
4. Memory DB 이해하기
4-1. Memory DB란?
LLM에게 단기 기억을 만들어주는 저장소이다.
가령, 우리가 생성형 AI를 활발히 쓰다보면 "어라? 이전 질문을 가지고 파악하네" 라는 느낌을 받을 때가 있다. 마치 진짜 사람과 대화하는 듯 하다.
즉, LLM으로 하여금 대화 기록을 가지게끔 하는 것이다.
4-2. Memory DB 구현
거창한 별도 DB를 쓸+ 필요 없이, 실시간 조회를 위해 사용하는 관계형 DB(MySQL, PostgreSQL 등)에 chat_history라는 테이블 하나만 만들어서 저장하면 끝입니다.
사실 제일 중요한 건 최적화 !! 쿼리 최적화, 벡터 최적화, 프롬프트 최적화이다. 여느 AI 프로젝트나 환경설정-최적화 검증이 가장 시간 소요가 많이된다. RAG 파이프라인 자체를 구축하는 것 보다.
