LFM2.5-Embedding-350M ist LiquidAIs dichter Bi-Encoder für mehrsprachige und sprachübergreifende Suche. Er erzeugt für jeden Text einen 1024-dimensionalen Vektor und zielt auf Suche mit kurzem Kontext in elf Sprachen. Die benannte Modellfamilie 350M verwendet eine bidirektionale Anpassung von LFM2.5-350M-Base; die detaillierte Modelltabelle nennt ungefähr 354 Millionen Parameter für diese Embedding-Edition.
Der Hersteller passt das Grundmodell so an, dass Attention und lokale Faltungen Kontext auf beiden Seiten eines Tokens verwenden können. Pooling nach CLS-Art wandelt den verarbeiteten Text in einen dichten Vektor um. Die Modelltabelle beschreibt siebzehn Schichten: zehn Faltungsblöcke, sechs Attention-Blöcke und eine Pooling-Stufe. Dies ist ein Suchencoder mit eigener Vorbereitung und Ausgabe, getrennt von der Textgenerierungsaufgabe des Basismodells.
Das separat benannte LFM2.5-ColBERT-350M behält Vektoren pro Token für späte Interaktion bei. Diese Darstellung erfordert einen anderen Index und eine andere Vergleichsmethode. Das hier beschriebene Embedding-Modell liefert einen Vektor pro Dokument oder Abfrage; die Kosinusähnlichkeit ist der dokumentierte Vergleich.
Bereiten Sie Suchabfragen mit „query:“ und Quellpassagen mit „document:“ vor. Der Hersteller speichert diese Prompts in seiner Konfiguration; der Referenzablauf wendet den passenden Promptnamen an. Er empfiehlt ausdrücklich die entsprechende Rolle auf jeder Seite, weil das Modell mit diesen Präfixen trainiert wurde. Dieses Dokumentpräfix unterscheidet sich von der Konvention „passage:“ der E5-Modelle.
Eine praktische Produktsuchsammlung kann Beschreibungen in den unterstützten Sprachen enthalten. Bereiten Sie die Suchformulierung des Nutzers als Abfrage und jede Produktbeschreibung als Dokument vor. Speichern Sie Originaltext, Produktkennung und Sprache zusammen mit dem Vektor, damit ein Suchergebnis den zugehörigen Datensatz zurückgeben kann. Bewahren Sie für eine Supportsammlung die relevante Richtlinie oder Anweisung zur Frage, statt sie durch eine sachfremde kurze Bezeichnung zu ersetzen.
Der dokumentierte Sprachumfang umfasst Englisch, Spanisch, Deutsch, Französisch, Italienisch, Portugiesisch, Arabisch, Schwedisch, Norwegisch, Japanisch und Koreanisch. Der Hersteller zielt ausdrücklich sowohl auf Suche innerhalb einer Sprache als auch über Sprachgrenzen hinweg. Bereiten Sie echte Fragen der vorgesehenen Zielgruppe vor und prüfen Sie die zurückgegebenen Dokumenttexte in diesen Sprachen.
Die Spezifikation der Dokumentlänge beträgt 512 Token. Teilen Sie eine lange Quelle in zusammenhängende Passagen, die Überschrift, Definitionen und die für ein Suchergebnis nötigen Bedingungen bewahren. Rollenpräfix und zusätzlicher Kontext gehören zur vorbereiteten Eingabe. Eine FAQ-Antwort, eine Produkterklärung oder ein gezielter Abschnitt eines technischen Dokuments ist eine passendere Einheit als ein ganzes übergroßes Handbuch.
Der Hersteller beschreibt drei Trainingsphasen: englischsprachiges kontrastives Vortraining, mehrsprachige und sprachübergreifende Destillation und anschließend Feinabstimmung mit gezielt ermittelten schwierigen Negativbeispielen. Das entstandene Modell ist für Produktkataloge, FAQ- und Supportsammlungen, Datei- oder Notizsuche und Wissenssuche in Unternehmen vorgesehen. Dies sind Aufgaben für die Textdarstellungen und keine Aussagen über die Bereitstellung einer bestimmten Anwendung.
Das Herstellerbeispiel normalisiert Abfrage- und Dokumentvektoren und ordnet sie nach dem Skalarprodukt, das der Kosinusähnlichkeit entspricht. Berechnen Sie die Korpusdarstellungen vorab bei der Vorbereitung des Quellmaterials, betten Sie anschließend eine Suchabfrage ein und geben Sie mögliche Dokumenttreffer mit Text und Kennungen zurück. Bewahren Sie gewähltes Modell und Rollenkonvention zusammen mit dem Index, damit der numerische Vergleich kompatible Darstellungen verwendet.
Das hilfreiche Ergebnis ist ein kompakter dichter Suchindex oder ein Abfragevektor, der Quellmaterial über den dokumentierten Sprachumfang hinweg findet. Diese genaue LFM2.5-Embedding-Edition bleibt von ihrem ColBERT-Begleitmodell, älteren LFM2-Suchmodellen und extern quantisierten Implementierungen getrennt. Der ausgewählte Passagentext ist der Beleg, den ein Leser oder eine spätere RAG-Antwortstufe verwendet.
", "aboutText": "LFM2.5-Embedding-350M ist LiquidAIs dichter Bi-Encoder für mehrsprachige und sprachübergreifende Suche. Er erzeugt für jeden Text einen 1024-dimensionalen Vektor und zielt auf Suche mit kurzem Kontext in elf Sprachen. Die benannte Modellfamilie 350M verwendet eine bidirektionale Anpassung von LFM2.5-350M-Base; die detaillierte Modelltabelle nennt ungefähr 354 Millionen Parameter für diese Embedding-Edition.\n\n### Eine bidirektionale Suchdarstellung\n\nDer Hersteller passt das Grundmodell so an, dass Attention und lokale Faltungen Kontext auf beiden Seiten eines Tokens verwenden können. Pooling nach CLS-Art wandelt den verarbeiteten Text in einen dichten Vektor um. Die Modelltabelle beschreibt siebzehn Schichten: zehn Faltungsblöcke, sechs Attention-Blöcke und eine Pooling-Stufe. Dies ist ein Suchencoder mit eigener Vorbereitung und Ausgabe, getrennt von der Textgenerierungsaufgabe des Basismodells.\n\nDas separat benannte LFM2.5-ColBERT-350M behält Vektoren pro Token für späte Interaktion bei. Diese Darstellung erfordert einen anderen Index und eine andere Vergleichsmethode. Das hier beschriebene Embedding-Modell liefert einen Vektor pro Dokument oder Abfrage; die Kosinusähnlichkeit ist der dokumentierte Vergleich.\n\n### Verwenden Sie die richtigen asymmetrischen Prompts\n\nBereiten Sie Suchabfragen mit „query:“ und Quellpassagen mit „document:“ vor. Der Hersteller speichert diese Prompts in seiner Konfiguration; der Referenzablauf wendet den passenden Promptnamen an. Er empfiehlt ausdrücklich die entsprechende Rolle auf jeder Seite, weil das Modell mit diesen Präfixen trainiert wurde. Dieses Dokumentpräfix unterscheidet sich von der Konvention „passage:“ der E5-Modelle.\n\nEine praktische Produktsuchsammlung kann Beschreibungen in den unterstützten Sprachen enthalten. Bereiten Sie die Suchformulierung des Nutzers als Abfrage und jede Produktbeschreibung als Dokument vor. Speichern Sie Originaltext, Produktkennung und Sprache zusammen mit dem Vektor, damit ein Suchergebnis den zugehörigen Datensatz zurückgeben kann. Bewahren Sie für eine Supportsammlung die relevante Richtlinie oder Anweisung zur Frage, statt sie durch eine sachfremde kurze Bezeichnung zu ersetzen.\n\n### Sprachen und Passagengröße\n\nDer dokumentierte Sprachumfang umfasst Englisch, Spanisch, Deutsch, Französisch, Italienisch, Portugiesisch, Arabisch, Schwedisch, Norwegisch, Japanisch und Koreanisch. Der Hersteller zielt ausdrücklich sowohl auf Suche innerhalb einer Sprache als auch über Sprachgrenzen hinweg. Bereiten Sie echte Fragen der vorgesehenen Zielgruppe vor und prüfen Sie die zurückgegebenen Dokumenttexte in diesen Sprachen.\n\nDie Spezifikation der Dokumentlänge beträgt 512 Token. Teilen Sie eine lange Quelle in zusammenhängende Passagen, die Überschrift, Definitionen und die für ein Suchergebnis nötigen Bedingungen bewahren. Rollenpräfix und zusätzlicher Kontext gehören zur vorbereiteten Eingabe. Eine FAQ-Antwort, eine Produkterklärung oder ein gezielter Abschnitt eines technischen Dokuments ist eine passendere Einheit als ein ganzes übergroßes Handbuch.\n\n### Training und Abgleich\n\nDer Hersteller beschreibt drei Trainingsphasen: englischsprachiges kontrastives Vortraining, mehrsprachige und sprachübergreifende Destillation und anschließend Feinabstimmung mit gezielt ermittelten schwierigen Negativbeispielen. Das entstandene Modell ist für Produktkataloge, FAQ- und Supportsammlungen, Datei- oder Notizsuche und Wissenssuche in Unternehmen vorgesehen. Dies sind Aufgaben für die Textdarstellungen und keine Aussagen über die Bereitstellung einer bestimmten Anwendung.\n\nDas Herstellerbeispiel normalisiert Abfrage- und Dokumentvektoren und ordnet sie nach dem Skalarprodukt, das der Kosinusähnlichkeit entspricht. Berechnen Sie die Korpusdarstellungen vorab bei der Vorbereitung des Quellmaterials, betten Sie anschließend eine Suchabfrage ein und geben Sie mögliche Dokumenttreffer mit Text und Kennungen zurück. Bewahren Sie gewähltes Modell und Rollenkonvention zusammen mit dem Index, damit der numerische Vergleich kompatible Darstellungen verwendet.\n\nDas hilfreiche Ergebnis ist ein kompakter dichter Suchindex oder ein Abfragevektor, der Quellmaterial über den dokumentierten Sprachumfang hinweg findet. Diese genaue LFM2.5-Embedding-Edition bleibt von ihrem ColBERT-Begleitmodell, älteren LFM2-Suchmodellen und extern quantisierten Implementierungen getrennt. Der ausgewählte Passagentext ist der Beleg, den ein Leser oder eine spätere RAG-Antwortstufe verwendet.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "37678f590316045af59b37ad39a4802d1d46984885fd6b0a371cff93cf6b131a", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "liquid/lfm-2.5-embedding-350m:freeLiquidAI LFM2.5-Embedding-350M erzeugt für jeden Text einen 1024-dimensionalen Vektor für mehrsprachige und sprachübergreifende Suche. Das Modell ist auf 11 Sprachen und kurze Eingaben mit 512 Token ausgerichtet; Abfragen und Dokumente verwenden unterschiedliche Präfixe.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
LFM2.5-Embedding-350M ist LiquidAIs dichter Bi-Encoder für mehrsprachige und sprachübergreifende Suche. Er erzeugt für jeden Text einen 1024-dimensionalen Vektor und zielt auf Suche mit kurzem Kontext in elf Sprachen. Die benannte Modellfamilie 350M verwendet eine bidirektionale Anpassung von LFM2.5-350M-Base; die detaillierte Modelltabelle nennt ungefähr 354 Millionen Parameter für diese Embedding-Edition.
Der Hersteller passt das Grundmodell so an, dass Attention und lokale Faltungen Kontext auf beiden Seiten eines Tokens verwenden können. Pooling nach CLS-Art wandelt den verarbeiteten Text in einen dichten Vektor um. Die Modelltabelle beschreibt siebzehn Schichten: zehn Faltungsblöcke, sechs Attention-Blöcke und eine Pooling-Stufe. Dies ist ein Suchencoder mit eigener Vorbereitung und Ausgabe, getrennt von der Textgenerierungsaufgabe des Basismodells.
Das separat benannte LFM2.5-ColBERT-350M behält Vektoren pro Token für späte Interaktion bei. Diese Darstellung erfordert einen anderen Index und eine andere Vergleichsmethode. Das hier beschriebene Embedding-Modell liefert einen Vektor pro Dokument oder Abfrage; die Kosinusähnlichkeit ist der dokumentierte Vergleich.
Bereiten Sie Suchabfragen mit „query:“ und Quellpassagen mit „document:“ vor. Der Hersteller speichert diese Prompts in seiner Konfiguration; der Referenzablauf wendet den passenden Promptnamen an. Er empfiehlt ausdrücklich die entsprechende Rolle auf jeder Seite, weil das Modell mit diesen Präfixen trainiert wurde. Dieses Dokumentpräfix unterscheidet sich von der Konvention „passage:“ der E5-Modelle.
Eine praktische Produktsuchsammlung kann Beschreibungen in den unterstützten Sprachen enthalten. Bereiten Sie die Suchformulierung des Nutzers als Abfrage und jede Produktbeschreibung als Dokument vor. Speichern Sie Originaltext, Produktkennung und Sprache zusammen mit dem Vektor, damit ein Suchergebnis den zugehörigen Datensatz zurückgeben kann. Bewahren Sie für eine Supportsammlung die relevante Richtlinie oder Anweisung zur Frage, statt sie durch eine sachfremde kurze Bezeichnung zu ersetzen.
Der dokumentierte Sprachumfang umfasst Englisch, Spanisch, Deutsch, Französisch, Italienisch, Portugiesisch, Arabisch, Schwedisch, Norwegisch, Japanisch und Koreanisch. Der Hersteller zielt ausdrücklich sowohl auf Suche innerhalb einer Sprache als auch über Sprachgrenzen hinweg. Bereiten Sie echte Fragen der vorgesehenen Zielgruppe vor und prüfen Sie die zurückgegebenen Dokumenttexte in diesen Sprachen.
Die Spezifikation der Dokumentlänge beträgt 512 Token. Teilen Sie eine lange Quelle in zusammenhängende Passagen, die Überschrift, Definitionen und die für ein Suchergebnis nötigen Bedingungen bewahren. Rollenpräfix und zusätzlicher Kontext gehören zur vorbereiteten Eingabe. Eine FAQ-Antwort, eine Produkterklärung oder ein gezielter Abschnitt eines technischen Dokuments ist eine passendere Einheit als ein ganzes übergroßes Handbuch.
Der Hersteller beschreibt drei Trainingsphasen: englischsprachiges kontrastives Vortraining, mehrsprachige und sprachübergreifende Destillation und anschließend Feinabstimmung mit gezielt ermittelten schwierigen Negativbeispielen. Das entstandene Modell ist für Produktkataloge, FAQ- und Supportsammlungen, Datei- oder Notizsuche und Wissenssuche in Unternehmen vorgesehen. Dies sind Aufgaben für die Textdarstellungen und keine Aussagen über die Bereitstellung einer bestimmten Anwendung.
Das Herstellerbeispiel normalisiert Abfrage- und Dokumentvektoren und ordnet sie nach dem Skalarprodukt, das der Kosinusähnlichkeit entspricht. Berechnen Sie die Korpusdarstellungen vorab bei der Vorbereitung des Quellmaterials, betten Sie anschließend eine Suchabfrage ein und geben Sie mögliche Dokumenttreffer mit Text und Kennungen zurück. Bewahren Sie gewähltes Modell und Rollenkonvention zusammen mit dem Index, damit der numerische Vergleich kompatible Darstellungen verwendet.
Das hilfreiche Ergebnis ist ein kompakter dichter Suchindex oder ein Abfragevektor, der Quellmaterial über den dokumentierten Sprachumfang hinweg findet. Diese genaue LFM2.5-Embedding-Edition bleibt von ihrem ColBERT-Begleitmodell, älteren LFM2-Suchmodellen und extern quantisierten Implementierungen getrennt. Der ausgewählte Passagentext ist der Beleg, den ein Leser oder eine spätere RAG-Antwortstufe verwendet.
POST /v1/embeddingstext, token_idsembedding| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits liquid/lfm-2.5-embedding-350m:free | Standard— |
Feldinput | Typstring|string[]|integer[]|integer[][] | AnforderungErforderlich | Werte und Limits Mindestanzahl Elemente: 1 Bedingungen: Nicht leerer, homogener Batch. Token-IDs sind nichtnegative Ganzzahlen. Eingabebudget: Maximum: 512 · Texteinheit: UTF8-Bytes · Tokeneinheit: Elemente des Token-Arrays | Standard— |
Feldencoding_format | Typstring | AnforderungOptional | Werte und Limits float | Standardfloat |
Felddimensions | Typinteger | AnforderungNicht unterstützt | Werte und Limits Minimum: 1 | Standard— |
Felduser | Typjson_value | AnforderungOptional | Werte und Limits Bedingungen: Der Quellcode erlaubt dieses JSON-Metadatenfeld; die genaue Semantik beim vorgelagerten Anbieter ist modellspezifisch. | Standard— |
Feldsession_id | Typjson_value | AnforderungOptional | Werte und Limits Bedingungen: Der Quellcode erlaubt dieses JSON-Metadatenfeld; die genaue Semantik beim vorgelagerten Anbieter ist modellspezifisch. | Standard— |
Feldtrace | Typjson_value | AnforderungOptional | Werte und Limits Bedingungen: Der Quellcode erlaubt dieses JSON-Metadatenfeld; die genaue Semantik beim vorgelagerten Anbieter ist modellspezifisch. | Standard— |
Feldprovider | Typobject | AnforderungOptional | Werte und Limits Bedingungen: provider.options abgelehnt | Standard— |
text_to_embedding
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, input |
Parameterinput_shapes | Vertragstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Vertragfloat |
Parameterdimensions_override | Vertragfalse |
Parametermax_input_budget_units | Vertrag512 |
Parametermultimodal_objects | Vertragfalse |
Parametermaterial_types | Vertragtext, token_ids |
Lebenszyklus: synchronous_json
Jeden Vektorindex und jede Dimension beibehalten.
Ein multimodaler Modellname erlaubt auf genau diesem Pfad keine Bildobjekte.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
| Konfiguration | Tarifstaffel | Gebühr |
|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Gebühr Eingabe · Eingabetoken $0 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen — / 1K Token Eingabe · Cache-Schreiben — / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
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
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Jeden Vektor mit seinem Index beibehalten. Die Anzahl der Vektoren muss der Anzahl der Eingaben entsprechen; die Dimensionen müssen konsistent sein.
Es wird kein Endpunkt für Embedding-Aufträge eingeführt.
| Feld | Typ |
|---|---|
Feldobject | Typstring |
Feldmodel | Typstring |
Felddata[].index | Typinteger |
Felddata[].embedding | Typfinite float[] |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra liquid/lfm-2.5-embedding-350m:free
Verwenden Sie die oben angezeigten Methodenpfade.