영업팀에 문의

네. Jina는 모델 브랜드로 전환하고 있습니다. 알리바바의 Qwen, OpenAI의 GPT, 문샷의 Kimi와 같은 관계라고 생각하시면 됩니다. 회사의 법적 정체성을 "Jina AI"에서 Elastic으로 점진적으로 이전하여, Jina AI가 브랜드로서 search foundation 모델에만 집중할 수 있도록 할 계획입니다.

더 나은 검색을 위한 임베딩, 리랭커, 그리고 소규모 언어 모델입니다. 우리의 미션은 아직 완수되지 않았습니다. 우리는 선도적인 검색 모델 제공업체가 되겠다는 목표를 한 번도 숨긴 적이 없습니다.

네. Reader API, Embedding API, 그리고 Reranker API는 계속해서 개발 및 유지 관리될 예정입니다. 출시하는 모든 모델은 클라우드 마켓플레이스 플랫폼에도 게시됩니다. 기존처럼 API 서비스를 계속 이용하실 수 있습니다. 유일한 예외는 미국 수출 통제 대상 국가 또는 단체에는 서비스를 제공할 수 없다는 점입니다.

네. Elastic에서도 Jina는 search foundation 모델의 한계를 계속 넓혀갈 것이며, 오픈 웨이트 모델도 계속 출시할 예정입니다.

상황이 바뀌지 않는 한 (그럴 가능성은 낮지만), 저희는 앞으로도 CC-BY-NC 4.0 라이선스에 따라 저희의 저작물을 배포할 것입니다.

네. 저희가 출시하는 모든 모델은 엄격한 연구 논문을 통해 뒷받침되며, ICLR, EMNLP, SIGIR, NeurIPS, ICML과 같은 주요 학회에 지속적으로 논문을 제출할 예정입니다.

이전과 마찬가지로 저희 웹사이트 또는 해당 클라우드 마켓플레이스를 통해 간단히 등록하고 결제하시면 됩니다.

현재 저희 제품은 Elastic의 제품 라이브러리(SKU)에 아직 포함되어 있지 않으므로, 해당 서비스를 이용하시려면 저희 웹사이트를 통해 결제하셔야 합니다. 조만간 Jina 모델은 Elastic Inference Services를 통해 제공될 예정입니다.

Elastic 영업 담당자 또는 현장 영업 엔지니어에게 문의하십시오. 그들이 당사와 협력하여 귀하의 Elastic 라이선스가 사내 상업용 사용을 포함하는지 여부를 확인해 드릴 것입니다.

현재 Elastic과의 통합 작업을 진행 중이며, 향후 방향이 곧 명확해질 것입니다. 현재로서는 저희 모델에 대한 개별 상업용 라이선스를 발급할 수 없습니다.

당사는 중국 법인이 없으므로 중국 세금계산서(发票)를 발행할 수 없습니다. 송장은 독일 본사인 Jina AI GmbH에서 발행합니다.

Jina AI의 비즈니스 모델에서 계약 기반 방식은 항상 작은 부분에 불과했습니다. 대부분의 고객은 사용량에 따라 지불하는 셀프 서비스 모델을 이용하고 있습니다. 현재 Elastic과의 통합 작업을 진행 중이지만, 새로운 계약은 발행하지 않습니다.

해당 사안에 대해 논의하기 위해 귀하와 Jina AI 팀, 그리고 Elastic 간의 미팅을 주선할 수 있도록 Elastic 영업 담당자에게 문의해 주십시오.

리더 API의 기본 기능은 무료입니다. URL 앞에 "https://r.jina.ai/"를 추가하기만 하면 됩니다. 더 높은 사용량 제한이 필요한 경우 API 키를 제공할 수 있으며, 콘텐츠 길이에 따라 요금이 부과됩니다. 사용량 제한에 대한 자세한 내용은 질문 16을 참조하세요.

Reader API는 프록시를 사용하여 모든 URL을 가져오고 브라우저에서 해당 콘텐츠를 렌더링하여 고품질 기본 콘텐츠를 추출합니다.

Reader API 코드는 Jina AI의 GitHub 저장소에서 찾을 수 있습니다. ReaderLM-v2 모델은 오픈 소스 라이선스가 아닌 CC-BY-NC 4.0 비상업적 라이선스에 따라 배포된다는 점에 유의하십시오.

Reader API는 일반적으로 URL을 처리하고 2초 이내에 콘텐츠를 반환하지만 복잡하거나 동적 페이지는 시간이 더 걸릴 수 있습니다.

스크래핑은 복잡하고 신뢰하기 어려울 수 있으며, 특히 복잡하거나 동적인 페이지의 경우 더욱 그렇습니다. Reader API는 깔끔하고 LLM에 바로 쓸 수 있는 텍스트를 간결하고 안정적으로 출력해 줍니다.

Reader API는 URL의 내용을 원래 언어로 반환합니다. 번역 서비스를 제공하지 않습니다.

네. Reader는 표준 웹 클라이언트처럼 작동하며 웹사이트의 접근 제어 정책을 준수합니다. 웹사이트에서 요청을 차단하는 경우, Reader는 해당 결정을 따릅니다. 사용자는 Reader를 사용할 때 방문하는 웹사이트의 이용 약관을 준수하고 제3자의 지적 재산권을 침해하지 않도록 할 책임이 있습니다.

