PostgreSQL, LLM 연결(3)

 

To-do : 시간이 왜 이렇게 차이가 크게 나는지 디버깅, Hugging Face 기반으로 Llama 돌려보기, Llama Model Fine tuning방도 적용시켜보기

 

일단 이전 코드와 비교해보며 디버깅해보니, Table schema처럼 좀 긴~ 놈을 Prompt text에 그냥 집어 넣으면 시간이 오래 걸리고, System_prompt로 따로 빼 놓으면 시간이 좀 덜 걸린다.

 

같은 양의 Token 처리 비교 표

1. Table Schema를 System_prompt로 따로 빼놓기

2. Table Schema를 User prompt_text에 넣기

 

오케이, 대충 이거는 원인을 찾았다

근데, 이유에 대한 설명은 잘 나와있지 않다. 일단 GPT답변 참고,

1) 실제로 system prompt + user prompt를 합치는 과정에서 토큰 수가 달라진다 많은 라이브러리(예: OpenAI API, ChatCompletion 방식)에서 system 메시지는 대화 컨텍스트의 첫 부분에 붙여지고, user 메시지는 뒤에 붙습니다. 만약 “system prompt”를 별도 처리하거나, “user prompt”로 두 번 넣고 있다면, 결국 실제로 Llama가 처리해야 할 전체 길이가 다를 수 있습니다. 예시 상황: System prompt에 schema를 넣고, User prompt에도 똑같이 schema를 일부 반복 → 불필요하게 토큰 2배. User prompt에 schema만 넣고, system prompt는 짧게 유지 → 토큰이 덜 생김. 그러면 분명 “system prompt 버전”이 더 느려질 수 있습니다 (혹은 반대). 2) Ollama가 “system 메시지”를 다르게 tokenization/처리할 수 있다 Chat 모델(예: GPT-3.5/gpt-4)에서는 system 메시지가 “높은 우선순위”를 갖지만, 실제 맥락(토큰)은 여전히 모아서 하나의 conversation으로 처리합니다. Ollama(또는 llama.cpp 기반)의 “system: …” 문법도 내부적으로 user 메시지와 다르게 전처리하거나, 추가 토큰을 삽입할 수 있음. 이 과정에서 system에 방대한 텍스트를 넣었을 때, 추가 prompt 토큰(예: 내부 안내, role 표시 등)이 포함되어 길이가 더 길어지고, 결과적으로 추론 시간이 늘어날 수 있습니다. 3) 형식(포매팅) 차이로 인한 토큰 증가 system prompt 예시: user prompt 예시: 줄바꿈, 스페이싱, 인덱스, Markdown 등에서 system 구문에 추가되는 메타 토큰이 들어가면, 중간에 숨어 있는 공백·줄바꿈이 tokenization 때 크게 늘어날 수 있습니다. 4) 실제 프롬프트가 다를 가능성 종종 사용자 코드에서 system prompt에 table schema를 “매번” 붙일 때, user prompt에도 일부가 중복되어 “2번” 들어가거나, 또는 system prompt가 잘려서(토큰 초과) "…" 형태가 되면, user prompt가 제대로 반영되지 않는 식. 결과적으로 모델 입장에서 다른 길이/내용의 프롬프트 → 추론 시간이 크게 달라질 수 있습니다. 5) Llama가 context window를 초과하여 잘리는 경우 table schema가 지나치게 길면, Llama가 **context 한도(4k 토큰 등)**를 넘어 일부를 잘라낼 수 있습니다. 이 때, 잘리는 위치가 system prompt 쪽인지 user prompt 쪽인지에 따라 다른 토큰들이 남아 실제 수행 시간이 달라질 수 있습니다. 예: “system prompt에 엄청 긴 schema” → user prompt가 잘려서 “모델이 짧은 user 메시지”만 남김 → 예상치 못한 응답, 혹은 runtime 감소. 반면 user prompt에 긴 텍스트면 system 메시지 쪽이 잘려서, 등등.

 

자, 그러면 다음 이슈

Hugging-Face 입문과, 이를 이용한 DB-textbook 연계 Llama Model finetuning 업무!

---

이것은 일단 뒤로 미루자.

 

