-
Notifications
You must be signed in to change notification settings - Fork 0
RAG ‐ GPT API Trouble Shooting List and Thinkers
Crawling에 있어서 합법 여부를 확인하기 위해서 Robot.txt를 확인할 필요가 있습니다. Robot.txt에 /disallow가 있는 페이지 목록은 Crawling이 법적으로 허용되지 않으며, 이에 따른 책임이 생길 수 있으므로 이를 사전에 확인하는 것이 중요합니다.
BE서버를 Python이 아닌 Java로 통일하여 Spring Boot 기반 서비스를 구축하고자 하는 초기 목표를 가지고 RAG를 Java 기반으로 구현하려고 하였으나, 사용하고자 하는 Vector DB Qdrant가 Java 호환성에 대한 정보가 미비하였으므로 구현하지 못하고 Python으로 서버를 분리 및 관리하고 있습니다. 특히나 AI기반의 서비스를 구상하시는 분들이라면 굳이 Java 단일 서버 사용보다는 Python 서버를 분리하는 방안도 고려해보시기를 권장드립니다.
Vercel에 배포한 Python BE 서버 관리를 위해서 CORS문제가 가장 극심한 골칫거리였습니다. vercel.json 구조를 통해 CORS 문제 해결 과정을 확인하시기 바랍니다. wildcard를 사용할 경우 CORS 문제가 지속적으로 발생해서 배포 페이지만을 CORS 허용하는 방식으로 문제를 해결하였습니다.
Python Server에서 GPT Inference 시간 동안 Timeout이 지속적으로 발생하는 문제가 있었는데 기본으로 제공하는 Vercel의 Timeout 시간은 굉장히 짧은 편입니다. vercel.json에서 timeout 시간을 조절하는 방법을 기재하였으니 해당 정보를 참고하여 내 서비스에 적합한 timeout 시간을 확보하시기 바랍니다.
보통 Prompt Engineering과 RAG를 함께 사용하게 되면 증강된 Prompt만큼 Token이 증가합니다. 서비스 제공의 이윤과 Token 사용량을 비교하여 적합한 수익구조를 만들어야 합니다.
GPT-3.5-turbo를 사용하였을 때에 GPT-4-turbo와 GPT-4o보다 확연한 성능 차이를 보였습니다. Fine-Tuning도 많은 가격을 요구하지만 GPT-3.5를 기반으로 학습해야 하기 때문에 RAG가 Model 성능 향상에 더 좋은 방법일 수 있습니다. HuggingFace를 사용한 다른 모델들도 탐색해 보았지만 GPT와 다른 vector dimension을 사용하고 호환성에 있어 GPT를 사용하게 되었습니다. 다른 모델들도 활용해보는 시도를 권장합니다.
생각보다 작은 차이에도 많은 격차가 날만큼 Prompt Engineering은 매우 중요합니다. 여러 논문이 있지만 결국에는 Heuristic한 방법으로 평가할 수밖에 없으며, 평가 방법은 GPT 그 자체를 활용하시는 것을 권장합니다.
axiosInstance를 별도 선언하여 Java 서버와 Python 서버를 분리하였습니다. axiosInstance .post( 'java server url', { } ) .then((uploadRes) => { axiosInstance_python
이런 식으로 python 서버를 분리하였습니다.