🛣️ 지원 계획 & 로드맵
📌 Chunking Optimization AutoRAG 지원 계획 ?
현재 AutoRAG는 chunk된 Corpus 데이터셋이 준비 되어있어야만 사용할 수 있어 chunk-dependent합니다.
따라서 저희도 Chunking Optimization을 중요한 주제로 생각하고 있습니다.
지원 계획에는 있으나, 많은 고민과 연구가 필요한 주제인 만큼 정확한 지원 계획을 말씀드리긴 어려울 것 같습니다!
📌 실험에 예상 비용 알려주는 기능 지원 계획?
LLM을 사용하는 만큼 많은 분들이 실험을 돌리기 전에 어느 정도의 비용이 들어가는 지 궁금해 하시는데요,
물론 지원 계획에 있습니다 !
해당 이슈에서 지원할 예정입니다 :)
📌 다양한 벡터 DB 지원할 계획 있나요?
다양한 벡터 DB를 지원할 계획은 아직 없습니다.
벡터 DB의 성능은 충분히 상향 평준화가 되어있다고 판단했습니다.
현재 로컬에서 돌아가는 ChromaDB를 사용하고 있습니다.
AutoRAG에서는 데이터에 맞는 최적의 RAG pipeline을 찾아드리지만,
프로덕션 용으로 배포나 코드를 제공하지는 않기 때문에 현재로서는 다양한 벡터 DB를 지원할 계획이 없습니다 :)
💻 하드웨어 사양
📌 GPU 최소 사양?
AutoRAG를 완전히 이용하기 위해서는 CUDA gpu가 장착된 컴퓨터를 권장합니다.
구체적으로, gtx 1000번대 이상의 gpu를 권장드립니다.
LLM 역시 AutoRAG에서 구동하고 싶으실 경우, VRAM 20gb 이상의 rtx 3090 및 4090 급 gpu가 달린 시스템을 필요로 합니다.
- CUDA가 없는 경우 : 각종 리랭커 모듈의 구동이 힘들 수 있음. → OpenAI 등 api 모듈 사용 권장.
- gtx 1000번대 이상 gpu (CUDA) : 리랭커 모듈 구동 가능. LLM 로컬 구동 불가능.
- 3090 이상 : 모든 기능 구동 가능.
⭐AutoRAG 실행 관련
📌 OpenAI가 아닌 다른 LLM, Local LLM 사용하는 방법 (Yaml 구성하는 방법) ?
AutoRAG에서는 llama index에서 지원하는 모든 LLM을 사용하실 수 있습니다
1. vllm 모듈 사용하기
빠른 인퍼런스를 위해 vllm을 사용하시는 걸 추천드립니다 !
저희가 따로 병렬화가 가능하도록 개발해두어 llama_index_llm 모듈을 사용하시는 것보다 빠른 실험이 가능합니다 :)
- Docs: vllm
- Sample YAML
modules: -module_type: vllm llm: mistralai/Mistral-7B-Instruct-v0.2 temperature:[0.1, 1.0] max_tokens: 512
2. llama_index_llm 모듈 사용하기
- Docs: llama_index_llm supporting llm models
- Sample YAML
modules: - module_type: llama_index_llm llm: openailike model: mistralai/Mistral-7B-Instruct-v0.2 api_base: your_api_base api_key: your_api_key
❗ 3가지 LLM Model Type이 아닌 LLM(ex: ollama, groq) 사용하는 법
Ollama 사용해보기 튜토리얼
- Python에서 아래의 코드로 ollama를 추가해준다
import autorag
from llama_index.llms.ollama import Ollama
autorag.generator_models["ollama"] = Ollama- YAML파일 구성하기
nodes:
- node_line_name: node_line_1
nodes:
- node_type: generator
modules:
- module_type: llama_index_llm
llm: ollama
model: [llama3, qwen, mistral]추가 parameter는 직접 YAML 파일에 넣어 사용이 가능합니다
📌 최적의 pipeline으로 구성된 RAG 코드는 어디서 확인 가능한가요?
직접적인 코드가 Langchain이나 LlamaIndex 형태로 제공되지는 않습니다.
AutoRAG에서는 다음 2가지 기능을 제공하고 있습니다.
-
최적의 RAG 파이프라인 YAML 파일 추출이 가능합니다.
autorag extract_best_config --trial_path your/path/to/trial_folder --output_path your/path/to/pipeline.yaml -
최적의 pipeline의 RAG 답변은 CLI, API Server, Web Interface(Streamlit)에서 확인 가능합니다.
직접 프로덕션 용으로 구축하시려면, 최적의 방법론을 이용해 RAG 코드를 작성하시면 됩니다!
📌 Compact.yaml으로도 1-2시간씩 걸려요. 너무 오래걸리는 거 같은데 정상인가요?
CUDA 사용이 가능하신 환경이 아니면, compact를 사용하였을 때 Reranker에서 오랜 시간이 걸릴 수 있습니다.
그럴때는 simple_openai.yaml 파일부터 사용하시는 것을 추천드립니다!
📌 평가 중 끊어진 경우에 다시 시작하는 방법이 있나요?
평가가 중간에 끊어진 경우, 끊어진 곳부터 평가를 다시 돌릴 수 있는 restart_evaluate 기능이 준비되어 있습니다.
- Use at CLI
autorag restart_evaluate --trial_path your/path/to/trial_folder - Use Python Code
from autorag.evaluator import Evaluator evaluator = Evaluator(qa_data_path='your/path/to/qa.parquet', corpus_data_path='your/path/to/corpus.parquet') evaluator.restart_trial(tiral_path='your/path/to/trial_path')
→ Docs: Restart a trial if an error occurs during the trial
📌 한국어 말고 영어나 다른 언어도 동일한 방법으로 사용 가능한가요?
AutoRAG의 기본 값은 영어로 맞춰져 있습니다!
동일한 방법으로 사용이 가능하시긴 하지만, 프롬프트를 사용하는 특정 모듈을 사용하실 때는 한국어(혹은 다른 언어)에 맞는 프롬프트를 따로 입력해주셔야 더 좋은 결과를 얻으실 수 있습니다 !
📌 문서 내의 테이블 qa도 가능한가요?
문서 내의 테이블을 활용해서 QA를 하는 RAG 파이프라인을 구축하시려면,
먼저 테이블의 정보를 뽑아낼 수 있는 별도의 OCR이나 파서를 사용해 추출하셔야 합니다 :)
🤔 꿀팁/노하우
📌 적절한 qa데이터 셋의 갯수는 어떻게 생각하시나요?
약 100개 정도는 필요하다고 생각합니다.
경우에 따라서 RAG 질문의 다양성이 클 경우 그보다 훨씬 많은 데이터가 필요할 수도 있습니다.
📌 실험할 때 자주 사용하시는 LLM 정보가 궁금합니다.
저희 팀에서는 허락가능한 보안 범위내에서 SOTA 모델을 사용하고 있습니다.
지금은 GPT-4o를 주로 사용하고 있습니다.
프라이빗한 경우 QWEN72B 또는 라마3 70B 한글화 버전을 추천 드립니다!
📌 Chunk된 text를 바로 임베딩 하지 않고, text 앞단에 메타데이터(문서 제목 등)를 넣어서 임베딩을 하기도 하나요? 이렇게 하는게 retrieve 단계에서 유의미한 전처리인지 궁금합니다.
Chunk 이후의 text를 바로 Corpus의 Contents로 사용하지 않고,
(제목) + (요약 or 메타데이터) + (chunked text)로 구성해서 임베딩을 하기도 합니다.
Retrieval 성능을 높일 때 시도해보기 좋은 꿀팁이자 노하우입니다 : )
❗다만, 데이터마다 성능이 달라집니다. ❗
특정 데이터에서는 Retrieval 성능이 많이 올라 유의미한 전처리지만, 특정 데이터에서는 미미한 정도로만 오르거나 성능이 떨어지기도 합니다.
결국은 실험으로 데이터에 맞는 최적의 방법을 찾아야 합니다.
이런 실험을 쉽고 빠르게 하기위해 AutoRAG가 만들어 진 만큼 AutoRAG를 사용하셔서 빠른 실험 해보시는 걸 추천드립니다 😁
📌 특정 도메인의 전문적인 용어가 난무하는 문서에서 RAG 성능을 높이는 노하우를 공유해주세요!
특정 도메인의 전문적인 용어가 난무하는 상황일수록,
현실성 있게 만들어진 평가 qa 데이터셋을 구성하는 것이 중요합니다.
일반인들의 경우, 전문적인 용어를 잘 모르기 때문에 정확한 질문보다는 모호한 질문이 많습니다. 따라서 의미론적으로 비슷한 (Semantic Similarity가 높은) VectorDB를 사용한 Retrieval이 성능이 더 좋게 나올 수 있습니다.
반대로 전문가의 경우, 정확한 용어를 잘 알기 때문에 매칭 중심인 BM25가 더 성능이 좋게 나올 수 있습니다.
따라서 RAG를 실제로 사용하는 환경에서 일반인들이 더 많이 사용하는 지, 전문가들이 더 많이 사용하는 지를 고려하여 현실성 있게 만들어진 평가용 qa 데이터 셋을 잘 구성하는 것이 중요하고, 결국 모든 건 현실적 데이터 기반 실험에 의해 판단 되어야 합니다 !
📌 한국어 임베딩 검색 성능을 높이기 위한 노하우가 있을까요? (한국어 성능이 잘 나오지 않아 고민입니다)
내부 실험 결과, OpenAI 한국어 임베딩을 사용해서 Cosine Similarity를 찍어 봤을 때 전혀 다른 의미를 가진 단어도 cosine similarity가 0.7 이상이 나옵니다.
한국어가 되게 dense하게 몰려있고, 의미적으로 각각의 벡터를 구분하는 것이 쉽지 않은 현실입니다.
한국어 임베딩 모델의 문제이자 한계라고 볼 수 있는데요, 일단 한국어 임베딩 모델을 더 파인튜닝 하는 것이 가장 좋은 해결책이라고 보여집니다.
다만, 한국어 임베딩 모델을 파인튜닝하는 게 쉽지 않은 일이기 때문에, 차선책으로 BM25, 하이브리드 retrieval, 리랭커 등을 사용해 Retrieval 성능을 최대한 높여보는 걸 추천드립니다 !