왜냐하면 PostgreSQL에 Extention을 이용한 PSQL 코드수정작업이 가능해야, 일단 아무 모델이나 거기에 올려두고 psql에 내가 원하는 기능을 수행할 수 있는지 확인이 가능하기 때문이다.

 

이것만 된다면, 내가 원하는 LLM Model 코드를 psql 코드에 이식만 하면 되고, 그 Model에 대한 Fine Tuning작업 역시 그 때 가서 해도 늦지 않다.

 

그래서 내 Postgres 환경에서( PostgreSQL ver 17.2 ) PostgreSQL 코드변경을 시도하여 psql에 원하는 Extention을 넣어봅시다.. 이게 말이 쉽지 생각보다 어려운 길일 것이다.

 

그 전에, 궁금한 사항! 도대체 psql이 무엇이고, PostgreSQL code를 수정해서 psql에 내가 원하는 extension을 넣을 수 있는지?

 

아래 답변은 GPT 답변이라, 좀 더 정확한 건 구글링 등등.. 을 통해서 알아서 찾아내긴 해야함!

1. psql이란 무엇이고, 어떤 역할을 하나요? psql은 PostgreSQL 데이터베이스 서버와 상호작용하기 위한 커맨드라인 클라이언트입니다. 사용자는 터미널(혹은 명령 프롬프트)을 통해 psql을 실행하고, SQL 쿼리를 직접 입력하거나 스크립트를 실행하여 데이터베이스를 관리·조회할 수 있습니다. 또한, \d, \l, \dt와 같은 “메타커맨드” 들을 제공하여 테이블, 데이터베이스, 함수 등의 정보를 빠르게 볼 수 있게 해주는 유용한 도구입니다. 요약하자면, psql은 PostgreSQL 서버와의 대화 창 역할을 하는 프로그램이며, 사용자가 SQL 쿼리 및 DB 관리 명령을 날려 결과를 확인하고, DB를 제어할 수 있도록 해줍니다. 2. psql 코드를 수정해서 원하는 확장을 수행할 수 있을까? 결론부터 말하자면, psql 자체를 수정하는 것은 얼마든지 가능하지만(오픈소스이므로 소스 코드를 내려받아 원하는 대로 변경 후 컴파일), 일반적으로 PostgreSQL 확장을 개발하거나 설치·관리하기 위해 psql의 소스 코드를 직접 수정할 필요는 거의 없습니다. 그 이유는 다음과 같습니다: 확장은 서버 레벨에서 동작 PostgreSQL에서 “확장(Extension)”이란 PostgreSQL 서버가 구동 중에 동적으로 로드해 사용하는 추가 기능 모듈을 의미합니다. 확장은 주로 C로 작성된 라이브러리(.so 등) 형태이거나 SQL 스크립트 등을 포함하며, “CREATE EXTENSION [이름];” 형태로 설치해 사용할 수 있습니다. 이 “확장”은 서버 측에서 동작하는 것이지, 클라이언트 툴인 psql이 직접 로직을 실행하는 구조가 아닙니다. psql은 단순한 클라이언트 psql은 SQL 쿼리를 서버에 전달하고, 그 결과를 받아 화면에 출력하는 CLI(Command Line Interface)입니다. 확장을 서버에 설치·관리하는 작업은 psql을 통해 실행되는 SQL이나 관련 명령어가 담당하는 것이므로, psql 자체를 새로 컴파일하거나 수정하지 않고도 충분히 확장을 로드하고 사용할 수 있습니다. 확장을 위한 표준적인 방법 PostgreSQL에서 확장을 사용하려면 다음과 같은 과정을 거칩니다: 확장용 라이브러리(.so 등)를 PostgreSQL 서버의 라이브러리 경로에 배치한다. CREATE EXTENSION 확장명; (필요하다면 FROM ... VERSION ...; 형태 등) SQL 명령으로 설치한다. 이 과정은 psql뿐만 아니라, 다른 PostgreSQL 클라이언트(예: pgAdmin, JDBC, psycopg2 등)에서도 동일하게 실행할 수 있습니다. psql 확장을 직접 개발·수정하는 경우 만약 “psql 프로그램 자체”에 특정 기능을 추가하거나, psql의 작동 방식을 바꾸고 싶은 경우에는 PostgreSQL 소스코드를 가져다가 psql 소스(C 언어로 작성됨)를 수정하고 컴파일하는 과정을 거쳐야 합니다. 다만 이는 일반적인 확장 개발과는 전혀 다른 맥락이며, psql 사용자 커맨드를 추가한다든지, 콘솔 입출력 방식을 바꾼다든지 하는 클라이언트 UI/UX 측면의 변경이 필요할 때만 의미가 있습니다.

 

