
RAG(Retrieval-Augmented Generation)는 대규모 언어 모델의 출력을 최적화하여 응답을 생성하기 전에 학습 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 프로세스입니다.
대규모 언어 모델(LLM)은 방대한 양의 데이터를 기반으로 학습되며 수십억 개의 매개 변수를 사용하여 질문에 대한 답변, 언어 번역, 문장 완성과 같은 작업에 대한 독창적인 결과를 생성합니다. RAG는 이미 강력한 LLM의 기능을 특정 도메인이나 조직의 내부 지식 기반으로 확장하므로 모델을 다시 교육할 필요가 없습니다.
이는 LLM 결과를 개선하여 다양한 상황에서 관련성, 정확성 및 유용성을 유지하기 위한 비용 효율적인 접근 방식입니다.
from. AWS
프로젝트 도중 Keywords에 해당하는 유사한 시를 발췌해야하는 상황이 발생했다.
따라서, txt화 시켰던 시들을 embedding 시켜 vector db에 저장하고# 한국어 지원 Sentence Transformer 모델 사용 model = SentenceTransformer('jhgan/ko-sroberta-multitask')keywords와 유사성이 높은 시들을 output이 되게끔 하였다.
유사도를 검색할 때 마다 3000개가 넘는 시들을 vector로 변환하는데 6분이 넘게 걸렸다.
따라서, vector db로 pinecone free를 사용하기로 했다.
Pinecone에 회원가입 후 API 키를 받고
jupyter를 사용해 pinecone INDEX(databse table 같은 것)에 vector들을 저장하였다.
저장 하는 과정에서 S3에서는 한 번에 1000개의 파일들만 뽑아올 수 있다는 사실을 알게되었고, while loop를 사용해 3000개를 모두 뽑을 수 있도록 코드를 수정하였다.
또한, pinecone에 한 번에 넣을 수 있는 vector 크기 제한이 2MB였기 때문에 batch_size를 100으로 설정하고 for loop을 사용하여 3000개에 해당하는 vector들이 한 번에 들어갈 수 있도록 수정해주었다.
vector화 시켜서 저장하였다. 이제 backend랑 연결하여 잘 뽑아오는지 확인하면 된다. 문제 발생.
pinecone 공식 홈페이지 방식대로 해봐도 연결이 안된다. dependency 문제인 것 같다.
오랜 시간 구글링 도중 또 langchain이 지원한다는 사실을 알았다.
langchain 사용하자마자 성공했다..
연결 성공 하였지만, 생각해보니 vector db에 metadata로 시 내용을 전부 넣어줘야지 시를 post 할 수 있다.
metadata로 시 내용 전체 vs 시 제목 고민 도중 txt가 용량이 별로 크지 않아 pinecone에 저장해놓고 바로바로 post 해주는 전략을 채택하였다.
(그러지 않았으면, postgresql을 다시 참조해야함 -> 용량이 크다면 생각해 볼만 하다. 나는 pinecone 무료 사용 유저니까)
BE 서버에서 sentence transformer 을 사용하여 직접 model을 가져와서 input text를 벡터화시켰다.
완벽하게 완료했다고 생각하고 argocd를 들어가봤다. degraded 상태인 pod가 엄청 많았다.. !! 내가 push한 시점부터 해당 문제가 발생하고 있었다.. rancher로 로그를 확인해보니, disk pressure가 발생하였고, ecr image 용량이 무려 6gb나 되는 것을 발견하였다 ..!!!!
따라서, BE에서 직접 모델을 불러오는 코드를 전부 삭제하고, 다시 push 후 argocd에서 멈춰있던 sync를 다시 연결해주자 pod가 다행히도 healthy한 상태로 돌아왔다.
hugging face 에서 api token을 발급하는 방법을 채택해야 겠다고 생각했다.
하지만, 생각처럼 연결이 안됬다. 처음에는 token을 fine-grained 가 아닌 read로 발급받아야 연결이 가능하다는 사실을 알았다.
다음 문제는 input text를 보내도 type error가 발생하였다.
문득 생각난 langchain!
역시 또 langchain에서 제공하는 huggingface dependency로 해결할 수 있었다 !! 결과적으로, healthy한 pod로 서비스를 정상화 시켰다.
push 하기 전 생각을 많이하고 해야겠다...
push가 완료되었다고 안주하지 말고 github action 로그와 argocd, rancher를 활용하여 로그를 반드시 모니터링하는 습관을 가지도록 하자.
argocd 로 pod를 확인해보면 Rolling update를 시각적으로 볼 수 있다.
pod는 3개로 유지되면서 이전 pod를 하나씩 새로운 image로 업데이트시킨다.
🤔Load Blancing이란?
Load Balancing은 여러 Pod에 걸쳐 트래픽을 분산시키는 역할을 하며, 클러스터의 서비스가 고르게 트래픽을 처리하도록 돕는 기능입니다. 즉, 업데이트 중에도 트래픽을 처리할 수 있게 해줍니다.
Deloyments에서 log 확인하려면 우측 점 3개 누르면 된다. dependency 잘 지켜지고 있는지, 오류는 없는지 확인하자
secrets에 pinecone api, hugging face api token 추가하고 redeploy 하자. ( api key 추가되었을때 추가 후 redeploy 하기)
pinecone namespace 이름으로 한국어가 불가능하다.
각 소설 이름으로된 한국어를 hashing하여 namespace를 만들고, BE에서 hash decode를 통해 처리해야겠다.
BE서버에서 티키타카 하는 과정이기 때문에 가장 빠른 해싱 방법을 사용하였다. (한국어 -> 16진수) 후보 1. MD5 2. SHA256
import hashlib
import time
# 샘플 파일 이름
filename = "시나리오.txt"
# MD5 해시 생성 함수
def generate_md5(filename):
return hashlib.md5(filename.encode('utf-8')).hexdigest()
# SHA256 해시 생성 함수
def generate_sha256(filename):
return hashlib.sha256(filename.encode('utf-8')).hexdigest()
# MD5 속도 측정
start_time_md5 = time.time()
for _ in range(1000000): # 백만 번 해시 생성 테스트
generate_md5(filename)
md5_duration = time.time() - start_time_md5
# SHA256 속도 측정
start_time_sha256 = time.time()
for _ in range(1000000): # 백만 번 해시 생성 테스트
generate_sha256(filename)
sha256_duration = time.time() - start_time_sha256
md5_duration, sha256_duration
(1.373901128768921, 1.4350826740264893)
100만번 TEST 결과 MD5가 미세하게 빠르므로 MD5를 사용하였다.
(보안 측면에서는 SHA256이 더 우세하지만, MVP를 위해 MD5를 채택하겠다.)
- llm_ops에 django BE 로부터 선택된 2부분을 받는 route 만든다.
- 이 루트에서는 프롬프팅을 통해 줄거리, 2부분에 해당하는 keyword를 만든다.
- 만들어진 keyword를 선택하면 keyword에 해당하는 보기를 생성한다. (10개 정도 ??)
HNSW 알고리즘을 활용하는 postgresql db와 pinecone을 비교해보자
우선, dbeaver에서 vector extension을 설치해줘야한다.CREATE EXTENSION vector;이제 Django backend 코드에서 vector db 테이블을 만들어 migrate하자.
현재 사용하고 있는 모델을 정확히 알아보자.
TF-IDF 도 한 번 공부해보자. (시에서 keywords 추출할 때 사용)
pgvector( + HNSW) VS pinecone 비교해보자
https://www.timescale.com/blog/pgvector-vs-pinecone/