Travel AI Q&A API Development
- Source
- Professional Work / TF
- Company
- SK M&Service
- Service
- Travel AI Q&A API
- Period
- 2023
- Role
- Software Engineer
- Scope
- PythonFlaskAzure OpenAIDockerGitLab CINomad
Overview
Built the core processing server for a GPT-3.5 Turbo-based travel Q&A feature in 2023, when ChatGPT was just beginning to be considered for real service use.
The Hyugashop mobile screen was the user-facing AI travel information entry point. My direct implementation scope was the Python/Flask-based TourGPT Gateway API Server behind that flow, receiving service calls and handling question-scope classification, GPT answer generation calls, response JSON construction, and conversation-history persistence.
Rather than mixing the feature into the existing Hyugashop/Benepia service codebase, I packaged it as a separate Python API server running in its own Docker container and connected it behind the existing service API layer.
In an operating environment centered on Java and Spring Boot, I worked on the company's first Python/Flask-based GPT API Server effort, connecting GPT calls through the designated Azure OpenAI environment, response-state design, Oracle history storage, Docker images, GitLab CI, Nomad jobs, and health checks.
Because there was effectively no internal reference for operating a Python web API in production, this project required defining the implementation, runtime, CI/CD, and deployment validation standards from the ground up.
Service Screenshots
Mobile Entry Point
The mobile entry point for AI travel information connected to the TourGPT Gateway API Server. User questions start at this touchpoint and pass through the service API to the Gateway API Server.
Chat Start
The question-entry screen before the TourGPT Gateway API Server call. After submission, the Gateway API Server handles scope classification and the GPT answer-generation flow.
Usage Policy
A policy screen where question limits, domestic travel scope, privacy-entry warnings, and answer limitations connect back to TourGPT Gateway API Server response states and guide-message rules.
Loading State
The waiting state shown while the TourGPT Gateway API Server processes an Azure OpenAI GPT-3.5 Turbo call, with timeout and response-state handling reflected in the user feedback flow.
Answer Result
The result screen where Azure OpenAI GPT-3.5 Turbo output is shaped by the TourGPT Gateway API Server into the service response contract and displayed in the mobile chat UI, including long answers, status messages, and history persistence.
Problem
In 2023, service patterns for LLM APIs, structured responses, and production deployment were far less mature than they are now.
The existing internal service stack was centered on Java and Spring Boot, so the team had to establish how to run a Python/Flask Gateway API Server as a separate production container, including Docker image design, deployment jobs, health checks, log paths, Oracle client setup, and proxy configuration.
This was not a simple GPT call demo. It was the company's first Python-based AI API effort that had to work as a Gateway API Server callable from mobile/service APIs, with response states, conversation-history storage, and production deployment validation.
My Role
- Led API implementation and response JSON structure design for the company's first Python/Flask-based TourGPT Gateway API Server
- Defined the domestic travel Q&A service scope, request/response JSON structure, status codes, and error/blocking message rules
- Implemented GPT-3.5 Turbo calls through the designated Azure OpenAI environment, question-scope classification, answer-generation flow, response JSON construction, conversation-history persistence, and session cache handling
- Aligned runtime validation standards with the infrastructure team for Docker images, GitLab CI, Nomad jobs, log paths, health checks, proxy configuration, and Oracle client setup
Key Contributions
- Separated question eligibility classification from answer generation into a two-step GPT call flow, allowing the TourGPT Gateway API Server to block out-of-domain questions at the server layer
- Shaped AI responses into service-consumable fields such as status, answer, keywords, and system message
- Connected Gateway response states and guide messages to the user flow covering question input, loading, answer display, and usage policy screens
- Stored conversation history in Oracle and maintained recent session context through an in-process cache structure
- Validated dependencies, Oracle client setup, Docker base images, GitLab CI jobs, Nomad jobs, and environment-specific configuration in an organization with no established Python service deployment standard
- Separated proxy, logging, health check, and canary/rollback concerns into production deployment checkpoints for the Python API
- Identified early operationalization standards for GPT APIs, including sensitive configuration separation, dependency reproducibility, and response schema validation
DevOps & Runtime Validation
- Packaged the Python/Flask-based TourGPT Gateway API Server as a separate Docker container and configured the GitLab CI build/deploy job flow
- Designed an operation-ready execution structure by separating development/production branches, environment-specific config, image tags, log volumes, resources, and service checks
- Solved reproducibility constraints around Python dependencies and Oracle client setup by validating Docker base images, package composition, and proxy configuration for deployment behind the existing Hyugashop/Benepia operating environment
- Validated Nomad docker-driver behavior, health checks, canary, and auto-revert conditions with the infrastructure team so the Python API was treated as a deployable, observable, recoverable service rather than experiment code
- Worked with the infrastructure team to establish deployment execution and incident-response criteria for a Python API runtime reference that did not previously exist inside the organization
Troubleshooting
- Prepared validation and correction flows for cases where GPT-3.5 Turbo returned responses outside the intended JSON structure
- Separated Azure OpenAI call failures by network, authentication, and response-handling layers to handle internal proxy constraints
- Aligned daily question limits, domestic travel scope, privacy-entry warnings, and answer-limit notices with Gateway response states and service guide messages
- Reduced development/production connection risk by repeatedly validating Oracle client behavior inside the Python container runtime
- Worked through the lack of Python service operating references by validating Docker images, package installation, log volumes, and Nomad resource/service checks one by one
- Extended simple runtime success into production-readiness by adding health check paths and deployment validation flow
Results
- Built the company's first Python/Flask-based TourGPT Gateway API Server end to end, from requirement shaping and API implementation to DB integration, container execution, CI/CD, and Nomad deployment validation
- Connected GPT-3.5 Turbo during the early ChatGPT adoption period as a service-style Gateway API Server spanning user screens, service APIs, operational DB storage, and deployment runtime
- Implemented the core Gateway layer behind the user flow from mobile entry and question start to usage guidance, loading state, and answer result
- Established a new Python service runtime and deployment-validation pattern in an organization centered on Java and Spring Boot, creating a technical reference for later Python/AI API adoption
- Connected AI API implementation, Python runtime, Oracle integration, and Docker/GitLab CI/Nomad deployment validation into a service-ready new-technology adoption effort