6 dbms별 sql 차이를 반영한 few shot prompt 최적화 제안 #14
Conversation
- Changed user input from a text area to a selection box, providing SQL_PROMPTS options - Added SQL_PROMPTS module
- Implemented query_maker_node_with_db_guide to generate SQL queries using user input and database context. - Introduced SQLResult model for structured output of SQL queries and explanations. - Updated graph structure to replace the previous query_maker_node with the new functionality.
- Change SQL query result output to a code block format for better readability - Add explanations to provide more context to users
| [state["messages"][0].content] + [state["refined_input"].content] | ||
| ), | ||
| "table_info": [json.dumps(state["searched_tables"])], | ||
| "top_k": 10, |
There was a problem hiding this comment.
💊 top_k가 10개로 제한되어있는데 해당 파라미터의 갯수를 input으로 받게하는건 어떨까요?
그렇다면 top_k의 값을
- 사용자 input
- LLM의 redefined input 생성때 희망하는 테이블 갯수도 함께 생성
이런식으로 받을 수 있을것 같습니다.
There was a problem hiding this comment.
top_k의 의미가 SQL LIMIT top_k 의미라서 생각하시는 것과 조금 다른 것 같은데 말씀하시는 top_k의 의미가 참고되는 table을 말씀하시는 것일까요??
There was a problem hiding this comment.
아하 그렇군요!! SQL_PROMPTS의 top_k 파라미터군요 설명 감사합니다.ㅎㅎㅎㅎ
| # StateGraph 생성 및 구성 | ||
| builder = StateGraph(QueryMakerState) | ||
| builder.set_entry_point(QUERY_REFINER) | ||
|
|
||
| # 노드 추가 | ||
| builder.add_node(QUERY_REFINER, query_refiner_node) | ||
| builder.add_node(GET_TABLE_INFO, get_table_info_node) | ||
| builder.add_node(QUERY_MAKER, query_maker_node) |
There was a problem hiding this comment.
💬 query_maker_node 함수 정의는 삭제되지 않았네요! (이견은 없습니다.)
추후에 성능평가 부분이 추가된다면 query_maker_node, query_maker_node_with_db_guide 를 비교해볼수도 있을것 같습니다ㅎㅎㅎ
There was a problem hiding this comment.
저도 만들면서 #3 작업이 필요함을 느꼈습니다. token 소비는 많이 줄었는데 이게 제대로 만든 것인지 구분이 안되어서
There was a problem hiding this comment.
💬 교체된 프롬프트 덕분인지 그런지 토큰 사용량 측면에서는 비용이 꽤 많이 절약되는 것 같습니다. 그런데 호민님께서 말씀해주셨듯이 생성된 쿼리가 제대로 된 작업을 하는지 검증할 수 있으면 좋을 것 같습니다!!
또한 추가적으로 생성된 쿼리의 성능평가를 한다면 어떤 측면에서(비용, 실행시간, 리소스, 쿼리 정확도 등등) 해야 할지 논의해 보아야 할 것 같습니다.
| # StateGraph 생성 및 구성 | ||
| builder = StateGraph(QueryMakerState) | ||
| builder.set_entry_point(QUERY_REFINER) | ||
|
|
||
| # 노드 추가 | ||
| builder.add_node(QUERY_REFINER, query_refiner_node) | ||
| builder.add_node(GET_TABLE_INFO, get_table_info_node) | ||
| builder.add_node(QUERY_MAKER, query_maker_node) |
There was a problem hiding this comment.
💬 교체된 프롬프트 덕분인지 그런지 토큰 사용량 측면에서는 비용이 꽤 많이 절약되는 것 같습니다. 그런데 호민님께서 말씀해주셨듯이 생성된 쿼리가 제대로 된 작업을 하는지 검증할 수 있으면 좋을 것 같습니다!!
또한 추가적으로 생성된 쿼리의 성능평가를 한다면 어떤 측면에서(비용, 실행시간, 리소스, 쿼리 정확도 등등) 해야 할지 논의해 보아야 할 것 같습니다.
|
|
||
|
|
||
| def query_maker_node_with_db_guide(state: QueryMakerState): | ||
| sql_prompt = SQL_PROMPTS[state["user_database_env"]] |
There was a problem hiding this comment.
💊: 추후 유저나 개발자가 프롬프트를 수정하고자 할 때, 추후 변경이 어려울 수도 있을 것 같습니다. 별도의 Class로 관리하는 것도 좋을 것 같다고 생각해 제안드립니다.
There was a problem hiding this comment.
💊: 추후 유저나 개발자가 프롬프트를 수정하고자 할 때, 추후 변경이 어려울 수도 있을 것 같습니다. 별도의 Class로 관리하는 것도 좋을 것 같다고 생각해 제안드립니다.
👍 #11 와 연결하면 좋을 것 같은데 Propmt를 위한 class가 정해지면 멘션 주시면 저도 참여하여 작업하도록 하겠습니다. 😄
이슈에서 제안 주신 langchain에 built-in 되어 있는
SQL_PROMPTS를 사용하여 각자 다른 DB 환경에 맞게 SQL를 생성하도록 하였습니다.Update 항목
llm_utils/graph.py-query_maker_node와 같은 역할을 하는query_maker_node_with_db_guide를 만들었습니다.llm_utils/graph.py- SQL result를SQLResult를 pydantic으로 정의하여 sql와 sql의 설명을 받도록 하여 sql에 불필요한 정보가 담기지 않고 sql의 설명을 이용하여 reasoning을 받아 사용자에게 설명하도록 하였습니다.interface/streamlit_app.py- graph의 response가 변경되어 streamlit의 출력 부분을 업데이트 하였습니다.interface/streamlit_app.py- streamlit 상에서user_database_env를 받는 방법을selectbox로 변경하였습니다.