OpenAI API를 애플리케이션의 백엔드 에이전트 데이터로 활용한 KinoQuizAI 개발

OpenAI API를 애플리케이션의 백엔드 에이전트 데이터로 활용한 KinoQuizAI 개발

ChatGPT를 처음으로 생성AI(Generative AI)는 대화형 에이전트나 컨텐츠 생성 모델이 유효성이 되는 상태입니다. 하지만 이것에 포함되어 있는 대출 정보 자체를 데이터에 저장하여 활용하는 것은 언제까지입니까? 이 문제를 해결하기 위해 만든 KinoQuizAI 프로젝트의 발전 과정과 문제 해결 경험, 그리고 계층을 정리했습니다.

 

옛날에 ChatGPT와만 축소된 SNS 애플리케이션을 만들어 본 적이 있다. 경험에서 확신을 가지세요. 바로 직전 고도로 양식화 구조의 코드 생성이 가능하다면, 데이터가 된 것에서 필요한 내용까지 만을 찾아낸 뒤 최근 지표로 파싱하여 바로 허용하여 일도 가능할 것이다. 자연 플로어를 사용하는 대화형 에이전트 대신, 데이터베이스에 바로 삽입할 수 있도록 전처리된 결과물을 만들기 위해 백엔드 데이터 에이전트 역할을 언어 모델에게 던지는 것입니다 .

KinoQuizAI 프로젝트 앱 화면

이 아이디어를 토대로 4월에 KinoQuizAI 라고 말한 간단한 프로젝트를 만들었습니다. GPT 언어 모델이 생성한 영화 퀴즈를 풀고 점수를 얻는 웹 게임이다. ChatGPT와 같은 언어 모델 기반 서비스가 대화형 에이전트 뿐만 아니라 백엔드 기능 수행 도구도 원형을 확인하는 것이 목적이었습니다. 결과는 기대 이상이었다. 이번 글에서는 KinoQuizAI의 개발 과정과 문제 해결, 그리고 위로를 정리하고자 합니다.

 

키노퀴즈AI

KinoQuizAI는 영화 지식을 테스트하면서 다른 사람들과 경쟁할 수 있는 ChatGPT 기반 영화 퀴즈 게임입니다.

키노퀴즈AI

키노퀴즈AI 웹사이트

GitHub - seongjinme/KinoQuizAI: ChatGPT API로 구동되는 AI 생성 영화 퀴즈를 제공하는 Django 기반 웹 애플리케이션.

ChatGPT API로 구동되는 AI 생성 영화 퀴즈를 제공하는 Django 기반 웹 애플리케이션입니다. - GitHub - seongjinme/KinoQuizAI: Django 기반 웹 애플리케이션으로 인공지능 영화 퀴즈를 제공…

 

KinoQuizAI 프로젝트 성공

 

프로젝트컬렉션 기획사항

소재 선택 : 영화 퀴즈

GPT에 포함된 학습 데이터는 웹에 공개된 범용 정보를 기반으로 합니다. 따라서 GPT에 해독된 정보를 백엔드 데이터 소스로 활용하려면 공개 데이터가 가능할 만큼 충분히 가능하도록 개체를 찾아야 했습니다. 할루시네이션(hallucination) 에 의한 가능성이 줄어들었다는 사실도 있었다. IMDb 등 일반적으로 소스가 많은 영화는 이러한 조건에 맞춰 가능하다는 것이었다.

서비스 언어 선택 : 한글

ChatGPT 서비스의 간간이되는 GPT 언어 모델에서 한국어 학습 데이터량은 영어 데이터에 상대적으로 적다. OpenAI가 공개한 데이터 에 규격, GPT-3 기준으로 전체 사전 학습 데이터 중앙에 언어는 문서 단위로 0.019%, 단어 단위로 0.017%에 요청 했다. 이대로는 영어로 생성한 문서의 품질을 보장하기 어려웠습니다. OpenAI Playground 에서 gpt-3.5-turbo모델로 직접 실험한 결과도 예상되고 있었습니다. 이러한 현실을 고려하여 KinoQuizAI는 처음부터 국문 서비스로 기획했다.

기술 스택 : Django, JS, Tailwind CSS, Supabase, GCP

이제 내가 선택한 기술 스택은 다음과 같이 됩니다.

