PostgreSQL SQL2NL(7)

지난 연구 요약

LLM을 돌릴 때 Humantic(?)한 문구로 반환을 요청이라도 해야하나.. 고민이 된다. 어떻게 하면 좀 더 Human friendly 한 NL반환이 될 지 고민해봐야겠다. 무작정 LLM을 돌리면서 고민하자니 돈이 너무 깨지니까, 고민을 잘 하고 수행하자.

 

지난 시간에 SQL2NL API를 이용해서 GPT에 SQL을 던지고 NL을 변환받는 실험을 진행해보았고,(GPT 4o)

Table info / Parsing info를 Prompt Engineering을 진행해보았다.

 

Table info를 던졌을 때 좀 더 Human friendly 하고,

Parsing info를 같이 던졌을 땐 그냥 SQL을 어떻게 진행하면 되는지 Logic을 부가설명하는 느낌이 들었으며,

Table + Parsing info를 다 던졌을 땐 당연히 이 둘이 합쳐진 느낌의 NL이 반환되었는데, Gold NL처럼 의미가 명료한 녀석이 반환되진 않았다.

 

더 할 게 뭐가 있나.. 우찌해야 하나.. 째끔 난관이다.

 

NL2SQL의 Prompt Engineering 디버깅 기법을 참고해야하나 싶다...

 

1. NL2SQL에선 Prompt Engineering을 어떻게 진행하는지..? Script를 한 번에 집어 넣나 아니면 건 바이 건으로 집어 넣나.. 후자의 경우 경제적부담이 적지 않을 거 같다.

 

2. NL2SQL의 경향성(?)을 미리 예측해볼 수 있나? 아니면 전부 실험결과 관찰의 영역인가?

 

3. 젤 중요한 것. 원하는 데로 결과가 잘 나오지 않았다면 Debugging은 어떻게 진행하나? 이게 수식/공식이 있거나하면 대입을 할 수 있는데 우찌 진행하는지? 이게 소위 말하는 파인튜닝을 뜻하는 것인가..?

 

위 질문 3개에 대한 전문가님의 답변

 

1. SQL 건 바이 건으로 Prompt Script를 집어 넣는다 -> 돈이 많이 드는 건 매한가지다. 요즈음 LLM의 Prefix 기능이라고, Memory Cache 비슷한 기능이 있어서 이것을 사용하는 것을 검토 중인데, Cost는 모르겠고 속도가 빠르긴 하다. 2. 경향성 미리 예측 노노, 노가다 작업이 필요하다. 일단 돌려보고 결과들을 관찰하는 영역이다. 3. Debugging도 노가다로 진행한다. Error가 난 Pair들을 분석해서 나름 Solution을 예측(?)해보고 실험하는 방식이다. 일련의 경향성 같은 것들도 만들어 나가는 것이다. 수식/공식 등으로 미리 예단할 수 있는 영역이 아니다.

 

결국 노가다 이다.

 

돌려야 하는 Case가 많으므로 GPT-mini로 진행을 해야겠다.

 

스스로 문제를 case by case로 나누고 Error분석 과정에서 소정의 Insight를 얻길 기원해본다..