GTE-large é o modelo General Text Embeddings de tamanho grande treinado pela Alibaba DAMO Academy. É um codificador de texto em inglês principalmente baseado no framework BERT, com uma representação densa de 1024 dimensões para cada entrada. O fabricante treina a família GTE com pares de textos relacionados por relevância em vários domínios e identifica recuperação, similaridade semântica textual e reordenação de textos como aplicações posteriores.
Prepare a passagem em inglês que deve ser comparada com uma consulta de pesquisa. Numa coleção de relatórios técnicos, conserve o tema, a observação e a condição relevante de uma secção curta. Um relatório que descreve vibração apenas sob uma carga específica deve preservar essa condição, em vez de deixar uma afirmação genérica sobre vibração.
Mantenha identificadores de origem, títulos de documentos e localizações de secções com os vetores armazenados. Uma consulta pode recuperar secções candidatas, enquanto o relatório original continua disponível para verificar o equipamento, a condição e a conclusão. O embedding fornece uma representação numérica do conteúdo da passagem.
A receita publicada utiliza pooling por média das representações dos tokens com a máscara de atenção, excluindo o preenchimento da média. Também mostra normalização L2 opcional seguida de comparação por produto escalar de vetores normalizados. O exemplo de Sentence Transformers utiliza similaridade do cosseno.
Mantenha as mesmas definições de preparação, pooling e comparação na coleção e no lado da consulta. Cada representação contém 1024 componentes. A maior contagem de componentes é um detalhe da edição; não demonstra que vetores GTE-large possam ser misturados com a representação de 768 dimensões de GTE-base ou com outro codificador de 1024 dimensões.
Um fluxo de reordenação pode comparar o embedding de uma consulta com um conjunto de embeddings candidatos já recuperado e reordenar esses registos. Mantenha a distinção entre essa comparação vetorial e um modelo separado que avalia conjuntamente um par de consulta e passagem.
A ficha restringe explicitamente este modelo exato a texto em inglês e trunca entradas longas a um máximo de 512 tokens. Divida um relatório técnico longo em secções coerentes e mantenha contexto local suficiente para que cada secção se compreenda por si só. Se uma frase depender de uma ressalva anterior, conserve essa ressalva na mesma unidade indexada quando couber.
Um limite de tokens é diferente de uma contagem visível de palavras. Verifique o comprimento da secção preparada e assegure que o detalhe necessário à pesquisa prevista não fica para além da parte conservada após o truncamento.
Numa aplicação de pesquisa de relatórios, apresente secções candidatas com as suas localizações de origem e examine o conteúdo real. Observações semelhantes podem ter causas ou recomendações diferentes. Uma pontuação vetorial ajuda a ordenar os candidatos na configuração de comparação escolhida; não demonstra que a conclusão de um relatório se aplique a uma nova situação.
Para RAG, utilize as secções selecionadas como contexto de origem para a etapa de redação da resposta e conserve as suas associações aos documentos. Este perfil GTE-large exato fornece embeddings densos em inglês com 1024 dimensões e um limite de entrada de 512 tokens. Edições GTE multilingues e de contexto alargado posteriores têm identidades separadas, pelo que a sua cobertura linguística ou definições de entrada não decorrem do nome de família deste checkpoint.
", "aboutText": "GTE-large é o modelo General Text Embeddings de tamanho grande treinado pela Alibaba DAMO Academy. É um codificador de texto em inglês principalmente baseado no framework BERT, com uma representação densa de 1024 dimensões para cada entrada. O fabricante treina a família GTE com pares de textos relacionados por relevância em vários domínios e identifica recuperação, similaridade semântica textual e reordenação de textos como aplicações posteriores.\n\n### Represente o conteúdo de uma secção\n\nPrepare a passagem em inglês que deve ser comparada com uma consulta de pesquisa. Numa coleção de relatórios técnicos, conserve o tema, a observação e a condição relevante de uma secção curta. Um relatório que descreve vibração apenas sob uma carga específica deve preservar essa condição, em vez de deixar uma afirmação genérica sobre vibração.\n\nMantenha identificadores de origem, títulos de documentos e localizações de secções com os vetores armazenados. Uma consulta pode recuperar secções candidatas, enquanto o relatório original continua disponível para verificar o equipamento, a condição e a conclusão. O embedding fornece uma representação numérica do conteúdo da passagem.\n\n### Pooling, normalização e utilização dos vetores\n\nA receita publicada utiliza pooling por média das representações dos tokens com a máscara de atenção, excluindo o preenchimento da média. Também mostra normalização L2 opcional seguida de comparação por produto escalar de vetores normalizados. O exemplo de Sentence Transformers utiliza similaridade do cosseno.\n\nMantenha as mesmas definições de preparação, pooling e comparação na coleção e no lado da consulta. Cada representação contém 1024 componentes. A maior contagem de componentes é um detalhe da edição; não demonstra que vetores GTE-large possam ser misturados com a representação de 768 dimensões de GTE-base ou com outro codificador de 1024 dimensões.\n\nUm fluxo de reordenação pode comparar o embedding de uma consulta com um conjunto de embeddings candidatos já recuperado e reordenar esses registos. Mantenha a distinção entre essa comparação vetorial e um modelo separado que avalia conjuntamente um par de consulta e passagem.\n\n### Comprimento de entrada e limitação ao inglês\n\nA ficha restringe explicitamente este modelo exato a texto em inglês e trunca entradas longas a um máximo de 512 tokens. Divida um relatório técnico longo em secções coerentes e mantenha contexto local suficiente para que cada secção se compreenda por si só. Se uma frase depender de uma ressalva anterior, conserve essa ressalva na mesma unidade indexada quando couber.\n\nUm limite de tokens é diferente de uma contagem visível de palavras. Verifique o comprimento da secção preparada e assegure que o detalhe necessário à pesquisa prevista não fica para além da parte conservada após o truncamento.\n\n### Examine a evidência recuperada\n\nNuma aplicação de pesquisa de relatórios, apresente secções candidatas com as suas localizações de origem e examine o conteúdo real. Observações semelhantes podem ter causas ou recomendações diferentes. Uma pontuação vetorial ajuda a ordenar os candidatos na configuração de comparação escolhida; não demonstra que a conclusão de um relatório se aplique a uma nova situação.\n\nPara RAG, utilize as secções selecionadas como contexto de origem para a etapa de redação da resposta e conserve as suas associações aos documentos. Este perfil GTE-large exato fornece embeddings densos em inglês com 1024 dimensões e um limite de entrada de 512 tokens. Edições GTE multilingues e de contexto alargado posteriores têm identidades separadas, pelo que a sua cobertura linguística ou definições de entrada não decorrem do nome de família deste checkpoint.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "87059889143e5aa6fa785f61a2e0c58f0977147fe6bf16162f4c8db15a7c90d5", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "pt-pt", "methods": [ { "html": "thenlper/gte-largeAlibaba DAMO Academy GTE-large converte texto em inglês em vetores de 1024 dimensões para recuperação, similaridade semântica e reordenação baseada em embeddings. A sua receita de referência utiliza pooling por média, normalização opcional e um comprimento máximo de sequência de 512 tokens.
Esta descrição apresenta as capacidades do modelo. As entradas, saídas e opções disponíveis no Ailoot para o método selecionado estão indicadas abaixo.
GTE-large é o modelo General Text Embeddings de tamanho grande treinado pela Alibaba DAMO Academy. É um codificador de texto em inglês principalmente baseado no framework BERT, com uma representação densa de 1024 dimensões para cada entrada. O fabricante treina a família GTE com pares de textos relacionados por relevância em vários domínios e identifica recuperação, similaridade semântica textual e reordenação de textos como aplicações posteriores.
Prepare a passagem em inglês que deve ser comparada com uma consulta de pesquisa. Numa coleção de relatórios técnicos, conserve o tema, a observação e a condição relevante de uma secção curta. Um relatório que descreve vibração apenas sob uma carga específica deve preservar essa condição, em vez de deixar uma afirmação genérica sobre vibração.
Mantenha identificadores de origem, títulos de documentos e localizações de secções com os vetores armazenados. Uma consulta pode recuperar secções candidatas, enquanto o relatório original continua disponível para verificar o equipamento, a condição e a conclusão. O embedding fornece uma representação numérica do conteúdo da passagem.
A receita publicada utiliza pooling por média das representações dos tokens com a máscara de atenção, excluindo o preenchimento da média. Também mostra normalização L2 opcional seguida de comparação por produto escalar de vetores normalizados. O exemplo de Sentence Transformers utiliza similaridade do cosseno.
Mantenha as mesmas definições de preparação, pooling e comparação na coleção e no lado da consulta. Cada representação contém 1024 componentes. A maior contagem de componentes é um detalhe da edição; não demonstra que vetores GTE-large possam ser misturados com a representação de 768 dimensões de GTE-base ou com outro codificador de 1024 dimensões.
Um fluxo de reordenação pode comparar o embedding de uma consulta com um conjunto de embeddings candidatos já recuperado e reordenar esses registos. Mantenha a distinção entre essa comparação vetorial e um modelo separado que avalia conjuntamente um par de consulta e passagem.
A ficha restringe explicitamente este modelo exato a texto em inglês e trunca entradas longas a um máximo de 512 tokens. Divida um relatório técnico longo em secções coerentes e mantenha contexto local suficiente para que cada secção se compreenda por si só. Se uma frase depender de uma ressalva anterior, conserve essa ressalva na mesma unidade indexada quando couber.
Um limite de tokens é diferente de uma contagem visível de palavras. Verifique o comprimento da secção preparada e assegure que o detalhe necessário à pesquisa prevista não fica para além da parte conservada após o truncamento.
Numa aplicação de pesquisa de relatórios, apresente secções candidatas com as suas localizações de origem e examine o conteúdo real. Observações semelhantes podem ter causas ou recomendações diferentes. Uma pontuação vetorial ajuda a ordenar os candidatos na configuração de comparação escolhida; não demonstra que a conclusão de um relatório se aplique a uma nova situação.
Para RAG, utilize as secções selecionadas como contexto de origem para a etapa de redação da resposta e conserve as suas associações aos documentos. Este perfil GTE-large exato fornece embeddings densos em inglês com 1024 dimensões e um limite de entrada de 512 tokens. Edições GTE multilingues e de contexto alargado posteriores têm identidades separadas, pelo que a sua cobertura linguística ou definições de entrada não decorrem do nome de família deste checkpoint.
POST /v1/embeddingstext, token_idsembedding| Campo | Tipo | Requisito | Valores e limites | Predefinição |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObrigatório | Valores e limites thenlper/gte-large | Predefinição— |
Campoinput | Tipostring|string[]|integer[]|integer[][] | RequisitoObrigatório | Valores e limites Número mínimo de elementos: 1 Condições: Lote homogéneo não vazio. Os IDs de tokens são números inteiros não negativos. Orçamento de entrada: Máximo: 512 · Unidade de texto: bytes UTF8 · Unidade de tokens: elementos do array de tokens | Predefinição— |
Campoencoding_format | Tipostring | RequisitoOpcional | Valores e limites float | Predefiniçãofloat |
Campodimensions | Tipointeger | RequisitoNão suportado | Valores e limites Mínimo: 1 | Predefinição— |
Campouser | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Camposession_id | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Campotrace | Tipojson_value | RequisitoOpcional | Valores e limites Condições: A fonte permite este campo de metadados JSON; a semântica exata a montante depende do modelo. | Predefinição— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores e limites Condições: provider.options rejeitado | Predefinição— |
text_to_embedding
| Parâmetro | Contrato |
|---|---|
Parâmetrocontent_type | Contratoapplication/json |
Parâmetrorequired | Contratomodel, input |
Parâmetroinput_shapes | Contratostring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parâmetroencoding_format | Contratofloat |
Parâmetrodimensions_override | Contratofalse |
Parâmetromax_input_budget_units | Contrato512 |
Parâmetromultimodal_objects | Contratofalse |
Parâmetromaterial_types | Contratotext, token_ids |
Ciclo de vida: synchronous_json
Guarde o índice e a dimensão de cada vetor.
O nome do modelo multimodal não permite objetos de imagem neste caminho exato.
As referências tarifárias não acrescentam opções ao pedido. Os parâmetros suportados constam do método selecionado.
| Configuração | Tabela de tarifas | Custo |
|---|---|---|
| ConfiguraçãoTarifas base dos tokens | Tabela de tarifasTarifa base | Custo Entrada · Tokens de entrada $0.00002 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache — / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
O Ailoot reserva um montante estimado antes de um pedido. Após o resultado, liquida o custo final com base na utilização medida. No streaming, a liquidação usa o registo final de utilização. Como funcionam a reserva e a liquidação →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "thenlper/gte-large", "input": ["First document", "Second document"]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.embeddings.create(model='thenlper/gte-large',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Guarde cada resposta, ficheiro e parte de conteúdo devolvidos na íntegra.
Guarde cada vetor com o respetivo índice. O número de vetores tem de ser igual ao número de entradas; as dimensões têm de ser consistentes.
Não é introduzido nenhum endpoint de tarefas de embeddings.
| Campo | Tipo |
|---|---|
Campoobject | Tipostring |
Campomodel | Tipostring |
Campodata[].index | Tipointeger |
Campodata[].embedding | Tipofinite float[] |
Campousage | Tipoobject |
| Resposta | Condição | Passo seguinte |
|---|---|---|
Resposta400 · invalid_request_error | CondiçãoCampos obrigatórios, representação do material ou valor do parâmetro inválidos | Passo seguinteCorrija os campos indicados antes de um novo pedido de criação. |
Ailoot Ultra thenlper/gte-large
Use os caminhos dos métodos indicados acima.