• 백엔드 : Python(Django)
• 프런트엔드 : JavaScript, Tailwind CSS, HTML
• DB, 스토리지 : 수파베이스
• 인프라 : GCP App Engine

개발을 기록하는 나는 축소의 CS50 웹 개발 과정을 절약하고 있었습니다. 때문에 KinoQuizAI는 내 졸업 프로젝트로 선택되었습니다. 해당 교육과정의 초상 Django 프레임워크와 JavaScript를 반드시 수정해야 했습니다. 윌리엄스 화면 구현을 위해 Tailwind CSS 를 추가로 사용했습니다. 덕분에 스케치 노트 한 장 없이도 원하는 화면을 빠르게 만들 수 있었습니다.

Supabase 는 Firebase의 오픈소스형 대안으로 가능하다. 데이터베이스 파일 관리와 도움말 DB를 구축하기 위해 선택했습니다. 처음엔 DB용 연장을 장기간에 걸쳐 구성할 수 있도록, 해결책을 이용하여 공수를 극적으로 단축시키는 일도 엔지니어에게 필요한 덕목이라고 보았다. Supabase의 경우 Python을 사용하면 사용자 커뮤니티에 종속되어 있고, 공식 매뉴얼과 실제로 적용하는 방법이 비활성화되는 문제가 남아 있습니다. 그러나 무료 티어에서도 PostgreSQL DB와 USB를 사용할 수 있게 되면 이점이 있다.

배포처에는 일찍이 조기에 경험이 되었기 때문에 GCP의 App Engine 을 선택했습니다. 원래 이용 가능했던 Vercel이 무료 티어에서는 Function Timeout이 최대 10초로 제한 하는 것을 확인 후 계획을 취소했다. 현재 OpenAI API에서 수신 데이터를 연결하는 길이가 5-15초 걸리게 됩니다. OpenAI API를 사용하는 환경에서는 빠~만하다. 무료 티어를 제공하는 다른 배포처들에서는 크고 작은 부분에서 필요한 조건을 충족하지 못했습니다. 결국 돈을 내고 편히 떠나는 마음으로 GCP를 선택했다. 2023년 4월 유럽 GCP는 새로운 주름에 첫 3개월 동안 $300+100 상당의 쿠폰을 주었고, 큰 매력 요소였다.

응용 동작 구성

OpenAI API 대화상자 구성

KinoQuizAI 앱의 핵심 동작은 클라이언트 - 서버 - OpenAI API를 사용하여 통신에 의존에서 살아난다. 머릿속이 백지상태였던 프로젝트가 시작되기 전에 macOS에 기본으로 포함된 Freeform 앱으로 이 시작된 동작 구조를 상상하여 대강 그려 보았습니다. 내용은 파악하기 어렵다. (이와 같은 그림 형식을 불러오기 (시퀀스 다이어그램) 이라 걸려면 최근에 야 합니다.)

클라이언트-서버-OpenAI API

1. 클라이언트에서 사용자가 서버로 퀴즈 생성을 요청한다.
2. 서버는 퀴즈 생성에 필요한 범위를 조합하여 OpenAI API로 전송한다.
3. 서버는 OpenAI API를 통해 생성된 퀴즈 데이터를 전송합니다.
4. 서버는 전처리 후 클라이언트로 데이터를 전송한다.
5. 퀴즈 답안 상황에서도 똑같은 방법으로 1-4번 단계를 반복한다.

이렇게 구성한 자원으로 개발에 돌입하자, 기획 단계에서 문제가 발생하기 시작했다.

• 그때마다 퀴즈를 받아 풀 때마다 OpenAI API와 교신이 두 차례 나 오가야 한다. 응답 지연이 오래 지속되면 OpenAI대기와의 교신 페이지를 늘리는 사용자 입장에서 더 많은 불편함으로 힘들어집니다.
• GPT는 언어 모델이다. 사실이나 부상에 대한 의무를 이행하는 도구가 출발합니다. 현재의 계획안은 GPT에게 문제의 채점이라는 원칙을 강화한다. 따라서 채점 결과물의 품질이 보장될 수 없습니다.

위의 두 가지 문제를 풀어놓기 쉽게 펼쳐서 구조를 훨씬 보기 쉽게 해야 했다. 서비스 제공자 입장에서 통제 영역을 낮추는 것이다. 수정한 결과는 다음과 같이 된다.

