Ollama+Spring 피드백 프로젝트 개발 2

 

지난 글에서 로컬 LLM 모델을 사용하는 프로젝트를 Spring 프레임워크와 통합하기로 했다.

현재 목표는 노션으로부터 일일 목표를 가져와 질문에 포함시킴으로서 (오늘 한 일)만 입력하여 피드백을 받아내는 것이다. 따라서 노션 api 및 비즈니스 로직(목표+task로 질문 가공)이 포함될 것이므로 Spring 프레임워크를 사용한다. 

스프링에서 Ollama 모델과 통신하기 위해서는 Spring Ai, Ollama4j 등 여러 선택지가 있다. 이 중 추상화 수준이 낮고 금방 구현할 수 있는 Ollama4j 를 선택하였다.

 

OllamaAPI 사용

OllamaAPI 의 채팅 기능을 사용하기 위해서는 OllamaChatRequestModel 클래스를 사용해야 한다.

OllamaChatRequestModel 클래스는 {Model, List<OllamaChatMessage> messages} 의 필드(파라미터)를 가진다.

OllamaChatMessage 는 각각 OllamaChatMessageRole 과 content(String) 을 가진 메세지 클래스다.

OllamaChatMessageRole 는 (String) Role 을 래핑한 클래스다.

Role 이란 System [지침 -> Modelfile 을 생성할 때 프롬프팅했던 부분]User [질문하는 사용자]Assistant [모델의 응답(?)]Tool [현재 버전에서는 지원하지 않음]을 가진다.

OllamaChatRequestModel 은 OllamaCommonRequestModel 을 상속받아 만들어졌기 때문에, 직접 만들기보다 OllamaChatRequestBuilder 를 사용하여 구성한다.

 

 

Spring 어플리케이션으로 로컬 모델과 통신

OllamaChatRequestModel 구성을 위해 OllamaChatRequestBuilder 사용하고 테스트 해 보았다.

테스트 실패 
→ OllamaChatRequestBuilder 를 초기화 할 때 model 이 파라미터로 들어갔으나, 실제 생성된 RequestModel 에서 model 파라미터가 비어있었음
→ 수동으로 model 값을 채워 주어 해결

또 실패
→ HttpTimeout 
11초 정도 응답을 대기하다가 타임아웃이 발생했다. 
그래서 우선 OllamaChatRequestBuilder 쪽에서 RequestModel 생성할 때 파라미터로 전달하는 timeOut 값을 바꿔 봤다. 그런데 요청 타임아웃이 아닌 듯 했다. 다른 ai 모델 인터페이스의 경우 keepalive 옵션은 모델이 해당 응답을 메모리에 로드하여 유지하고 있는 기간인 모양이다.

→ 로그를 자세히 보면 HttpClient 에서 timeout 이 발생한 것을 알 수 있었다.

ollama 와 직접 통신하는 핵심 객체인 ollamaAPI 의 내부 구현은 자바의 표준 HttpClient 구현인 Java Native HttpClient(이하 HttpClient) 를 통해 ollama 와 통신한다. 

그러나 HttpClient 는 기본 타임아웃 설정값이 정해져 있지 않아서, 클라이언트 측에서 따로 타임아웃을 정하지 않으면 대기 시간이 무한히 길어질 가능성이 있다. 실제로 구현을 까보니, ollamaAPI 내부적으로 requestTimeoutSeconds 필드의 기본 값을 10초로 설정해 두고 있었다.

이 값을 60초(PC 성능 고려)로 변경하니, 20초만에 응답을 볼 수 있었다.

----------------- my-assistant 모델과 통신 성공 -------------------

 

 

 

노션 데이터베이스에서 목표 읽어오기

노션 데이터베이스에 접근하기 위해 노션 api 를 사용하려 했는데, 목표 기능은 데이터베이스의 마지막 행에서 목표(이미 기입된 그날의 목표)를 읽어오는 것이었지만 이 기능을 직접적으로 제공하는 api 는 없는 듯 했다.

그래서 우선 기능 구현을 위해 Http 요청으로 데이터베이스 전체를 읽어와 Json 파싱으로 목표 데이터를 추출하는 방식으로 진행하였다. 읽어오는 방식은 후에 리팩토링 해야 할 것이다.

 

테스트 결과 목표를 리스트 형태로 추출하는 데 성공하였고, 이 값을 프롬프트로 가공하여 질문에 포함시킴으로서 [그날의 task 만 입력하고 피드백 받기] 라는 목표 기능을 완성할 수 있었다. 

 

피드백 서비스를 편의성 측면에서 고도화하긴 했지만, '나'를 타겟하는 서비스인 만큼 '내가 정말 필요로 하는 서비스가 되면 좋겠다' 라는 욕심이 생겼다. 그 고민에 대한 내용은 다른 글로 다루겠다.