네, Reader API는 기본적으로 PDF 파일에서 콘텐츠를 추출할 수 있습니다.

네, Reader는 x-with-generated-alt 헤더를 사용하여 웹페이지의 이미지에 캡션을 붙일 수 있습니다. 이를 통해 alt 태그가 없는 이미지에 설명 alt 태그가 추가되어 LLM이 시각적 콘텐츠를 이해할 수 있습니다. 동영상 요약 기능은 향후 릴리스에서 제공될 예정입니다.

아니요, Reader API는 공개적으로 액세스 가능한 URL의 콘텐츠만 처리할 수 있습니다.

5분 이내에 동일한 URL을 요청하면 Reader API가 캐시된 콘텐츠를 반환합니다.

안타깝지만 불가능합니다.

예, Reader의 기본 PDF 지원을 사용하거나(https://r.jina.ai/https://arxiv.org/pdf/2310.19923v4) arXiv의 HTML 버전을 사용할 수 있습니다(https://r.jina.ai/https://arxiv.org/html/2310.19923v4)

Reader는 지정된 URL의 모든 이미지에 캡션을 생성하고, 원래 alt 태그가 없는 경우 `Image [idx]: [caption]`을 alt 태그로 추가합니다. 이를 통해 다운스트림 LLM이 추론, 요약 등에서 이미지를 활용할 수 있습니다.

Reader API는 확장성이 뛰어나도록 설계되었습니다. 실시간 트래픽에 따라 자동으로 확장되며, 최대 동시 요청 수는 현재 약 4,000개입니다. Jina AI의 핵심 제품 중 하나로 적극적으로 유지 관리하고 있으니 프로덕션에서 마음껏 사용하세요.

아래 표에서 최신 속도 제한 정보를 확인하세요. 우리는 Reader API의 속도 제한과 성능을 개선하기 위해 적극적으로 노력하고 있으므로 이에 따라 이 표도 업데이트될 예정입니다.

ReaderLM-v2는 원시 HTML을 깔끔한 markdown 또는 JSON으로 변환하는 최신 소형 언어 모델(SLM)입니다. v1 대비 3배 향상된 품질을 제공하며 JSON 스키마 또는 자연어 지시문을 사용해 구조화된 데이터를 추출할 수 있습니다. x-respond-with: readerlm-v2 헤더로 Reader API를 통해 바로 사용하거나, 클라우드 마켓플레이스(AWS, Azure, GCP)에서 배포할 수 있습니다.

JSON 스키마 정의와 함께 x-json-schema 헤더를 사용하거나, 자연어 지시문과 함께 x-instruction 헤더를 사용하십시오. 두 기능 모두 ReaderLM-v2와 함께 작동하여 어떤 웹페이지에서든 가격, 제목, 날짜 등 특정 필드를 구조화된 JSON 형식으로 추출합니다.

아니요. Reader는 웹사이트의 방어 체계, 봇 방지 시스템 또는 접근 제어를 적극적으로 우회하거나 무력화하지 않습니다. 웹사이트에서 당사 서비스를 봇으로 감지하여 요청을 차단하는 경우, 당사는 해당 결과를 존중합니다. 당사는 표준 웹 클라이언트로 작동하며 탐지 시스템을 우회하도록 설계된 어떠한 기술도 사용하지 않습니다. Reader를 사용하는 동안 제3자의 지적 재산권 및 방문하는 웹사이트의 이용 약관을 준수하는 것은 여전히 ​​사용자 본인의 책임입니다.

아니요. 무료 API 키에서 유료 API 키로 업그레이드한다고 해서 다른 웹사이트에 접속할 수 있거나 웹사이트 접속 제한을 우회할 수 있는 것은 아닙니다. 두 등급의 주요 차이점은 요청 처리량 제한과 성능 최적화입니다. 유료 API 키는 더 높은 요청 처리량과 더 빠른 처리 속도를 제공하지만, 당사 서비스를 차단한 웹사이트에 접속할 수 있도록 허용하지는 않습니다.

훈련 과정, 데이터 소스 및 평가에 대한 자세한 내용은 arXiv에 게시된 기술 보고서 ​​jina-embeddings-v3 및 jina-embeddings-v4를 참조하십시오.

jina-embeddings-v4는 텍스트와 이미지를 모두 지원하는 최신 범용 멀티모달 모델(38억 개의 파라미터)로, 32K 컨텍스트, 밀집(dense) 및 지연 상호작용(late-interaction) 검색을 지원하고 시각적으로 풍부한 문서에서 SOTA 성능을 달성합니다. jina-clip-v2는 89개 언어를 지원하고 512x512 이미지 해상도와 Matryoshka 표현을 사용하는 더 가벼운 옵션(8억 6,500만 개의 파라미터)입니다. 두 모델 모두 텍스트-텍스트, 텍스트-이미지 및 이미지-이미지 검색 작업에서 탁월한 성능을 보여줍니다.

jina-embeddings-v4와 jina-embeddings-v3 모두 89개 언어를 지원하며 강력한 다국어 성능을 자랑합니다. 상위 30개 언어에는 아랍어, 벵골어, 중국어, 덴마크어, 네덜란드어, 영어, 핀란드어, 프랑스어, 조지아어, 독일어, 그리스어, 힌디어, 인도네시아어, 이탈리아어, 일본어, 한국어, 라트비아어, 노르웨이어, 폴란드어, 포르투갈어, 루마니아어, 러시아어, 슬로바키아어, 스페인어, 스웨덴어, 태국어, 터키어, 우크라이나어, 우르두어, 베트남어가 포함됩니다. jina-clip-v2 또한 멀티모달 작업에서 89개 언어를 지원합니다.

컨텍스트 길이는 모델에 따라 다릅니다. jina-embeddings-v4는 최대 32K 토큰을 지원하는 반면, jina-embeddings-v3와 jina-clip-v2는 최대 8192 토큰을 지원합니다. 토큰은 단일 문자에서 하나의 완전한 단어까지 다양할 수 있습니다. 이러한 확장된 컨텍스트를 통해 대량의 텍스트 데이터에 대한 포괄적인 문서 분석이 가능해지고 컨텍스트 이해의 정확도가 향상됩니다.

요청에 포함할 수 있는 항목 수에는 엄격한 제한이 없습니다. API는 GPU 활용도를 최적화하기 위해 토큰 수를 기준으로 입력을 내부적으로 일괄 처리합니다. 따라서 단일 요청에 원하는 만큼의 텍스트나 이미지를 보낼 수 있습니다.

jina-embeddings-v4, jina-clip-v2, jina-clip-v1의 경우, API 요청의 input 필드에 url 또는 bytes를 사용할 수 있습니다. url에는 처리할 이미지의 URL을 제공하고, bytes에는 이미지를 base64 형식으로 인코딩합니다. jina-embeddings-v4는 PDF URL 또는 base64로 인코딩된 PDF 바이트를 전달하여 PDF 문서를 직접 임베딩할 수도 있습니다.

jina-embeddings-v4는 시각적으로 풍부한 문서 검색(ViDoRe) 및 멀티모달 벤치마크에서 SOTA 성능을 달성한 최신 플래그십 모델입니다. 텍스트 전용 작업의 경우, jina-embeddings-v3는 MTEB 영어 및 다국어 벤치마크에서 OpenAI 및 Cohere보다 우수한 성능을 보이면서도 더 작고 효율적입니다. 두 모델 모두 Matryoshka 표현 학습(MRL)을 지원하여 큰 성능 저하 없이 차원 축소가 가능합니다(v3는 32까지, v4는 128까지).

당사의 API 엔드포인트가 OpenAI text-embedding-3-large 모델의 입력 및 출력 JSON 스키마와 일치하므로 마이그레이션 과정이 간소화되어 있습니다. 이러한 호환성 덕분에 사용자는 OpenAI 엔드포인트를 사용할 때 OpenAI 모델을 당사 모델로 쉽게 교체할 수 있습니다.

토큰은 텍스트 길이와 이미지 크기를 기반으로 계산됩니다. 요청의 텍스트에 대해서는 토큰이 표준 방식으로 계산됩니다. 이미지에 대해서는 다음 단계를 수행합니다. 1. 타일 크기: 각 이미지는 타일로 나뉩니다. jina-embeddings-v4의 경우 타일 크기는 28x28픽셀이고, jina-clip-v2의 경우 타일 크기는 512x512픽셀이며, jina-clip-v1의 경우 타일 크기는 224x224픽셀입니다. 2. 적용 범위: 입력 이미지를 덮는 데 필요한 타일 수를 계산합니다. 이미지 크기가 타일 크기로 정확히 나누어 떨어지지 않더라도 일부 타일은 전체 타일로 계산됩니다. 3. 총 타일 수: 이미지를 덮는 총 타일 수에 따라 비용이 결정됩니다. 예를 들어, 600x600 픽셀 이미지는 jina-embeddings-v4에서는 22x22 타일(484개), jina-clip-v2에서는 2x2 타일(4개), jina-clip-v1에서는 3x3 타일(9개)로 구성됩니다. 4. 비용 계산: jina-embeddings-v4의 경우 타일당 10개 토큰, jina-clip-v2의 경우 타일당 4000개 토큰, jina-clip-v1의 경우 타일당 1000개 토큰입니다. 예: 600x600 픽셀 이미지의 경우: • jina-embeddings-v4 사용 • 이미지는 28x28 픽셀 타일로 분할됩니다. • 필요한 총 타일 개수는 가로 22개 x 세로 22개 = 484개입니다. • jina-embeddings-v4의 비용은 484*10 = 4840개 토큰입니다. • jina-clip-v2 사용 • 이미지는 512x512픽셀 타일로 분할됩니다. • 필요한 총 타일 개수는 가로 2개 x 세로 2개 = 4개 타일입니다. • jina-clip-v2의 비용은 4*4000 = 16000개 토큰입니다. • jina-clip-v1 사용 • 이미지는 224x224픽셀 타일로 분할됩니다. • 필요한 총 타일 개수는 가로 3개 x 세로 3개 = 9개 타일입니다. • jina-clip-v1의 비용은 9*1000 = 9000 토큰입니다.

네, jina-embeddings-v4, jina-clip-v2, jina-clip-v1은 이미지와 텍스트를 모두 임베딩할 수 있습니다. 더 많은 모달리티를 지원하는 임베딩 모델이 곧 발표될 예정입니다!

특정 데이터로 모델을 미세 조정하는 방법에 대한 질문이 있는 경우 당사에 문의하여 요구 사항을 논의하세요. 우리는 귀하의 요구 사항에 맞게 모델을 어떻게 조정할 수 있는지 알아보고 싶습니다.

예. AWS, Azure 및 GCP 마켓플레이스에서 당사 서비스를 사용할 수 있습니다. 특정 요구 사항이 있는 경우 jina.ai 영업 담당자에게 문의하세요.

jina-embeddings-v3와 jina-embeddings-v4의 task 매개변수는 최적의 성능을 위해 작업별 LoRA 어댑터를 활성화합니다. 검색 쿼리에는 retrieval.query, 검색 대상 문서에는 retrieval.passage, 의미 유사도에는 text-matching, 텍스트 분류에는 classification, 클러스터링 작업에는 separation을 사용하세요.

jina-embeddings-v4는 output_type 매개변수를 통해 밀집(단일 벡터) 검색과 지연 상호작용(다중 벡터) 검색을 모두 지원합니다. 지연 상호작용은 토큰 수준의 세밀한 정보를 더 많이 보존하여 복잡한 쿼리에서 검색 정확도를 높입니다. jina-colbert-v2는 지연 상호작용 전용 모델입니다.

지연 청킹(late chunking)은 먼저 긴 컨텍스트 모델을 사용하여 전체 문서를 임베딩한 다음, 토큰 수준 표현에서 청크 임베딩을 추출하는 기술입니다. 단순 청킹(먼저 청킹한 후 임베딩)과 달리, 지연 청킹은 청크 간 컨텍스트를 보존하여 RAG 애플리케이션의 검색 성능을 향상시킵니다. jina-embeddings-v3의 late_chunking 매개변수를 통해 활성화할 수 있습니다.

일부 임베딩 모델은 아키텍처적으로 더 긴 컨텍스트 길이를 처리할 수 있지만, 추론 인프라의 GPU 메모리 제약으로 인해 API에서 더 낮은 제한을 적용할 수 있습니다. 매우 긴 시퀀스를 처리하려면 상당한 메모리가 필요하며, 대부분의 사용 사례에 대해 처리량, 지연 시간 및 비용의 균형을 맞추도록 서비스 구성을 최적화했습니다. 더 긴 컨텍스트 길이에 대한 지원이 필요한 경우, 당사 영업팀에 문의하여 맞춤형 배포 솔루션을 논의하십시오.

jina-embeddings-v4는 Qwen Research License에 따라 배포되는 Qwen2-VL 기본 모델을 기반으로 구축되었습니다. 이 라이선스는 연구 및 비상업적 용도로만 사용 가능하므로 jina-embeddings-v4를 상업용 제품으로 제공할 수 없습니다. 따라서 이 모델은 API를 통해 무료로 제공됩니다. jina-embeddings-v4가 다른 모델보다 느려 보일 수 있는 이유는 두 가지입니다. 첫째, jina-embeddings-v4는 jina-embeddings-v3보다 훨씬 큰 모델이므로 본질적으로 요청당 더 많은 계산 시간이 필요합니다. 둘째, 이 모델을 상용화할 수 없기 때문에 인프라 비용을 관리하기 위해 API 처리량을 의도적으로 제한하고 있습니다. 따라서 jina-embeddings-v4 API를 사용할 때 대용량 처리나 프로덕션 수준의 처리량을 기대해서는 안 됩니다. 더 높은 처리량이 필요한 프로덕션 워크로드의 경우 jina-embeddings-v3을 사용하거나 Hugging Face를 통해 자체 인프라에 jina-embeddings-v4를 배포하는 것을 권장합니다.

API 키 유형에 따라 요청 제한이 다릅니다.

무료 버전: 100 RPM, 10만 TPM, 동시 요청 2개
유료 버전: 500 RPM, 200만 TPM, 동시 요청 50개
프리미엄 버전: 5,000 RPM, 5천만 TPM, 동시 요청 500개

또한, 악용을 방지하기 위해 IP 주소 기반 요청 제한도 적용되며, 60초당 최대 1만 건의 요청으로 제한됩니다. 더 높은 제한이 필요한 경우 영업팀에 문의하십시오.

각 모델에는 입력마다 최대 컨텍스트 길이 제한이 있습니다.

jina-embeddings-v4: 32,768 토큰
jina-embeddings-v3: 8,192 토큰
jina-embeddings-v2-*: 8,192 토큰
jina-clip-v1/v2: 8,192 토큰
jina-colbert-v1/v2: 8,192 토큰
jina-code-embeddings-*: 32,768 토큰

truncate: true가 설정되지 않은 경우, 제한을 초과하는 입력은 오류를 반환합니다. 이 값을 설정하면 입력이 자동으로 최대 길이로 잘립니다.

최대 파일 크기는 다음과 같습니다. 이미지: 5MB, PDF: 8MB. 이 제한을 초과하는 파일은 거부되고 오류 메시지가 표시됩니다.

Reranker API의 가격은 Embedding API의 가격 구조와 일치합니다. 새로운 API 키 하나당 1,000만 개의 무료 토큰이 제공됩니다. 무료 토큰 외에도 다양한 패키지를 구매할 수 있습니다. 자세한 내용은 가격 섹션을 방문하세요.

jina-reranker-v3는 최신 플래그십 리랭커로, 새로운 리스트와이즈 아키텍처를 통해 131K 컨텍스트 길이로 SOTA 다국어 검색 성능을 제공합니다. jina-reranker-m0는 여러 언어의 시각적 문서 순위를 매기는 멀티모달 리랭커입니다. jina-reranker-v2-base-multilingual은 100개 이상의 언어를 지원하는 크로스 인코더로, 함수 호출 및 코드 검색을 지원합니다. jina-colbert-v2는 레이트 인터랙션(late interaction)을 사용하여 89개 언어를 지원하며 사용자가 임베딩 크기를 제어할 수 있습니다.

저희의 모든 리랭커(jina-reranker-v3, jina-reranker-m0, jina-reranker-v2-base-multilingual, jina-colbert-v2)는 CC-BY-NC 4.0 라이선스로 배포됩니다. 비상업적 목적으로 이러한 모델을 자유롭게 사용, 공유 및 수정할 수 있습니다. 상업적 용도로 사용하시려면 저희에게 문의해 주십시오.

네, 저희의 모든 리랭커는 다국어 검색을 지원합니다. jina-reranker-v3와 jina-reranker-v2-base-multilingual은 100개 이상의 언어를 지원합니다. jina-reranker-m0은 다국어 시각적 문서 순위 지정을 지원합니다. jina-colbert-v2는 89개 언어를 지원합니다.

컨텍스트 길이는 모델에 따라 다릅니다.

jina-reranker-v3: 131,072 토큰(쿼리 + 모든 문서 합계), 자동 잘림 활성화
jina-reranker-m0: 10,000 토큰
jina-reranker-v2-base-multilingual: 1,024 토큰, 긴 문서에 대한 자동 청킹 활성화
jina-reranker-v1-*: 1,024 토큰, 자동 청킹 활성화
jina-colbert-v2: 8,192 토큰

v1/v2 리랭커의 경우 쿼리는 자동으로 잘리고, 긴 문서는 청크로 나뉘며, 청크 간에는 최대 풀링이 수행됩니다.

요청당 문서 수에는 엄격한 제한이 없습니다. 임베딩 API와 마찬가지로, 리랭커 API는 GPU 활용도를 최적화하기 위해 토큰 수를 기준으로 입력을 일괄 처리합니다. 따라서 단일 요청에 필요한 만큼의 문서를 전송할 수 있습니다.

지연 시간은 문서와 쿼리의 길이에 따라 크게 달라지며 100밀리초에서 7초까지입니다. 예를 들어 64 토큰 쿼리로 각각 256 토큰인 문서 100개를 리랭킹하는 데 약 150밀리초가 걸립니다. 문서 길이를 4096 토큰으로 늘리면 시간이 3.5초로 늘어납니다. 쿼리 길이를 512 토큰으로 늘리면 시간은 7초까지 더 늘어납니다.

예. AWS, Azure 및 GCP 마켓플레이스에서 당사 서비스를 사용할 수 있습니다. 특정 요구사항이 있는 경우 sales AT jina.ai 로 문의해 주세요.

특정 도메인 데이터에 맞춰 미세 조정된 리랭커에 관심이 있으시면 영업팀에 문의해 주세요. 저희 팀이 문의에 신속하게 답변해 드리겠습니다.

jina-reranker-m0 모델이 허용하는 최소 이미지 크기는 28x28픽셀입니다.

jina-reranker-v3는 모든 문서를 한 번의 순방향 패스로 함께 평가하는 새로운 리스트와이즈 아키텍처를 사용하여 문서 간 비교를 가능하게 합니다. 기존의 포인트와이즈 리랭커(예: v2)는 쿼리에 대해 각 문서에 독립적으로 점수를 매깁니다. 리스트와이즈 리랭킹은 전체 후보 집합에서 상대적 관련성을 파악함으로써 더 높은 정확도를 달성합니다.

일부 리랭커 모델은 아키텍처상 더 긴 컨텍스트 길이를 처리할 수 있지만, 추론 인프라의 GPU VRAM 제약으로 인해 API에서 더 낮은 제한을 적용할 수 있습니다. 매우 긴 시퀀스를 처리하려면 상당한 메모리가 필요하며, 대부분의 사용 사례에 대해 처리량, 지연 시간 및 비용의 균형을 맞추도록 서비스 구성을 최적화했습니다. 더 긴 컨텍스트 길이 지원이 필요한 경우, 전용 배포 옵션을 논의할 수 있도록 영업팀에 문의해 주십시오.

API 키 유형에 따라 요청 제한이 다릅니다.

무료 버전: 100 RPM, 10만 TPM, 동시 요청 2개
유료 버전: 500 RPM, 200만 TPM, 동시 요청 50개
프리미엄 버전: 5,000 RPM, 5천만 TPM, 동시 요청 500개

또한, IP 기반 요청 제한으로 60초당 1만 건의 요청이 적용됩니다. 이러한 요청 제한은 임베딩 API와 리랭커 API에도 적용됩니다.

예. Jina AI의 모든 검색 기반 제품에 동일한 API 키가 작동합니다. 여기에는 모든 서비스 간에 토큰이 공유되는 Reader, Embedding, Reranker, Classifier 및 Fine-Tune Model API가 포함됩니다.

예, 키 및 청구 탭에 API 키를 입력하면 최근 토큰 사용량과 남은 토큰 잔액을 볼 수 있습니다. API 키 제어판에 로그인한 경우 API 키 관리 탭에서도 이러한 세부정보를 볼 수 있습니다.

재충전 키를 분실하여 되찾고 싶으신 경우 등록된 이메일을 사용하여 jina.ai 지원팀에 문의해 도움을 받으세요. API Key의 안전한 보관과 손쉬운 접근을 위해 로그인을 권장합니다.

아니요, API 키에는 만료일이 없습니다. 그러나 키가 손상되었다고 의심되어 이를 비활성화하려는 경우 지원 팀에 문의하여 도움을 받으십시오. API 키 제어판에서 키를 자체 폐기할 수도 있습니다.

예, 프리미엄 키에서 다른 키로 토큰을 이전할 수 있습니다. API 키 관리 대시보드에서 계정에 로그인한 후, 이전하려는 키의 설정에서 남아 있는 모든 유료 토큰을 이동하세요.

예. API 키가 손상되었다고 생각되면 파기할 수 있습니다. 키를 파기하면 이를 저장한 모든 사용자에 대해 키가 즉시 비활성화되며, 남아 있는 모든 토큰 잔액 및 관련 자산은 영구적으로 사용할 수 없게 됩니다. 프리미엄 키가 있는 경우, 소각하기 전에 남은 유료 토큰 잔액을 다른 키로 이전하도록 선택할 수 있습니다. 이 작업은 취소할 수 없습니다. 키를 파기하려면 API 키 대시보드의 키 설정으로 이동하세요.

이는 서버리스 아키텍처가 사용량이 낮을 때 특정 모델을 오프로드하기 때문입니다. 초기 요청은 모델을 활성화하거나 "준비"하는데 몇 초 정도 걸릴 수 있습니다. 초기 활성화 후 후속 요청은 훨씬 빠르게 처리됩니다.

아니요. 저희는 귀하의 API 요청, 입력 또는 출력을 임베딩, 리랭커 또는 기타 모델을 학습시키는 데 사용하지 않습니다. 귀하의 데이터는 귀하의 것입니다.

각 API 키에는 다음과 같은 요청 제한이 적용됩니다.

무료: 100 RPM, 100K TPM, 동시 요청 2개
유료: 500 RPM, 2M TPM, 동시 요청 50개
프리미엄: 5,000 RPM, 50M TPM, 동시 요청 500개

또한 60초당 10,000건의 IP 기반 요청 제한도 적용됩니다. 이러한 제한은 모든 Jina API(Embeddings, Reranker, Reader 등)에 적용됩니다.

Embeddings API와 Reranker API 모두 배치 크기 제한이 없습니다. 필요에 따라 요청당 원하는 만큼의 항목이나 문서를 전송할 수 있습니다. 두 API 모두 최적의 GPU 활용을 위해 토큰 수를 기준으로 입력을 내부적으로 배치 처리합니다.

우리의 가격 모델은 처리된 총 토큰 수를 기반으로 하므로 사용자는 이러한 토큰을 원하는 수의 문장에 유연하게 할당할 수 있으며 다양한 텍스트 분석 요구에 맞는 비용 효율적인 솔루션을 제공합니다.

저희는 신규 사용자를 대상으로 무료 체험판을 제공하는데, 여기에는 모든 모델에서 사용할 수 있는 1,000만 개의 토큰이 포함되어 있으며, 자동 생성된 API 키를 통해 교환할 수 있습니다. 무료 토큰을 모두 사용하면 사용자는 "토큰 구매" 탭을 통해 API 키와 함께 사용할 추가 토큰을 쉽게 구매할 수 있습니다.

아니요, 실패한 요청에 대해서는 토큰이 차감되지 않습니다.

결제는 Stripe을 통해 처리되며 귀하의 편의를 위해 신용 카드, Google Pay, PayPal을 포함한 다양한 결제 방법을 지원합니다.

예, 토큰을 구매한 후 Stripe 계정과 연결된 이메일 주소로 청구서가 전송됩니다.

DeepSearch는 쿼리에 대한 정확한 답을 찾거나 토큰 예산 한도에 도달할 때까지 반복적인 검색, 읽기, 추론을 수행하는 LLM API입니다.

OpenAI와 Gemini와는 달리 DeepSearch는 긴 기사를 생성하는 것보다 반복 작업을 통해 정확한 답변을 제공하는 데 중점을 둡니다. 이 기능은 포괄적인 보고서를 만드는 것이 아니라, 심층적인 웹 검색에서 빠르고 정확한 답변을 제공하는 데 최적화되어 있습니다.

Jina API 키가 필요합니다. 새로운 API 키에 대해 1,000만 개의 무료 토큰을 제공합니다.

단순히 포기하거나 불완전한 답변을 반환하는 것이 아니라, 축적된 모든 지식을 토대로 최종 답변을 생성합니다.

아니요. 정확도를 높이기 위해 반복적인 검색 프로세스를 사용하지만, 평가 결과 테스트 문제에서 75%의 통과율을 달성하는 것으로 나타났습니다. 이는 0% 기준선(gemini-2.0-flash)보다 상당히 높지만 완벽하지는 않습니다.

단계 수는 매우 다양합니다. 평가 데이터에 따르면 쿼리는 1~42단계로 구성될 수 있으며 평균적으로 4단계가 소요됩니다. 20초입니다. 간단한 질문은 빠르게 해결될 수 있지만, 복잡한 연구 질문은 여러 번 반복해야 하며 최대 120초가 걸릴 수 있습니다.

네, deepsearch.jina.ai/v1/chat/completions의 공식 DeepSearch API는 모델 이름으로 'jina-deepsearch-v1'을 사용하여 OpenAI API 스키마와 완벽하게 호환됩니다. 따라서 OpenAI에서 DeepSearch로 전환하여 로컬 클라이언트나 OpenAI 호환 클라이언트와 함께 사용하는 것이 매우 쉽습니다. 원활한 경험을 위해 Chatwise를 적극 추천합니다.

속도 제한은 API 키 계층에 따라 다르며 10RPM에서 30RPM까지입니다. 이는 쿼리가 많은 애플리케이션에 중요합니다.

DeepSearch는 사고 단계를 XML 태그 ...로 감싼 뒤 최종 답변을 제공하며, OpenAI 스트리밍 형식을 따르되 생각의 사슬을 나타내는 이러한 특수 마커를 사용합니다.

네. Jina Reader가 웹 검색 및 읽기에 사용되며, 시스템이 웹 콘텐츠에 효율적으로 접근하고 처리할 수 있게 해 줍니다.

네, 복잡한 쿼리에서 DeepSearch의 토큰 사용량은 평균 70,000 토큰으로, 기본 LLM 응답의 500 토큰과 비교했을 때 상당히 높습니다. 이는 연구의 심도를 보여주지만, 비용에도 영향을 미칩니다.

이 시스템은 단계 수보다는 주로 토큰 예산에 의해 제어됩니다. 토큰 예산을 초과하면 시스템은 최종 답변을 생성하기 위해 Beast 모드로 전환됩니다. 자세한 내용은 reasoning_effort를 참조하세요.

참고문헌은 매우 중요하며, 답변이 명확한 것으로 간주되지만 참고문헌이 부족한 경우 시스템은 답변을 수락하지 않고 검색을 계속합니다.

네, 하지만 많은 조사가 필요합니다. "2028년 대통령은 누구일까"라는 사례는 여러 차례의 연구 반복을 통해 추측적 의문을 처리하는 것이 가능함을 보여주지만, 이러한 예측의 정확성을 보장할 수는 없습니다.

제로샷은 분류 시점에 의미론적 레이블이 필요하고 학습 시에는 필요하지 않은 반면, 퓨샷은 학습 시에 레이블이 필요하고 분류 시에는 필요하지 않습니다. 따라서 제로샷은 유연하고 즉각적인 분류 요구에 더 적합하고, 퓨샷은 시간이 지남에 따라 변화할 수 있는 고정된 도메인 특화 카테고리에 더 적합합니다.

num_iters는 훈련 강도를 제어합니다. 값이 높을수록 중요한 예가 강조되고 값이 낮을수록 신뢰성이 떨어지는 데이터의 영향이 최소화됩니다. 최근 예제에 더 많은 반복 횟수를 제공하여 시간 인식 학습을 달성하는 데 사용할 수 있으므로 데이터 패턴을 발전시키는 데 유용합니다.

classifier_id를 가진 사람은 누구나 공개 분류기를 사용할 수 있으며, 자신의 토큰 할당량이 소비됩니다. 사용자는 학습 데이터나 구성에 접근할 수 없고 다른 사람의 분류 요청도 볼 수 없어 안전하게 분류기를 공유할 수 있습니다.

퓨샷이 제로샷 분류를 능가하려면 200~400개의 학습 예제가 필요합니다. 최종적으로는 더 높은 정확도를 달성하지만, 효과를 내려면 이러한 워밍업 기간이 필요합니다. 제로샷은 학습 데이터 없이도 즉시 일관된 성능을 제공합니다.

예, API는 jina-embeddings-v3를 사용한 다국어 쿼리와 jina-clip-v2 또는 jina-embeddings-v4를 사용한 멀티모달(텍스트/이미지) 분류를 지원하며, 동일한 요청에서 URL 또는 base64로 인코딩된 이미지를 사용할 수 있습니다.

제로샷은 분류자 제한 없이 256개 카테고리를 지원하는 반면, 퓨샷은 16개 카테고리와 16개 분류자로 제한됩니다. 둘 다 요청당 1,024개의 입력과 입력당 8,192개의 토큰을 지원합니다.

소수 샘플 패턴을 사용하면 /train 엔드포인트를 통해 지속적인 업데이트를 통해 변화하는 데이터 패턴에 적응할 수 있습니다. 데이터 분포가 변경되면 전체 분류기를 다시 구축하지 않고도 새로운 예시나 카테고리를 점진적으로 추가할 수 있습니다.

API는 원패스 온라인 학습을 사용합니다. 학습 예제는 분류기 가중치를 업데이트하지만 이후에 저장되지는 않습니다. 즉, 과거 학습 데이터를 다시 가져올 수는 없지만 개인정보 보호와 리소스 효율성이 보장됩니다.

즉각적인 결과가 필요하거나 의미론적 레이블로 유연한 분류가 필요할 때는 제로샷으로 시작하세요. 예제가 200~400개 확보되었거나, 더 높은 정확도가 필요하거나, 도메인 특화 데이터나 시의성이 중요한 데이터를 다뤄야 할 때는 퓨샷으로 전환하세요.

네, 텍스트 분류(특히 다국어에 적합)에는 jina-embeddings-v3, 멀티모달 분류(89개 언어 지원)에는 jina-clip-v2, 일반적인 멀티모달 및 다국어 분류에는 jina-embeddings-v4 중에서 선택하실 수 있습니다.

Segmenter API는 무료로 사용할 수 있습니다. API 키를 제공하면 더 높은 속도 제한을 이용할 수 있으며 키에 요금이 청구되지 않습니다.

API 키가 없으면 20 RPM의 속도 제한으로 Segmenter API에 액세스할 수 있습니다.

API 키를 사용하면 200 RPM의 속도 제한으로 Segmenter API에 액세스할 수 있습니다. 프리미엄 유료 사용자의 경우 속도 제한은 1000 RPM입니다.

아니요. API 키는 더 높은 속도 제한에 액세스하는 데에만 사용됩니다.

예, Segmenter API는 다국어를 지원하며 100개 이상의 언어를 지원합니다.

GET 요청은 텍스트의 토큰 수를 계산하는 데만 사용되므로 이를 애플리케이션에 카운터로 쉽게 통합할 수 있습니다. POST 요청은 첫 번째/마지막 N 토큰 반환과 같은 더 많은 매개변수와 기능을 지원합니다.

요청당 최대 64,000자를 보낼 수 있습니다.

청킹 기능은 일반적인 구조적 단서를 바탕으로 긴 문서를 더 작은 청크로 분할하여 텍스트가 의미 있는 청크로 정확하게 나뉘도록 합니다. 본질적으로 이는 문장 끝, 단락 구분, 구두점, 특정 접속사 등 의미 경계와 자주 일치하는 구문적 특징을 기반으로 텍스트를 분할하는 (거대한!) 정규식 패턴입니다. 시맨틱 청킹은 아닙니다. 이 (거대한) 정규식은 정규식의 한계 내에서 가능한 한 강력하며, 복잡성과 성능의 균형을 맞춥니다. 정규식으로 진정한 의미 이해는 불가능하지만, 일반적인 구조적 단서를 통해 컨텍스트를 잘 근사합니다.

입력에 특수 토큰이 포함된 경우, Segmenter API는 이를 'special_tokens' 필드에 넣습니다. 이렇게 하면 특수 토큰을 쉽게 식별하고 다운스트림 작업에서 적절하게 처리할 수 있습니다. 예를 들어 인젝션 공격을 방지하기 위해 텍스트를 LLM에 입력하기 전에 제거할 수 있습니다.

청킹 기술은 서양 언어 외에도 중국어, 일본어, 한국어에도 적용됩니다.

이 기능은 현재 베타 버전이며, 미세 조정된 모델 하나당 100만 토큰이 필요합니다. Embedding/Reranker API에 충분한 토큰이 있으면 기존 API 키를 사용하거나 1,000만 개의 무료 토큰이 포함된 새 키를 만들 수 있습니다.

학습 데이터를 제공할 필요가 없습니다. 대상 도메인(미세 조정된 벡터 모델을 최적화하려는 도메인)을 자연어로 설명하거나 URL을 참조로 사용하기만 하면 당사 시스템이 모델 학습을 위한 합성 데이터를 생성합니다.

약 30분.

미세 조정된 모델과 합성 데이터는 Hugging Face 모델 허브에 공개적으로 저장됩니다.

시스템은 Reader API를 사용하여 URL에서 콘텐츠를 가져옵니다. 그런 다음 내용을 분석하여 어조와 영역을 요약하고 종합 데이터를 생성하기 위한 지침으로 사용했습니다. 따라서 URL은 공개적으로 액세스할 수 있어야 하며 대상 도메인을 나타내야 합니다.

예, 영어가 아닌 언어에 맞게 모델을 미세 조정할 수 있습니다. 시스템은 도메인 명령의 언어를 자동으로 감지하고 그에 따라 합성 데이터를 생성합니다. 또한 대상 언어에 적합한 기본 모델을 선택하는 것이 좋습니다. 예를 들어 독일 도메인을 대상으로 하는 경우 "jina-embeddings-v2-base-de"를 기본 모델로 선택해야 합니다.

아니요. 미세 조정 API는 Jina v2 모델만 지원합니다.

미세 조정 과정이 끝나면 시스템이 홀드아웃 테스트 세트로 모델을 평가하고 성능 지표를 보고합니다. 이 테스트 세트에서의 미세 조정 전후 성능을 정리한 이메일을 받게 됩니다. 품질을 확실히 확인하기 위해 직접 보유한 테스트 세트로도 모델을 평가해 보시길 권장합니다.

이 시스템은 사용자가 제공한 대상 도메인 지시문과 LLM 에이전트의 추론을 결합하여 합성 데이터를 생성합니다. 고품질 임베딩 모델 학습에 필수적인 하드 네거티브 트리플릿을 생성합니다. 자세한 내용은 곧 arXiv에 공개될 연구 논문을 참조하세요.

현재로서는 불가능합니다. 이 기능은 아직 베타 단계임을 유의해 주세요. 미세 조정된 모델과 합성 데이터를 Hugging Face 모델 허브에 공개적으로 저장하면 저희와 커뮤니티가 학습 품질을 평가하는 데 도움이 됩니다. 앞으로 비공개 저장 옵션을 제공할 계획입니다.

미세 조정된 모든 모델은 이미 Hugging Face에 업로드되어 있으므로 SentenceTransformers를 통해 액세스하려면 모델 이름만 지정하면 됩니다.

스팸 폴더를 확인해 보세요. 그래도 찾을 수 없으면 제공한 이메일 주소를 사용하여 지원팀에 문의하세요.