클라이언트-서버-OpenAI API 간화면2안

1. 클라이언트에서 사용자가 서버로 퀴즈 생성을 요청한다.
2. 서버는 새로운 퀴즈 콘텐츠(문항, 선택지, 번역, 해설자, IMDb URL 등)를 생성하기 위해 선택을 조합하여 OpenAI API로 전송한다.
3. 서버는 OpenAI API를 통해 생성된 퀴즈 데이터를 전송합니다.
4. 서버는 전처리하여 DB에 데이터를 저장합니다.
5. 서버는 DB에 저장을 마치고 퀴즈 데이터를 클라이언트로 전송한다.
6. 이후의 퀴즈 답안 확인은 클라이언트 - 서버 간 통신으로 만 이루어집니다.

이렇게 OpenAI API와의 교신을 회당 한 번 으로 늘릴 수 있었습니다. 사용자에 대한 지연 시간도 엄청나고 비용도 만만치 않으며 처음에 의도했던 사용자 환경도 성숙하게 유지된다. 구현도 더욱 간단해졌습니다.

일반적으로 사용자가 검토를 재개할 때마다 매번 콘텐츠를 생성하도록 하는 방식이 바로 비효율적이다. 다른 사용자에 의해 이미지가 생성되어 DB에 저장된 퀴즈를 새로운 사용자에게 우선적으로 제공하도록 하게 되면 훨씬 복잡해 지나요? 그래서 다음과 같이 탐구를 재설계했다.

클라이언트-서버-OpenAI API 간 임시안

1. 클라이언트에서 사용자가 서버로 퀴즈 생성을 요청한다.
2. 서버는 DB에 저장된 사용자의 풀이를 확인한다.
3. 아직 풀이되지 않은 문제들이 DB에 남아있다면, 그들 중 하나를 초기에 적어서 클라이언트로 전송한다.
4. 이 사용자가 DB에 저장된 모든 문제를 풀이한 상태라면, 새로운 퀴즈 내용(문항, 선택지, 번역, 해설자, IMDb URL 등)을 생성하기 위해 선택지를 조합하여 OpenAI API로 전송한다. 서버는 OpenAI API를 통해 생성된 퀴즈 데이터를 업로드한 뒤, 데이터를 전처리하여 DB에 저장 후 클라이언트로 전송한다.
5. 이후의 퀴즈 답안 확인 단계는 클라이언트 - 서버 유형 통신으로 만 실현됩니다.

이렇게 재설계한 구성을 본 프로젝트에 최종적으로 반영했다. 결과는 만족한다. 서비스 오픈 후 첫 팽창 기간 약 200명의 여성이 생겨서 총 510건의 문제 풀이가 되었어요. 기존에 생성된 퀴즈 기술을 신규 사용자에게 우선적으로 제공하도록 한 결과, 106개의 퀴즈 기술 만으로 이 참여가 이루어지게 되었습니다. 퀴즈 풀이 간 딜레이를 줄이는 등 사용자 환경을 크게 개선하면서 외부(유료) API 호출량도 또한 약 80% 정도 될 수 있습니다.

데이터 테이블 구성

구조를 구성할 수 없는 중요한 일이 데이터 저장 구조를 정하는 것이다. 일찍 SQL 학문을 공부하던 시절의 기억을 ERD(Entity Relationship Diagram) 을 먼저 그린 후에 Django 모델 생성 및 교정 작업을 진행했습니다.

ERD를 굽을 때엔 dbdiagram.io 서비스를 이용했습니다. 이 서비스는 데이터베이스 마크업 언어인 DBML 로 DB이고 구성을 마치 기록이 손상될 수 있게 합니다. 아래 이미지는 2023년 5월 현재 진행 중인 버전의 데이터 테이블 구성을 받침 받침이다.

KinoQuizAI 앱의 DB 테이블 구조

테이블 Quiz테이블의 역할이 가장 중요하다. 이 앱이 이전 작업을 수행하려면 OpenAI API를 통해 생성된 문서가 파싱 및 전처리 단계를 거쳐 이 테이블의 question, option, answer, explanation, imdb_url필드에 각각 차곡차곡 있어야 합니다. 이 프로세스가 오류 없이 되돌리려면 생산을 재개해야 합니다. 이 긴축을 만들기 위해 결국엔 작업에 공을 낮추어야 했습니다.

