벤치 마크를 참조하십시오
사용 방법
- 적절한 패키지가 설치되어 있는지 확인하십시오. 다음이 설치되어 있는지 확인하십시오. sentence_transformers tqdm pandas pandas pandas pypdf2 torch asyncio 동시 qdrant_client pinecone pymilvus dotenv
- 지정된 경우 모든 PDF를 /data /또는 기타 디렉토리에 업로드하십시오.
- PDF 파일에 대한 자세한 내용은 메타 데이터 파일이있는 경우 홈 디렉토리에 업로드하고 이름 IT Metadata.csv를 업로드하거나 이름을 변경하십시오. 특정 메타 데이터 파일을 수용하기 위해 MacLoader의 get_metadata ()에서 코드를 변경해야 할 것입니다.
- .env의 입력 연결 세부 사항. .env의 모습은 .env-example을 참조하십시오.
- 코드에서 DB 초기화의 일부로 세부 사항을 입력하려면 피할 수 있습니다.
- 인덱스 파이썬 파일을 만듭니다. 여기에서 나는 적절한 로깅을 정의 할 것입니다. 모든 데이터를 사용하면 모든 문제를 찾는 것이 중요합니다. 모든 로깅은 정보, 경고, 오류 및 중요성을 사용하여 적절하게 명명되었습니다.
- delete.txt를 만들고 아무것도 넣지 마십시오.
- 프로젝트에서 적절한 파일을 가져 와서 적절한 세부 정보로 초기화하십시오. 사용 가능한 모든 매개 변수는 잘 문서화되어 있으며 호버링 또는 클릭을 통해 IDE에 의해 표시되어야합니다.
- 예 :
from Loader import MacLoader & from databases.PineconeDB import PineconeDB
- 파일을 실행 한 후 Delete.txt를 확인하고 PYPDF2 리더와 관련된 파일을 확인하십시오. 이 파일을 제거하려면 utility.delete_bad_pdfs ()를 사용하십시오.
- 이 과정을 개선하는 방법을 알려주세요!
주요 테이크 아웃
사전 처리
llama_index는 훌륭하지만 노드에 대한 신뢰성은 진정한 방해입니다. TextNodes는 매우 유용한 것처럼 보이지만 저장 및 성능을 차지하는 벡터와 함께 업로드 할 불필요한 데이터가 많이 제공됩니다. 이러한 이유로 인해 LLAMA_INDEX는 벡터 업로드 프로세스의 복잡한 데 사용되지 않습니다. 추가 데이터는 생산 규모 데이터 세트에있을 때 너무 많습니다. 또한 때로는 많은 이상한 규칙과 불필요한 단계로 코드를 작성하는 것이 얼마나 성가신지를 싫어합니다. TextNodes는 모든 것이 제대로 관리되면 귀중한 강력한 자산이 될 수 있으며, 모든 추가 데이터가 로컬로 저장되고 검색 속도 나 메모리를 방해하지 않습니다.
Langchain은 규칙이 적은 것으로 데이터를 더 쉽게 인터페이스하는 방법을 만듭니다 (컨텍스트에 따라 다름). 나는 Langchain이 생산 준비라고 생각하지 않으며 그립 테이프를 대신 사용해야한다고 생각하지 않습니다. 생산 환경에서도 전체 프로세스를 완전히 제어 할 수 있습니다.
전반적으로, 나는 원하는대로 쉽게 맞는 것을 찾을 수 없습니다. 이 과정이 어떻게 진행되어야한다고 생각하는지에 대한 나의 이해는 다음과 같습니다.
이 프로그램을 마치는 동안 나는 그것이 위의 두 도구를 대체하는 것임을 깨달았습니다. 위의 두 가지 도구는 모든 사용 사례에 적용하기위한 것이며, 방금 내 특정 사례를 코딩했습니다.
임베딩 / 변압기
문장 변압기를 따는 것은 그리 어렵지 않았습니다.
All-Minilm-V2는 좋고 빠르지 만 대량의 데이터로 확장성에 대해 걱정했습니다. 가장 정확하지는 않지만 여전히 좋은 것은 아닙니다.
E5-Large-V2는 테스트에서 소규모로 기본 데이터 검색에 실패했습니다. 이로 인해 나는 그것을 더 큰 규모로 고려하지 않을 것입니다.
강사 임베딩으로 모든 것이 더 오래 걸리지 만 데이터는 훨씬 더 나은 데이터를 제공 할 것입니다. 아직 제대로 테스트하지 않았습니다.
All-MPNET-V2는 속도와 성능 측면에서 최고이며 강사 임베드만큼 정확하지는 않지만 제작 환경에서 속도와 성능이 선호 될 수 있습니다.
Ada (OpenAi) 임베딩은 일반적인 로컬 문장 변압기보다 훨씬 비싸 질 것입니다. 과거에는 요금 제한 및 모델이 부과하는 기타 제한으로 인해 대규모 데이터 세트를 처리하는 데 문제가있었습니다. 청크로 데이터를 전송하면이 문제가 해결됩니다.
- ADA는 1536 차원에도 포함된다는 것을 고려하는 것이 중요합니다. 이로 인해 더 많은 차원에 필요한 추가 수학으로 인해 의미 론적 검색 시간이 높아집니다. 다시 이것은 정밀도로 이어질 것이지만, 다른 모델은 고가의 외부 API를 사용하지 않고도 높은 차원의 임베딩을 수행 할 수 있습니다.
- 로컬 문장 변압기의 사용이 제한적이거나 불편한 경우, 이것은 큰 대체품입니다.
최종 선택 : 결정되지 않았습니다. orruct 또는 mpnet을 선택하기 전에 먼저 사전 처리를 완료해야합니다.
벡터 데이터베이스
거부 된 데이터베이스
- 크로마
- 서버 배포 옵션이 부족합니다. 소규모 프로젝트의 경우 이것은 내가 생각하지만 항상 최선의 선택이 될 것입니다.
- pgvector
- 어떤 이유로 벤치 마크에서 매우 제대로 수행하지 못합니다. 그래도 실제 성능을 대표하지 않을 수 있습니다. 여기를 참조하십시오
- postresql 데이터베이스가 이미 사용 중이거나 주어진 데이터에 실용적이라면 PGVECTOR가 최상의 옵션이 될 것이라는 데는 의심의 여지가 없습니다. 그러나 PGVECTOR 라이브러리를 자체적으로 사용하거나 PostresQL로 전환하지 않습니다.
- 탄력 있는
- 직조
- 나는 이전에 이것을 평가할 계획 이었지만이 프로그램에서 이것을 구현하려고 시도하면서 다른 모든 것에 비해 훨씬 더 어려움이있었습니다.
- Python 클라이언트를위한 문서는 전혀 크지 않으며 어렵지는 않았지만 문서의 부족은 걱정됩니다.
- 내 유스 케이스는 관리되는 클라우드를 사용할 계획이며 WCS는 정말 걱정하게 만들었습니다. 보안이 많지 않은 것 같습니다. 2FA조차 없습니다. 나는 개인적으로 WCS를 신뢰하지 않으며 다른 데이터베이스에 비해 최악의 UI가있었습니다.
- Docker 컨테이너에 사용하려는 경우 Weaviate는 재고하고 공정한 샷을 주어야하지만 지금은 계속 평가하지 않습니다.
현재 조사 중입니다
전체 프로세스의 고려 사항
- PDF는 쓰레기가 너무 많고 대부분의 로더는 그것을 먹습니다. PDF의 텍스트를 벗기려면 특히 Langchain 또는 Llama_index의 독서 솔루션을 사용할 때 많은 쓰레기가 있습니다. 해당 프로세스를 제어하지 않으면 사용자 정의 디렉토리 PDF 로더를 만드는 것보다 어려워졌습니다.
- 나는 거의 모든 형식이 대량의 데이터를 읽는 데 PDF보다 우수하다고 생각합니다. 인코딩, 정크 캐릭터 및 읽을 수없는 PDF의 파멸 텍스트 및 파이프 라인에 관한 많은 문제가 있습니다.
- 텍스트 데이터는 필요한 경우 모든 벡터 데이터베이스에 저장할 수 있습니다. 이것은 스토리지 프로세스를 크게 단순화합니다. 많은 벡터 데이터베이스는이를 메타 데이터 형태로 허용하지만 문제가 될 수있는 별도의 텍스트 저장을 허용하지는 않습니다. 텍스트는 너무 크고 메모리에도 메모리에 저장되어 메모리에 저장되며 메타 데이터는 디스크에 저장 될 수 있지만 메타 데이터 필터링을 사용할 수 없습니다.
- 벡터 데이터베이스가이를 올바르게 처리하지 않으면 벡터 업로드 프로세스는 벡터와 ID 만 업로드하여 단순화 될 수 있습니다. 시맨틱 검색이 수행되면 관련 ID에서 로컬 또는 NOSQL 데이터베이스를 검색하십시오.
