LFM2.5-Embedding-350M è il bi-encoder denso di LiquidAI per recupero multilingue e tra lingue diverse. Produce un vettore a 1024 dimensioni per ogni testo e mira alla ricerca a contesto breve in undici lingue. La famiglia denominata 350M usa un adattamento bidirezionale di LFM2.5-350M-Base; la tabella dettagliata del modello indica circa 354 milioni di parametri per questa edizione di embedding.
Il produttore adatta l’architettura di base affinché attenzione e convoluzioni locali possano usare il contesto su entrambi i lati di un token. Il pooling di tipo CLS trasforma il testo elaborato in un vettore denso. La tabella del modello descrive diciassette strati: dieci blocchi di convoluzione, sei blocchi di attenzione e una fase di pooling. È un encoder di recupero con propria preparazione e output, anziché l’attività di generazione testuale del modello base.
Il modello denominato separatamente LFM2.5-ColBERT-350M conserva vettori per token per l’interazione tardiva. Quella rappresentazione richiede un indice e un metodo di confronto diversi. Il modello Embedding qui descritto fornisce un vettore per documento o query, con la similarità del coseno come confronto documentato.
Prepara le query di ricerca con «query:» e i passaggi di origine con «document:». Il produttore memorizza questi prompt nella configurazione e il flusso di riferimento applica il nome di prompt corrispondente. Raccomanda specificamente di usare il ruolo appropriato su ogni lato, perché il modello è stato addestrato con questi prefissi. Questo prefisso di documento è diverso dalla convenzione «passage:» dei modelli E5.
Una raccolta concreta di ricerca di prodotti può contenere descrizioni nelle lingue supportate. Prepara la formulazione di ricerca dell’utente come query e ogni descrizione di prodotto come documento. Memorizza testo originale, identificatore del prodotto e lingua insieme al vettore, affinché un risultato di ricerca possa restituire il record corrispondente. Per una raccolta di assistenza, conserva la regola o l’istruzione pertinente alla domanda anziché sostituirla con un’etichetta breve non correlata.
L’insieme linguistico documentato comprende inglese, spagnolo, tedesco, francese, italiano, portoghese, arabo, svedese, norvegese, giapponese e coreano. Il produttore mira esplicitamente sia al recupero all’interno di una lingua sia al recupero tra lingue diverse. Prepara domande reali del pubblico previsto ed esamina il testo dei documenti restituiti in quelle lingue.
La specifica di lunghezza del documento è di 512 token. Dividi una fonte lunga in passaggi coerenti che preservino titolo, definizioni e condizioni necessari a un risultato recuperato. Il prefisso di ruolo e il contesto aggiunto fanno parte dell’input preparato. Una risposta di FAQ, una spiegazione di prodotto o una sezione mirata di un documento tecnico sono unità più adatte di un intero manuale eccessivamente grande.
Il produttore descrive tre fasi di addestramento: pre-addestramento contrastivo inglese, distillazione multilingue e tra lingue diverse, quindi fine-tuning con esempi negativi difficili selezionati. Il modello risultante è destinato a cataloghi di prodotti, raccolte di FAQ e assistenza, ricerca in file o note e recupero di conoscenze aziendali. Sono attività per le rappresentazioni testuali, non affermazioni sul deployment di una particolare applicazione.
L’esempio del produttore normalizza i vettori di query e documenti e li ordina con un prodotto scalare, equivalente alla similarità del coseno. Precalcola le rappresentazioni del corpus quando il materiale di origine è preparato, poi codifica una query di ricerca e restituisci documenti candidati con testo e identificatori. Mantieni il modello selezionato e la convenzione di ruolo insieme all’indice, affinché il confronto numerico usi rappresentazioni compatibili.
Il risultato utile è un indice di ricerca denso e compatto o un vettore di query che recupera materiale di origine nell’insieme linguistico documentato. Questa esatta edizione LFM2.5 Embedding rimane distinta dal modello compagno ColBERT, dai precedenti modelli di recupero LFM2 e dalle implementazioni quantizzate esternamente. Il testo del passaggio selezionato è l’evidenza usata da un lettore o da una successiva fase di risposta RAG.
", "aboutText": "LFM2.5-Embedding-350M è il bi-encoder denso di LiquidAI per recupero multilingue e tra lingue diverse. Produce un vettore a 1024 dimensioni per ogni testo e mira alla ricerca a contesto breve in undici lingue. La famiglia denominata 350M usa un adattamento bidirezionale di LFM2.5-350M-Base; la tabella dettagliata del modello indica circa 354 milioni di parametri per questa edizione di embedding.\n\n### Una rappresentazione bidirezionale per il recupero\n\nIl produttore adatta l’architettura di base affinché attenzione e convoluzioni locali possano usare il contesto su entrambi i lati di un token. Il pooling di tipo CLS trasforma il testo elaborato in un vettore denso. La tabella del modello descrive diciassette strati: dieci blocchi di convoluzione, sei blocchi di attenzione e una fase di pooling. È un encoder di recupero con propria preparazione e output, anziché l’attività di generazione testuale del modello base.\n\nIl modello denominato separatamente LFM2.5-ColBERT-350M conserva vettori per token per l’interazione tardiva. Quella rappresentazione richiede un indice e un metodo di confronto diversi. Il modello Embedding qui descritto fornisce un vettore per documento o query, con la similarità del coseno come confronto documentato.\n\n### Usare i prompt asimmetrici corretti\n\nPrepara le query di ricerca con «query:» e i passaggi di origine con «document:». Il produttore memorizza questi prompt nella configurazione e il flusso di riferimento applica il nome di prompt corrispondente. Raccomanda specificamente di usare il ruolo appropriato su ogni lato, perché il modello è stato addestrato con questi prefissi. Questo prefisso di documento è diverso dalla convenzione «passage:» dei modelli E5.\n\nUna raccolta concreta di ricerca di prodotti può contenere descrizioni nelle lingue supportate. Prepara la formulazione di ricerca dell’utente come query e ogni descrizione di prodotto come documento. Memorizza testo originale, identificatore del prodotto e lingua insieme al vettore, affinché un risultato di ricerca possa restituire il record corrispondente. Per una raccolta di assistenza, conserva la regola o l’istruzione pertinente alla domanda anziché sostituirla con un’etichetta breve non correlata.\n\n### Lingue e dimensione dei passaggi\n\nL’insieme linguistico documentato comprende inglese, spagnolo, tedesco, francese, italiano, portoghese, arabo, svedese, norvegese, giapponese e coreano. Il produttore mira esplicitamente sia al recupero all’interno di una lingua sia al recupero tra lingue diverse. Prepara domande reali del pubblico previsto ed esamina il testo dei documenti restituiti in quelle lingue.\n\nLa specifica di lunghezza del documento è di 512 token. Dividi una fonte lunga in passaggi coerenti che preservino titolo, definizioni e condizioni necessari a un risultato recuperato. Il prefisso di ruolo e il contesto aggiunto fanno parte dell’input preparato. Una risposta di FAQ, una spiegazione di prodotto o una sezione mirata di un documento tecnico sono unità più adatte di un intero manuale eccessivamente grande.\n\n### Addestramento e corrispondenza\n\nIl produttore descrive tre fasi di addestramento: pre-addestramento contrastivo inglese, distillazione multilingue e tra lingue diverse, quindi fine-tuning con esempi negativi difficili selezionati. Il modello risultante è destinato a cataloghi di prodotti, raccolte di FAQ e assistenza, ricerca in file o note e recupero di conoscenze aziendali. Sono attività per le rappresentazioni testuali, non affermazioni sul deployment di una particolare applicazione.\n\nL’esempio del produttore normalizza i vettori di query e documenti e li ordina con un prodotto scalare, equivalente alla similarità del coseno. Precalcola le rappresentazioni del corpus quando il materiale di origine è preparato, poi codifica una query di ricerca e restituisci documenti candidati con testo e identificatori. Mantieni il modello selezionato e la convenzione di ruolo insieme all’indice, affinché il confronto numerico usi rappresentazioni compatibili.\n\nIl risultato utile è un indice di ricerca denso e compatto o un vettore di query che recupera materiale di origine nell’insieme linguistico documentato. Questa esatta edizione LFM2.5 Embedding rimane distinta dal modello compagno ColBERT, dai precedenti modelli di recupero LFM2 e dalle implementazioni quantizzate esternamente. Il testo del passaggio selezionato è l’evidenza usata da un lettore o da una successiva fase di risposta RAG.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "3d57d713ce0109c0598a5eb67f82b6996a0f79fcc3132695f0ce665afed3e607", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "it", "methods": [ { "html": "liquid/lfm-2.5-embedding-350m:freeLiquidAI LFM2.5-Embedding-350M produce un vettore di 1024 dimensioni per ogni testo, per il recupero multilingue e tra lingue diverse. È pensato per 11 lingue e ingressi brevi di 512 token, con prefissi distinti per query e documenti.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
LFM2.5-Embedding-350M è il bi-encoder denso di LiquidAI per recupero multilingue e tra lingue diverse. Produce un vettore a 1024 dimensioni per ogni testo e mira alla ricerca a contesto breve in undici lingue. La famiglia denominata 350M usa un adattamento bidirezionale di LFM2.5-350M-Base; la tabella dettagliata del modello indica circa 354 milioni di parametri per questa edizione di embedding.
Il produttore adatta l’architettura di base affinché attenzione e convoluzioni locali possano usare il contesto su entrambi i lati di un token. Il pooling di tipo CLS trasforma il testo elaborato in un vettore denso. La tabella del modello descrive diciassette strati: dieci blocchi di convoluzione, sei blocchi di attenzione e una fase di pooling. È un encoder di recupero con propria preparazione e output, anziché l’attività di generazione testuale del modello base.
Il modello denominato separatamente LFM2.5-ColBERT-350M conserva vettori per token per l’interazione tardiva. Quella rappresentazione richiede un indice e un metodo di confronto diversi. Il modello Embedding qui descritto fornisce un vettore per documento o query, con la similarità del coseno come confronto documentato.
Prepara le query di ricerca con «query:» e i passaggi di origine con «document:». Il produttore memorizza questi prompt nella configurazione e il flusso di riferimento applica il nome di prompt corrispondente. Raccomanda specificamente di usare il ruolo appropriato su ogni lato, perché il modello è stato addestrato con questi prefissi. Questo prefisso di documento è diverso dalla convenzione «passage:» dei modelli E5.
Una raccolta concreta di ricerca di prodotti può contenere descrizioni nelle lingue supportate. Prepara la formulazione di ricerca dell’utente come query e ogni descrizione di prodotto come documento. Memorizza testo originale, identificatore del prodotto e lingua insieme al vettore, affinché un risultato di ricerca possa restituire il record corrispondente. Per una raccolta di assistenza, conserva la regola o l’istruzione pertinente alla domanda anziché sostituirla con un’etichetta breve non correlata.
L’insieme linguistico documentato comprende inglese, spagnolo, tedesco, francese, italiano, portoghese, arabo, svedese, norvegese, giapponese e coreano. Il produttore mira esplicitamente sia al recupero all’interno di una lingua sia al recupero tra lingue diverse. Prepara domande reali del pubblico previsto ed esamina il testo dei documenti restituiti in quelle lingue.
La specifica di lunghezza del documento è di 512 token. Dividi una fonte lunga in passaggi coerenti che preservino titolo, definizioni e condizioni necessari a un risultato recuperato. Il prefisso di ruolo e il contesto aggiunto fanno parte dell’input preparato. Una risposta di FAQ, una spiegazione di prodotto o una sezione mirata di un documento tecnico sono unità più adatte di un intero manuale eccessivamente grande.
Il produttore descrive tre fasi di addestramento: pre-addestramento contrastivo inglese, distillazione multilingue e tra lingue diverse, quindi fine-tuning con esempi negativi difficili selezionati. Il modello risultante è destinato a cataloghi di prodotti, raccolte di FAQ e assistenza, ricerca in file o note e recupero di conoscenze aziendali. Sono attività per le rappresentazioni testuali, non affermazioni sul deployment di una particolare applicazione.
L’esempio del produttore normalizza i vettori di query e documenti e li ordina con un prodotto scalare, equivalente alla similarità del coseno. Precalcola le rappresentazioni del corpus quando il materiale di origine è preparato, poi codifica una query di ricerca e restituisci documenti candidati con testo e identificatori. Mantieni il modello selezionato e la convenzione di ruolo insieme all’indice, affinché il confronto numerico usi rappresentazioni compatibili.
Il risultato utile è un indice di ricerca denso e compatto o un vettore di query che recupera materiale di origine nell’insieme linguistico documentato. Questa esatta edizione LFM2.5 Embedding rimane distinta dal modello compagno ColBERT, dai precedenti modelli di recupero LFM2 e dalle implementazioni quantizzate esternamente. Il testo del passaggio selezionato è l’evidenza usata da un lettore o da una successiva fase di risposta RAG.
POST /v1/embeddingstext, token_idsembedding| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti liquid/lfm-2.5-embedding-350m:free | Predefinito— |
Campoinput | Tipostring|string[]|integer[]|integer[][] | RequisitoObbligatorio | Valori e limiti Numero minimo di elementi: 1 Condizioni: Batch omogeneo non vuoto. Gli ID dei token sono numeri interi non negativi. Budget di input: Massimo: 512 · Unità di testo: byte UTF8 · Unità di token: elementi dell’array di token | Predefinito— |
Campoencoding_format | Tipostring | RequisitoFacoltativo | Valori e limiti float | Predefinitofloat |
Campodimensions | Tipointeger | RequisitoNon supportato | Valori e limiti Minimo: 1 | Predefinito— |
Campouser | Tipojson_value | RequisitoFacoltativo | Valori e limiti Condizioni: La fonte consente questo campo di metadati JSON; la semantica esatta del fornitore a monte dipende dal modello. | Predefinito— |
Camposession_id | Tipojson_value | RequisitoFacoltativo | Valori e limiti Condizioni: La fonte consente questo campo di metadati JSON; la semantica esatta del fornitore a monte dipende dal modello. | Predefinito— |
Campotrace | Tipojson_value | RequisitoFacoltativo | Valori e limiti Condizioni: La fonte consente questo campo di metadati JSON; la semantica esatta del fornitore a monte dipende dal modello. | Predefinito— |
Campoprovider | Tipoobject | RequisitoFacoltativo | Valori e limiti Condizioni: provider.options rifiutato | Predefinito— |
text_to_embedding
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, input |
Parametroinput_shapes | Contrattostring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parametroencoding_format | Contrattofloat |
Parametrodimensions_override | Contrattofalse |
Parametromax_input_budget_units | Contratto512 |
Parametromultimodal_objects | Contrattofalse |
Parametromaterial_types | Contrattotext, token_ids |
Ciclo di vita: synchronous_json
Conserva l'indice e la dimensione di ogni vettore.
Il nome del modello multimodale non consente oggetti immagine su questo percorso specifico.
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
| Configurazione | Listino delle tariffe | Costo |
|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Costo Input · Token in input $0 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
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": "liquid/lfm-2.5-embedding-350m:free", "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='liquid/lfm-2.5-embedding-350m:free',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Conserva ogni vettore con il suo indice. Il numero di vettori deve coincidere con il numero di input; le dimensioni devono essere coerenti.
Non viene introdotto alcun endpoint per i job di embedding.
| Campo | Tipo |
|---|---|
Campoobject | Tipostring |
Campomodel | Tipostring |
Campodata[].index | Tipointeger |
Campodata[].embedding | Tipofinite float[] |
Campousage | Tipoobject |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneCampi obbligatori, rappresentazione del materiale o valore del parametro non validi | Passaggio successivoCorreggi i campi indicati prima di una nuova richiesta di creazione. |
Ailoot Ultra liquid/lfm-2.5-embedding-350m:free
Usa i percorsi dei metodi indicati sopra.