### **기능 설명 (Description)** - 카탈로그 내 쿼리 히스토리를 활용하여 - 컬럼의 속성 파악 : Dimension, Fact, Metric, Filter, ... - 타 테이블과의 관계 파악 : FK, relationship - SQL-to-Lang 을 이용한 QA셋 구축 ### **왜 필요한가요? (Motivation / Use Case)** - 코드/프롬프트는 도메인 지식을 모름 ( 회사마다 다른 경우도 많음 ) - A라는 컬럼을 집계해야되는데 더해야 할까? 평균을 내야 할까? - 설비 가동률을 알려달라는데 24시간으로 나눠야 할까 근무시간으로 나눠야 할까? - 재고수량 월마감을 해야하는데 미착품을 인식해야할까 말까? - 쿼리는 보통 항상 쓰는걸 쓰는 경우가 많음 - 이번달 매출 / 이익 -> 다음달 매출 / 이익 등 - 분석 역시 표준화된 Metric들 간의 비교로 출발 ### **제안하는 해결 방법 (Proposed Implementation)** - Table의 하위 document로 Column에 대한 document 강화 - { "type" : "filter", "statement" : "where A ilike '%text%'", "description" : "품번 조회" } - 기존 쿼리이력을 긁어 Table간의 끊어진 Relationship 생성 - 기존 쿼리이력과 유사한 경우, 템플릿화된 쿼리를 통해서 즉각 실행 <img width="1077" height="613" alt="Image" src="https://github.com/user-attachments/assets/4e71cd51-38d0-4554-baf3-0699b92f761f" /> ### **대안 (Alternatives)** - vanna.ai등의 프레임워크 차용 - Q&A RAG셋 구성 ### **추가 고려사항 (Additional Context)** - AI가 생성한 쿼리에 대한 RAG는 어떻게 처리할 것인지 고민이 필요. - 사용자 영향, 마이그레이션 이슈 등이 있다면
기능 설명 (Description)
왜 필요한가요? (Motivation / Use Case)
코드/프롬프트는 도메인 지식을 모름 ( 회사마다 다른 경우도 많음 )
쿼리는 보통 항상 쓰는걸 쓰는 경우가 많음
제안하는 해결 방법 (Proposed Implementation)
Table의 하위 document로 Column에 대한 document 강화
기존 쿼리이력을 긁어 Table간의 끊어진 Relationship 생성
기존 쿼리이력과 유사한 경우, 템플릿화된 쿼리를 통해서 즉각 실행
대안 (Alternatives)
추가 고려사항 (Additional Context)