Skip to content

LLM, RAG 관련 기본 지식

Jump to bottom
Gyeongtae Park edited this page Sep 29, 2025 · 3 revisions

Lang2SQL 레포 요약

이 레포는 "자연어 → SQL" 변환을 자동화하는 툴킷임.

몇 가지 핵심 기능 및 구조

  • 자연어 질의를 받아서 내부적으로 최적화된 SQL 쿼리로 변환
  • 관련 테이블을 자동 추천하는 기능 (의미론적 검색 기반)
  • 스키마 인식 / 메타데이터 활용 — DataHub와의 통합
  • 벡터 DB (FAISS 또는 pgvector) 사용
  • 프론트엔드: Streamlit 기반 웹 UI
  • 내부적으로는 LangGraph 라는 LLM 워크플로우 오케스트레이션 레이어가 있음
  • “Graph Builder”, “Context Enrichment”, “Query Maker” 등의 구성 요소 선택 가능

최종 정리

단순히 LLM 하나를 던져서 자연어를 SQL로 바꾸는 게 아니라, 여러 단계(파싱, 테이블 검색, SQL 생성, 최적화 등)를 거치는 “파이프라인 + 보조 검색” 구조임.

LLM 기본 개념 정리

Lang2SQL을 이해하려면, LLM(대형 언어 모델, Large Language Model)에 대한 기본 개념이 필요함.

핵심 포인트

  • 모델 구조
    • Transformer 기반 구조 (예: GPT, PaLM, LLaMA 등)
  • 입력과 출력
    • 입력: 자연어 프롬프트 / 컨텍스트 + 추가
    • 정보출력: 텍스트 (SQL 쿼리, 질문 응답, 요약 등)
  • 프롬프트 설계 (Prompting)
    • 모델이 원하는 출력을 내게 하기 위해 프롬프트를 잘 설계해야 함 (사전 지시, 예시 포함, 형식 제약)
  • 제로샷 / Few-shot
    • 프롬프트 내에 예시를 넣지 않는 것이 제로샷, 몇 개 예시를 넣는 것이 few-shot
  • Fine-tuning / Instruction tuning
    • 사전 학습된 모델 위에서 특정 작업(SQL 생성 등)에 적응시키는 과정
  • 컨텍스트 길이 / 토큰 제한
    • 입력 문맥의 최대 길이 제한 존재 — SQL 변환 작업에서 스키마 설명 등을 얼마나 넣을 수 있는지가 중요
  • 제한과 오류
    • Hallucination (모델이 존재하지 않는 정보를 만들어내는 현상), 구문 오류, 스키마와 매핑 안 맞는 출력 등이 빈번

정리

Lang2SQL에서는 LLM이 바로 SQL을 뱉는 역할도 하겠지만, 보조 단계가 많아서 “LLM에게만 모든 걸 맡기지는 않는다”는 특징이 있음.

RAG (Retrieval-Augmented Generation) 기본 개념

RAG는 “생성 (Generation)” 모델 + “검색 (Retrieval)” 모델을 결합한 방식.

핵심 아이디어

  1. 입력 문장 (예: 자연어 질의)이 주어지면
  2. 관련 문서 / 정보 (예: 스키마 설명, 컬럼 설명, 테이블 메타데이터 등)를 검색해 와서
  3. 그 검색된 정보를 프롬프트 컨텍스트로 포함시켜 LLM에게 질의를 던짐
  4. LLM은 그 정보를 바탕으로 더 정확하고 사실 기반의 응답/출력을 생성함

RAG 장점

  • LLM이 이미 학습하지 않았거나 기억하지 못하는 최신/도메인 특화 정보도 반영 가능
  • hallucination 감소
  • 더 정확한 응답 가능

RAG의 여러 아키텍처

  • 두 단계 검색 + 생성: 먼저 검색(access), 그 후 생성
  • End-to-end 통합 모델: 검색과 생성이 상호작용하면서 이루어짐
  • 캐시 / 메모리 추가: 검색 결과를 저장하고 재활용
  • LLM 내부의 retrieval 단계: (예: ReAct, Tool-augmented 모델 등)

Lang2SQL에서 LLM + RAG 역할 및 적용 방식

  1. 테이블 검색 / 관련 테이블 찾기
  • 사용자의 자연어 질의가 들어오면, 해당 질의와 관련 있을 법한 테이블/컬럼 정보를 벡터 유사도 기반으로 찾아야 함
  • 이 단계가 “검색 (Retrieval)” 역할
  • 예를 들어, 쿼리 내 특정 키워드나 엔티티를 벡터화하고, 미리 인덱싱된 테이블 메타데이터 벡터 DB (FAISS 또는 pgvector)와 유사도를 비교해서 관련 테이블을 뽑음
  1. 프롬프트 컨텍스트 구성 + LLM 호출
  • 검색된 테이블/컬럼 설명, 스키마 정보, 관련 예시 쿼리 등을 LLM 입력 프롬프트에 포함
  • LLM은 자연어 + 이 검색된 정보를 바탕으로 SQL 쿼리를 생성
  • 이게 RAG의 “생성 (Generation)” 부분
  1. 최적화 / 후처리 / 검증
  • 생성된 SQL 쿼리에 대해 문법 검사, 스키마 일치 여부 검증
  • 성능 최적화를 위한 리팩토링 (예: 불필요한 JOIN 제거, 인덱스 고려 등)
  • 사용자에게 시각화 결과 제공
  1. 피드백 루프 / 교정 (선택적)
  • 사용자가 쿼리를 수정하거나 피드백을 주면 모델을 재조정하거나 후속 쿼리를 생성하게 할 수 있음

좀 더 깊게 알아두면 좋은 개념 / 이슈들

스키마 설명 표현 방식

  • 스키마 / 테이블 / 컬럼 설명을 어떻게 임베딩/표현해서 검색 인덱싱할지 (텍스트 기반, 구조 기반 등) 벡터 DB 선택
  • FAISS (로컬) vs pgvector (PostgreSQL 내장) — 확장성, 배포성, 실시간 업데이트 등 프롬프트 설계
  • 검색된 정보가 많아지면 프롬프트가 커지는데, 토큰 제한 고려해서 중요한 정보를 어떻게 선택/요약할지 모델 선택 / 비용
  • 어떤 LLM을 쓸지 (예: OpenAI GPT 계열, LLaMA, 내부 호스팅 모델 등), 호출 비용과 응답 속도 고려 하이브리드 접근
  • LLM만 쓰는 방식보다 검색 + 규칙 기반 병합 방식 (예: 기본 JOIN 알고리즘, 후보 쿼리 필터링 등) 조합이 더 안정적 오류 보정 / 검증
  • LLM이 잘못된 SQL을 생성했을 때 감지하고 수정하는 메커니즘 (예: 트라이 캐치, 구문 파싱, 실행 계획 검사 등) 보안 / 권한 제어
  • 사용자가 접근 권한이 없는 테이블에 SQL이 접근하지 않도록 제어 계층 필요 멀티테넌시 / 스케일링
  • 여러 데이터베이스, 대규모 스키마에서 성능 유지하는 것 피드백 학습 / 교정 루프
  • 사용자 수정 쿼리를 학습 데이터로 삼아 성능 향상 (on-the-fly fine-tuning or reinforcement)
Clone this wiki locally