그럼 이제 PostgreSQL source 코드를 수정해서 실제 PostgreSQL 안에서 Model 호출이 되는지 체크

아래 영상을 참고해서 코드를 짜보려고 한다.

'RUST'라는 언어를 사용한다는데 좀 불안하긴 하네 ㅋ;;

https://www.youtube.com/watch?v=g8lzx0BABf0

 

 

2023년 기준이지만, 이미 Rust로 PostgreSQL을 GPT에 연결하는 Library가 있다. called PGX

pg_gpt / pg_human이라는 Extension도 SW Engineer들이 만들었다.

 

 

이 절차에서 NL을 반환받으면 될 거 같다.

 

2023년 기준이라 그런가, PostgreSQL의 Schema를 받는 방법이 없어서 catalog를 보며 직접 table schema를 추출했다고 한다.

 

그 당시 RUST의 extension을 이용해서 GPT를 연결하였고, Prompt Engineering은 아래와 같이 진행했다고 한다.

RUST / C base의 PostgreSQL Extension Making with GPT 코드 Git hub를 찾았다. 이걸 변형해서 Develope해보자..

 

1.https://github.com/cloudquery/pg_gpt 2.https://github.com/prabin-acharya/pg_gpt 3.https://github.com/JelteF/pg_human 4. https://github.com/pramsey/pgsql-openai 5.https://www.crunchydata.com/blog/accessing-large-language-models-from-postgresql

 

---

 

PostgreSQL ver 17.2 기준, db의 table schema를 읽어오는 코드는 아래와 같다.

PostgreSQL의 pg_dump라는 녀석을 이용하면 된다.

pg_dump -U [username] -h [host] -p [port] -s -f [DDL저장하고픈 파일명->example].sql [DBname]

그러면 저 example.sql에 해당 DB의 Schema(DDL)만 추출된다.

 

그리고 cat을 이용해 해당 파일을 읽어보는 것이 가능하다.

cat example.sql

cat으로 postgreSQL 읽은 예시

파일 생성위치는 해당 코맨드를 날린 곳이다.

그래서 특정 경로에 스키마 파일을 저장하고 싶으면 pg_dump 명령어 실행시 절대경로를 지정해줘야 한다.

1. 기본 생성 위치 pg_dump 명령에서 -f db_schema.sql과 같이 상대 경로만 지정했다면, 그 파일은 **명령을 실행한 위치(현재 작업 디렉터리)**에 생성됩니다. 예를 들어, 쉘(터미널)에서 pwd(리눅스/macOS) 명령을 실행하면 현재 디렉터리를 알 수 있고, 바로 그곳에 db_schema.sql 파일이 생깁니다. 2. 절대 경로 지정 만약 -f 옵션에 절대 경로(예: /home/myuser/db_schema.sql 혹은 C:\path\db_schema.sql)를 넣었다면, 그 정확한 위치에 파일이 생성됩니다.

---

일단 이건 이렇고,

다시 돌아와서 PostgreSQL에 Coding작업 진행해보기..

 

일단 이게 PostgreSQL에 version에 맞는 http extension을 download 해야 하는데, 혹여나 version check 잘못했다가 깡그리 엎어지는 case가 있으므로, 다시 신중하게 알아보고 작업해야겠다.

 

뭔가, postgreSQL에 새로운 extension을 내 스스로 만드는건 객기같고, 남들이 구현해놓은 extension이나 코드를 이것저것 Searching 해 본 다음에 내가 이용할만한 것들이 있는지 적용해보고 수정이 필요하면 일부 수정하고, 이런 식으로 진행해봐야지.

 

다음 글에서 PostgreSQL http extension을 집중적으로 파헤쳐보고, 다른 Code변경법도 위 git-hub 링크들을 참고해서 적용시켜봐야겠다.

 

그리고, 백도화지에 그림 그리다가 조져졌을때 언제든 Roll-back 할 수 있는 git 사용법도 다시금 파악해놔야지!