메시지 작업

채택의 품질이 응답의 품질을 결정한다. 단순히 정도가 아닌 하늘과 땅 수준의 차이다. KinoQuizAI 앱은 구상부터 배포까지 총 20일 이 걸렸는데, 그 중 수동인 열흘을 뺏어서 작업을 해야만 합니다.

이번 프로젝트에 적용한 프롬프팅 효능제를 아래에 소개한다. 모든 데이터베이스에 바로 삽입 가능한 가공된 콘텐츠를 지속적으로 생성하기 위해 적용하는 내용을 수행합니다. 이첵 OpenAI의 응용 AI 연구 부문 연구원(Head of OpenAI's Applied AI Research)인 Lilian Weng의 글 과 The Stanford AI Lab Blog에 올려서 In-context Learning 소개글 에서 큰 도움을 얻었습니다.

명령 프롬프팅

Instruction Prompting 은 언어 모델이 산출을 생성할 때 따라야 할 지시사항을 직접 전달하는 프롬프팅 정력이다. 언어 모델로 사용자의 의도를 잘 읽어내어 지시된 내용을 기준으로 유도하는 가장 기초적인 방법이다. Lilian Weng은 자신의 지연 엔지니어링 소개 글에서 다음과 같이 의미 있는 사항을 바라봐야 합니다 .

지침 모델과 상호 작용할 때 작업 요구 사항을 구체적이고 정확하게 설명하고 "무언가를 하지 말라"는 말을 피하고 무엇을 해야 하는지 지정해야 합니다.

• 작업에 필요한 요구 사항을 세분화하여 자세히 설명한다.
• 지시사항은 구체적으로 해야 한다.
• "무엇을 하지 않는다"고 하기에는 "무엇을 해야 할까요"라고 하여도 파생한다.

KinoQuizAI 앱이 빠르게 동작하려면 OpenAI API가 전달하는 것이 표준 형식에 따라 정확하게 파싱되어야 합니다. 드롭 생성된 퀴즈 정보를 DB에 채운 뒤 사용자에게 서비스할 수 있습니다. 이 기록에 (1) 어떤 기록을 생성해야 하는가, (2) 이 기록을 어떤 양식으로 출력해야 하는가에 대한 기록사항이 모두 기록되어야 한다 .

먼저 단어 생성을 하면 지연 내용을 소개하기 시작합니다. 이와 유사한 방법으로 퀴즈로서 지도교수 야 양식과 조건을 하나 지정했다.

Create a single movie quiz with four options. The quiz must follow conditions described below:
- The question must have four options: (A), (B), (C), (D) for answers.
- Only one option must be correct.
- Do not make up the content of correct option with false information.
- ...

다음으로 생성된 문서의 출력 양식을 검열한다. 이 내용을 적용하기로 하여 청구하는 것은 아래와 같습니다.

According to the conditions above, generate each element of the quiz. Follow the instructions below.
- There must be eight elements: question, option A, option B, option C, option D, right option, explanation, and IMDb URL.
- Include a single line-break(`\n`) at the end of each element.
- At the first line, ...
- At the second line, ...

이와 유사한 방식으로 여러 실험을 수행하기 위해 준비를 완료했습니다. 실제로 작동된 환경에서는 데이터와 빈을 포함하여 약 2,800자까지 연장 되었습니다. 여기에 9개의 콘텐츠 생성 조건과 12개의 출력 조건이 포함되었습니다.

상황에 맞는 학습

In-context Learning 은 최저에 작업 지시문(task description)과 함께 하나 이상의 전압 예시(few-shot)를 함께 포함시키는 프롬프팅 매력으로, GPT -3 논문 에 소개된 것처럼 Few-shot Learning 으로 설정된다. 작업을 기준할 때 사용자가 원하는 올바른 형태의 최소 표본을 언어 모델에게 짧게 짧게, 닙의 최하단에 예시와 닮은 입력 문구를 더 자연스럽게 생성하여 양식을 선택하도록 유도한다. OpenAI 공식 문서의 "Quickstart"에 포함된 "예시 추가"의 내용 이력을 활용한 주장이다.

OpenAI의 In-context Learning 프롬프팅 예시 화면

전압 이 프로젝트에서는 여러 환경에서 하나의 청구만 저지에 포함시키는 One-shot 을 사용했다. 이유는 다음과 같다.

1. 여러 개의 예시를 주회할 때 마지막 전기의 예시 내용과 거의 동일한 퀴즈 생성이 반복되었습니다.
2. 때때로 예시의 풀만큼 여러 개의 질문이 연달아 생성되는 문제가 발생했습니다.
3. 예시가 질의 전력 전력도 저지르다. 비용의 문제로 해결됩니다.

퀴즈의 유형, 내용, 기간에 이미 지난 시간으로 상세하게 결정되었기 때문에, 여기서 산출물의 출력 양식을 언어 모델에게 이해시키는 유용한 로만 예시를 활용하기로 했다. 열광에 열광하는 예시 내용은 다음과 같다. 그 결과, 예시와 똑같은 형태로 깨끗하게 정리된 데이터를 얻을 수 있었다.

...
- Follow the exact format of the example below. Do not include additional line-break between the elements.
- After the end line of this prompt, start printing your question.

[Question]
In the movie "Inception", what is the name of the device that allows people to enter and share dreams?
(A) The Dreamcatcher
(B) The PASIV Device
(C) The Mind Explorer
(D) The Dream Weaver
B
The PASIV (Portable Automated Somnacin IntraVenous) Device is a briefcase-like machine used by Cobb and his team to enter and share dreams. It's designed to administer a sedative called somnacin, which puts all users into a synchronized sleep state, allowing them to connect with one another in a shared dream world.
https://www.imdb.com/title/tt1375666/

[Question]

실제로 운영 환경에서는 이전과 같은 예시를 총 12개까지 만든 DB의 Prompt테이블에 포함 하고, 새로운 수학을 생성할 때마다 중 하나를 닫아서 빼기에 추가해서 해두었다. 내용의 예시가 반복되어 유사 유형의 퀴즈 생성이 되풀이될 가능성을 내재적으로 한정한다.

파라미터 튜닝

퀴즈를 만들 때 창의력과 엄밀성이 함께 필요하다. 모든 퀴즈가 바로 그 주인공 이름만 연필로 표현하다. 애써 풀어낸 퀴즈가 엉뚱한 선택이 된 번역으로 소개하는 상황도 피해야 합니다. 문항과 선택지에는 다채로운 재료와 흥미 요소가 권장되고, 답안과 주석에 충실한 내용이 우선적으로 이루어져야 한다.

서로 다른 두 가지 개체가 상호 생성 과정에 반영될 수 있다고 밝혔습니다. 하지만 결과물의 품질을 높이려면 반드시 해내야 했습니다. 필요할 때 필요한 것이 바로 직후에 (Parameter tuning) 이다. OpenAI API에 걸리고 함께 보낼 수 있는 temperature, top_p, frequency_penalty, presence_penalty등의 가능성 있는 가치를 GPT의 생성 결과물에 어느 정도의 득(혹은 획일성)을 부여할 수 있도록 조정해야 한다 . 각 항목은 OpenAI API 공식 문서에서 확인하도록 합니다.

사진한 관계자는 KinoQuizAI 앱을 활성화했다 값을 다음과 같이 정했다. temperature와 top_p값을 모두 가져왔을 때 보다 창의적인 문장을 구사하게 되었고, 또한 frequency_penalty와 presence_penalty새우 설정으로 동일한 소재로 교합비슷한 내용이 반복되지 않도록 유도했다.

parameters = {
    "temperature": 1.15,
    "top_p": 0.7,
    "frequency_penalty": 1,
    "presence_penalty": 0.85,
    "max_tokens": 2048
}

이대로 극도로 빨라졌을 뿐이지 이전에는 배우나 감독의 이름만 반복적으로 문제를 만들어냈다. 상표 최고 이후에는 영화 속 번역, 설정, 설명 등을 소재로 다양한 유형의 퀴즈가 생성되기 시작했습니다. 조그마한 간격의 품질 차이로 저지하는 격언을 실감한 순간이었다.

메시지 작업 결과

이렇게 작업을 초기에 새로운 생성과 데이터 파싱, 수신, 전처리 및 DB 삽입 과정에 가공 데이터 처리가 이루어지게 됩니다. 서버측에서 OpenAI API와 교신한 뒤 전송받은 데이터를 확인한 뒤 바로 DB에 제대로 클라이언트로 전달하는 로직만 실행하면 되었습니다. ChatGPT와 같은 언어 모델 서비스를 백엔드 데이터 에이전트로 활용하는 스파크가 구현되었습니다 .

생성 발전기 KinoQuizAI DB에 전처리되어 축적된 퀴즈 화면 데이터

문제 해결 및 개선 환경

퀴즈 재료가 특정 영화에 편중되는 문제 해결하기

이와 같이 임시 생성을 테스트하는 동안 긴급 상황이 발생한 문제에 직면했습니다. 생성된 탐구의 재료가 극소수의 유명 영화들에 제한이 있었다. <대부 대부> , <다크나이트 The Dark Knight> , <인셉션 인셉션> , <쇼생크 투구 The Shawshank Redemption> 을 엇비슷한 퀴즈가 반복적으로 만들어졌다. 시각적으로 보니 모두 IMDb에서 사용자 별점수가 가능하다는 것이 존재했습니다.

경찰은 이를 통해 GPT의 학습에 쓰인 데이터는 웹에 공개된 범용 정보를 얻는다. 인터넷에서 자주 거론된 영화일수록 기록된 데이터를 많이 명시하지 못했고, 그렇지 못한 영화는 참고할 자기 데이터에 적지 않은 학습량도 부족할 것이다. 이러한 정보량의 포장 임의의 영화 하나를 골라서 퀴즈를 만들 것이라는 명칭의 출력물에 영향을 미치게 될 것이다.

나는 KinoQuizAI 앱이 세계적으로 흔하고, 평단과 대중의 높은 평가를 받은 다양한 영화를 얻으려는 길 원했다. 따라서 백업의 첫 문구를 {영화}에 대한 퀴즈를 만들 것내용으로 수정하고, {영화}부분에 무작위로 삽입하여 영화 목록을 구성하여 DB에 미리 저장해 두기로 했다.

퀴즈 동물로 삼을 영화 목록을 바탕으로 정리한 화면

사진 목록을 복구하는 작업은 문서로 간략하게 진행되었습니다. 1996년부터 2021년까지 IMDb Top 250 Movie리스트를 가득 채웠고, 20만 개 이상의 사용자 별점을 획득한 상위 300개를 만들었다. 이렇게 연구한 영화 목록을 DB에 quiz_movie테이블로 복구하고, 퀴즈를 나중에 생성할 때 각 영화에 부여된 id값이 Foreign Key값에 따라 붙도록 수정했다.

퀴즈 테이블과 영화 테이블을 서로 연결한 결과

그 결과, KinoQuizAI 앱은 직업상 비상 사태는 영화 제목에 대한 퀴즈 생성을 긴급 해프닝으로 만듭니다. 훨씬 다양한 영화들을 소재로 퀴즈를 만들 수 있을 만큼, 지식이 풍부하고 심도 깊어지기까지 했습니다.

퀴즈가 생성될 때마다 번역이 (A)로 고정되는 문제 해결하기

생성 데이터가 이전에는 보이지 않거나 다른 문제가 발생했습니다. 정의에 용어 4개의 선택지 중 임의의 하나를 정답으로 만들 것조건이 연장되면 실제로 생성된 퀴즈들 중 약 70%의 번역이 (A)고정되는 현상을 중단합니다. 즉, GPT 언어 모델은 여러 개의 선택지가 있는 퀴즈를 생성할 때 가장 먼저 선 렬의 선택이 된 번역을 하고 내용을 채워넣는 경향이 있었습니다 .

리버풀의 퀴즈 Translation이 (A)로 계속 고정되는 상황

한 가지 선택지 로만 쭈욱 찍었는데 그게 다이가 되는 퀴즈 앱을 좋아할 사람이 될 거에요. 그것을 해결하기 위해 처음에는 작업을 시도하기 위해, 반복된 시도에도 불구하고 효과를 발휘하지 못했습니다.

결국 이 문제는 고민 이 사용자에게 다가갈 때마다 선택이 되었는지 판단하는 방법 으로 해결했습니다. 서버측에서 선택지 항목을 정면으로 스캔할 때마다 위상을 돋보이게 하도록 하고, 정면측의 선택각기에 해당하는 값에는 해당 선택지의 원래 radio input답안 value기호( A, B, )를 삽입하여 서버 C쪽에서 D처리쪽 DB 내용과 가능하게 처리했다.

앱의 주요 논리가 포함된 views.py파일에는 퀴즈를 생성한 후 클라이언트로 전송하는 get_quiz()것이 포함되어 있다. 이 처음의 리턴 코드는 원래 다음과 헤드입니다.

	...

return JsonResponse({
        "quiz": {
            "quiz_id": quiz.id,
            "question": quiz.question,
            "option_a": quiz.option_a,
            "option_b": quiz.option_b,
            "option_c": quiz.option_c,
            "option_d": quiz.option_d
        }
    }, status=200)

위의 코드 내용을 연구할 수 있었다. 선택지 항목을 처리하는 과정에서 secrets모듈에 포함되었습니다 randbelow. 각 퀴즈에 랜덤한 난수 ID를 건설하기 위해 secrets모듈의 choice를 사용하고 계시에, 얇은상 같은 모듈에 포함된 난수를 생성하여 꽃을 꽂았습니다. 배선의 슬라이싱 기능도 이 작업에 큰 도움이 되었습니다.

	...

# Shuffle the order of options to make user experiences more dynamic
    quiz_options = [quiz.option_a, quiz.option_b, quiz.option_c, quiz.option_d]
    quiz_option_a = quiz_options.pop(randbelow(len(quiz_options)))
    quiz_option_b = quiz_options.pop(randbelow(len(quiz_options)))
    quiz_option_c = quiz_options.pop(randbelow(len(quiz_options)))
    quiz_option_d = quiz_options.pop()

    # Considering shuffled order of options,
    # remove marks((A), (B), etc) from each option label before sending to the front-end.
    # Additionally, provide the original option values to fill values in the radio input form
    # which will be used to validate the user's choice.
    return JsonResponse({
        "quiz": {
            "quiz_id": quiz.id,
            "question": quiz.question,
            "option_a": quiz_option_a[4:],
            "option_b": quiz_option_b[4:],
            "option_c": quiz_option_c[4:],
            "option_d": quiz_option_d[4:],
            "option_values": [quiz_option_a[1], quiz_option_b[1], quiz_option_c[1], quiz_option_d[1]]
        }
    }, status=200)

이렇게 수정하자 퀴즈가 생성될 때마다 모든 번역이 (A)로 고정되는 문제가 해결되었습니다. 각각의 사용자가 가진 문제를 풀거나 서로 다른 선택지가 되어서 더욱 더 드릴 수 있는 사용자 환경이 만들어지는 효과도 얻을 수 있었습니다.

퀴즈 풀이 단계에서 복구 기능 추가하기

더 많은 영화를 개체로 꺼내서, 나중에 선택지의 돌도쯤 되게 푼 퀴즈 풀이의 주름도 덩달아 눕게 되었습니다. 이러한 여건에서 단 한 번의 오답이 게임 종료로 종료된 설정은 사용자에게 너무 가혹해졌습니다. 나중 박제권님께서 만신 퀴즈와(QuizWa) 웹 게임을 알게 되었습니다. 관련하여 "목숨 3개 켜서 아이들이 좋아했다" 는 환불을 본 후, 위의 게임에서 '목숨'을 하트 아이콘으로 표현한 디자인을 참고하여 KinoQuizAI에도 목숨을 걸고 있었다.

먼저 DB쪽 User모델에 IntegerField로귤을 3가져오는 life필드 를 추가하고, 사용자가 게임을 새로 옮길 때마다 life필드값을 3으로 인터페이스하는 코드 를 추가했습니다. 사용자의 퀴즈 풀이 결과를 확인하는 것은 실제로 get_result()는 오답일 경우 사용자의 를 life감소 1시키다가 결국, 해당 시점에서 life프로브 값을 확인하여 게임을 지속하기를 중단하는 코드를 가능하게 했다.

# If user's choice was wrong, reduce user's life by 1
if not is_user_choice_correct:
	user.life -= 1
	user.save()

# Check whether user's remaining life
game_continue = True if user.life > 0 else False

...

return JsonResponse({
	"quiz_result": {
		"is_user_choice_correct": is_user_choice_correct,
		"answer": quiz.answer,
		"explanation": quiz.explanation,
		"imdb_url": quiz.imdb_url
	},
	"user_status": {
		"life": user.life,
		"score": score,
		"game_continue": game_continue,
		"highest_record": highest_record,
		"is_new_record": is_new_record
	}
}, status=200)

이와 같이 JSON빼서 전송된 user_status.life값은 정면에서 머리말을 표기하는 용도로 머리 user_status.game_continue값은 게임 종료 시 이를 감지하여 퀴즈 화면 하단의 버튼을 변경하는 용도로 사용되었다.

목숨이 추가된 KinoQuizAI의 게임 화면

대출 기능을 추가한 덕분에 퀴즈 게임에 대한 초과 대출을 낮추면서 재도전을 받고 유도하는 사용자 환경을 더 할 수 있었습니다.

프로젝트를 통해 알게 된 것

이미 GPT와 같은 언어 모델에 대한 정보를 종합하고 간략한 지붕의 용도로 결합하면 최근에 표시된 서비스가 여럿 존재한다. 이러한 서비스들에 비하면 KinoQuizAI는 반대로의 작은 개인 프로젝트에 의뢰한다. 그러나 언어 모델을 데이터 베이스로 활용함으로써 백엔드 영역에서 서버 역할을 확증 하면서도 다채로운 내용의 스크립트 생성과 데이터 축적을 동시에 구현해낸 물음 에서 번개로 큰 뿌듯함을 펼쳤습니다.

서비스를 적절하게 고객의 요청에 따라 공급해 드립니다. 엔지니어의 참여에서 이 앱은 모델에 학습 데이터를 기반으로 언어를 기반으로 작성 및 저장을 만들어 낼 수 있습니다. 그러나 사용자 입장에서 이 앱은 오랜 기간 보아왔던 기본 기반 퀴즈 앱의 일종일을 진행합니다. ChatGPT나 Bing Chat을 통해 평범하게 보아온, 인공지능이 생성한 텍스트와 예측불가의 성과 스트림 형태로 결과가 중계되는 시간성 등의 재미있는 요소가 이 프로젝트는 과도하게 되어 있다.

또한 지속적인 촬영을 거쳤음에도 불구하고, 생성된 콘텐츠에 가능한 내용이 포함되는 경우를 완전히 제거할 수는 없었습니다. 아래는 KinoQuizAI 앱에서 106번째로 생성된 퀴즈 내용의 일부다.

In "Blade Runner 2049", what is the name of the company that created replicants?

(A) Wallace Corporation
(B) Tyrell Corporation
(C) Weyland-Yutani Corporation
(D) Waystar Royco

The correct answer is (B), Tyrell Corporation. In the original "Blade Runner" movie, replicants were created by the Tyrell Corporation. In "Blade Runner 2049", a new type of replicant has been developed by the Wallace Corporation, but they are still based on the original designs from Tyrell.

이 퀴즈의 실제 번역은 (A)다. 본원의 설명 문구 중 첫 문장에서 (B)Translation를 소개하고 있다. 엉뚱하게도 그 다음 문장에는 다시 (A)가 번역이 불가능한 이유를 자연스럽게 설명하고 있다. 수수께끼를 사실처럼 오도하거나 둘을 혼재시키는 할루시네이션(hallucination) 이 106개 퀴즈 중 9개에서 발생하였다.

다양한 턴과 프롬프팅 기술이 더 종료되더라도 언어 모델 자체의 권리상 허용의 가능성은 필연적으로 발생한다. GPT를 도입한 다양한 서비스들 또한 이러한 문제에 직면하고 있거나, 또는 해결 중일 것이다. 시각적인 기회가 된다면 그 노하우를 닮고 싶다.

 

반응형

 

SMALL

 

참고 문서

• OpenAI 공식 문서 : 채팅 완료 API 지연
• Lilian Weng : 프롬프트 엔지니어링
• The Stanford AI Lab 블로그: 상황 내 학습은 어떻게 작동합니까? 전통적인 감독 학습과의 차이점을 이해하기 위한 프레임워크