티스토리 뷰

 

 

이전 글에서 Open AI의 Assistant API를 사용해봤다.

 

이전 글에서의 사용법대로 차례대로 포스트맨 요청으로 사용하면 타이밍만 잘 맞추면, 큰 문제가 발생하지 않는다.

(그래도 간간히 빈 문자열이 날아오는 경우가 생긴다.)

 

만약 실사용하게 된다면 아래와 같이 구성되게 될 것이다.

// 쓰레드 생성
val threads = assistantsClient.createThreads()
// 메시지 생성
assistantsClient.createMessages(threads.id, MessagesRequestDto("user", "PREP이 뭐야"))
// run 생성
val run = assistantsClient.createRuns(threads.id, RunsRequestDto(assistantId))
// run 상태 확인
assistantsClient.getRun(threads.id, run.id)
// message List에서 응답결과 확인
assistantsClient.getMessagesList(threads.id)

쓰레드는 사용자 별로 재사용할수도 있을 것 같기도하지만 일단은 무시 

 

문제는 run을 생성했을 때, run이 queued 에서 completed가 되는데 제법 시간이 걸리는데서 발생한다.

 

Run 대기상태 이슈

fun loopRunRequest(threadId: String, runId: String) {
    val startTime = Instant.now()
    while (true) {
        try {
            Thread.sleep(1000);
            val response: RunsResponseDto = assistantsClient.getRun(threadId, runId)
            println("retrying............")
            if (response.status == "completed") {
                break;
            }
        } catch (e: Exception) {
            println("error")
            return;
        }
    }
    val endTime = Instant.now()
    val duration = Duration.between(startTime, endTime)
    println("asyncRunRequest executed in ${duration.toMillis()} milliseconds")
}

1초마다 run의 결과를 확인하는 단순 루프문으로 구성해봤다.

 

run이 completed 될 때 까지 retrying을 찍고 

retrying............
retrying............
retrying............
retrying............
retrying............
retrying............
retrying............
retrying............
retrying............
retrying............
asyncRunRequest executed in 9420 milliseconds

약 10초나 걸린다!!

 

이럴 경우 요청이 대량으로 들어오게 된다면

 

톰캣의 모든 thread pool을 이 API가 잡아먹어버려서, 중요한 다른 요청들이 pending 상태가 되버릴 것이다.

 

이 작은 기능 때문에 메인 서비스가 의도치 않게 응답이 늦게 나가는 경우가 발생하게 된다.

 

어떻게 해결해야할지 고민을 많이해봤는데... 딱히 해결 방법이 없어서 그냥 함수를 람다에서 사용해야할 것 같다.

 

람다는 요청을 처리하는 함수가 대기 상태로 빠지면, 다른 함수를 병렬 실행하기 때문에 톰캣의 thread pool 문제를 발생시키지 않을 것이다.

 

비동기 처리나 다른 쓰레드에서 처리할 수 있을까 등 이런저런 생각을 해봤는데,

 

근본적으로 요청 쓰레드에서 발생하는 문제라 어떻게 해결이 안될 것 같다는 결론을 지었다.

 

고민하면서 딥다이브도 중요하지만, 피쳐 서비스 개발에선 결과물이 나오는게 중요하기 때문에 우선은 람다에서 구현해야할 것 같다.

 

Threads 리스트 보기(GET /threads API 사용하기)

이건 이슈라기보다는 API가 왜 없는지 알 수 없는 경우다.

 

Assistants API들을 훑어보면 GET /threads가 없다는 것을 알게 될 것이다.

 

thread를 확인하기 위해서 threadId가 필요한(?) API만 있다.

 

thread를 마음대로 만들다보면 삭제해야될 것 같은데 삭제를 못하는 경우가 생긴다.

(다행히 thread는 주기적으로 삭제된다. 삭제 주기는 마지막 접근일로 60일이라고 한다.)

https://platform.openai.com/docs/models/default-usage-policies-by-endpoint

 

사실 API를 제공안할리가 없다. 근데 숨겨놨다... 아래 글에서 어떻게 뚫나 알려줬다.

https://community.openai.com/t/list-of-threads-is-missing-from-the-api/484510/28

 

아래 순서대로 진행해보자.

 

1. https://platform.openai.com/assistants 페이지로 이동

2. F12 개발자 도구에서 Network 탭 열기

3. assistants 검색 후 새로고침

4. assistants?limit=10 RequestHeader 확인(맨 아래 있음)

5. Authorization에서 session key 복사(sess부터 복사)

 

 

7. Header에 OpenAI-Beta: assistants=v1 추가

 

 

8. Authorization에 Bearer 선택 후 session key를 채워넣고 https://api.openai.com/v1/threads 요청

9. 결과 확인(조금 걸림) 

 

그동안 생성한 thread의 리스트가 나온다.

 

github

https://github.com/imsosleepy/openai-api-repository/blob/main/src/main/kotlin/com/openai/controller/RunStatusController.kt

 

마치며

일단은 이것저것 부딪히긴했지만, 어떻게 구현해야할지 방향성은 잡은 것 같다.

 

더 나은 방식을 알게 되거나, Beta 딱지를 떼면 다시 확인해볼 것 같다. 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함