LMQL (Language Model Query Language) est un langage de programmation spécial pour les grands modèles de langage qui permet aux développeurs d'utiliser une syntaxe déclarative pour contrôler le format de sortie, les contraintes et le processus de raisonnement de LLM. Il prend en charge la sortie structurée de type sécurisé, les chaînes de raisonnement en plusieurs étapes, la logique de branchement et le décodage de contraintes, transformant l'ingénierie des mots rapides d'une « expérience de boîte noire » à un « processus déterministe programmable ».

LMQL

Paramètres de base et statistiques de LMQL

LMQL (Language Model Query Language) n'est pas une autre bibliothèque d'empaquetage LLM, ni un moteur de modèles de mots d'invite - c'est un langage de programmation complet qui utilise une syntaxe déclarative pour transformer les appels LLM d'« expériences de boîte noire » en « processus déterministes programmables ». Il a été développé par le Safe and Reliable Intelligence Laboratory (SRI Lab) de l'ETH Zurich et s'adresse aux développeurs et aux chercheurs qui ont besoin d'un contrôle précis des résultats du LLM.

Projets	Informations publiques
Positionnement officiel	Un langage de programmation pour les grands modèles de langage
Types de technologies de base	Agent/MCP/outils d'automatisation - contrôlez le comportement du LLM via des constructions au niveau du langage
Contrat de licence	Apache-2.0 Open Source
Formulaire d'installation	Bibliothèque Python (pip install lmql), multiplateforme
Accueil	DE (ETH Zurich, Laboratoire SRI)
Étoiles GitHub	~4 200
Fourches GitHub	~221
Contributeurs	~35
Dernière version	0.7.3 (2023-10-15)
Backends pris en charge	OpenAI, Azure OpenAI, HuggingFace Transformers, lama.cpp, Répliquer

Un bref commentaire : LMQL résout la contradiction fondamentale du projet Prompt : les développeurs veulent utiliser une logique déterministe pour contrôler la sortie, tandis que LLM est naturellement probabiliste. Il introduit le décodage de contraintes, le système de types et le flux de contrôle au niveau du langage, effectuant des appels LLM écrits comme Python et exécutés avec des limites.

Rappel de statut : La principale période de développement active de LMQL aura lieu en 2023 et la dernière version stable 0.7.3 sera publiée en octobre 2023. Les mises à jour ultérieures du projet se concentreront sur la maintenance de la communauté et l'amélioration des documents, et aucune nouvelle version majeure ne sera publiée. Cela signifie qu'il est tourné vers l'avenir en termes de concepts techniques, mais lorsqu'il est utilisé comme dépendance de production, l'activité de maintenance à long terme du projet doit être évaluée.

Utilisateurs et reconnaissance du marché de LMQL

L'influence du LMQL se reflète principalement dans la communauté de recherche universitaire et dans les premiers groupes de praticiens en ingénierie LLM, plutôt que dans son adoption commerciale à grande échelle.

Approbation académique : produit par le laboratoire SRI de l'ETH Zurich, le contexte de recherche fournit la profondeur théorique du projet. L'idée de décodage de contraintes de LMQL a directement influencé la conception de plusieurs chaînes d'outils LLM ultérieures (y compris l'analyseur de sortie partielle de LangChain, Guidance, et d'autres projets similaires). Les articles universitaires et articles de blog pertinents ont des citations stables dans la communauté NLP/ML.

Taille de la communauté : environ 4 200 étoiles, 221 Forks et 35 contributeurs sur GitHub. Il s'agit d'un projet open source « de grande envergure et de taille moyenne ». Sa communauté Discord et son blog technique (lmql.ai/blog) enregistrent en détail l'évolution des versions et les décisions de conception, qui constituent une valeur de référence pour les chercheurs et les utilisateurs approfondis.

Impact sur l'industrie : Le concept de « contrôler le LLM avec un langage de programmation » proposé par LMQL était un concept d'avant-garde en 2023, et a ensuite été adopté ou utilisé comme référence par de nombreuses entreprises et projets open source. Cependant, LMQL lui-même n'a pas évolué vers des applications commerciales à grande échelle, et sa valeur se reflète davantage dans la « réflexion technique » que dans la « croissance des utilisateurs ». Si l'activité et l'échelle des utilisateurs sont utilisées comme critères, LMQL en est encore au stade de « prototype de recherche influent » plutôt qu'à un outil de production mature.

Avantage financier de LMQL

La structure des coûts de LMQL est très simple : le langage lui-même est entièrement open source et gratuit, et le coût provient de la facturation à l'utilisation du backend LLM connecté.

• C-side/Personal : LMQL est une bibliothèque Python, entièrement gratuite (licence Apache-2.0). Les développeurs individuels peuvent l'installer et l'utiliser localement pour une durée illimitée sans aucun frais d'abonnement. Cependant, si vous utilisez un backend cloud tel qu'OpenAI, vous devez apporter votre propre clé API et payer selon les tarifs du backend.

• API/Développeur : LMQL lui-même n'a pas de frais d'appel API. Les développeurs n'ont qu'à « pip install lmql », puis configurer les informations d'identification du backend LLM cible (telles que la clé API OpenAI). LMQL agit comme une « couche de traduction + moteur de contraintes » au moment de l'exécution : il n'entraîne pas de frais d'API distincts, mais compile les requêtes en appels au backend LLM. Cela signifie que la consommation de jetons de LMQL affecte directement la facture back-end : la couche de décodage des contraintes et de mise en cache peut réduire considérablement la consommation de jetons (les données officielles indiquent que la couche de mise en cache peut réduire l'utilisation des jetons de 33 à 80 %), réduisant ainsi indirectement la facturation de l'API back-end.

• Entreprise/privatisation : les entreprises peuvent télécharger gratuitement le code source LMQL pour un déploiement privé ou un développement secondaire (licence Apache-2.0). Pour les scénarios sensibles aux données, il peut être combiné avec un modèle HuggingFace local ou llama.cpp pour s'exécuter complètement hors ligne sans aucun appel d'API externe. Le coût à l’heure actuelle concerne principalement les coûts d’achat/de location du serveur GPU ainsi que la main d’œuvre d’exploitation et de maintenance. La couche de cache arborescente de LMQL peut réutiliser les résultats du cache dans des scénarios d'inférence par lots d'entreprise, réduisant ainsi davantage la surcharge de puissance de calcul des requêtes répétées.

Dimension du coût	Côté C/Individuel	API/Développeur	Entreprise/Privatisation
Frais de licence LMQL	Gratuit	Gratuit	Gratuit
Coût back-end LLM	Apportez votre propre clé, le prix est basé sur le back-end	Apportez votre propre clé, le prix est basé sur le back-end	Construisez votre propre modèle ou payez au fur et à mesure
Infrastructures	PC uniquement	S'appuyer sur l'API backend	Serveur GPU + exploitation et maintenance
Coûts cachés	Apprendre la syntaxe LMQL	Décodage et débogage de contraintes	Gestion du cache, compatibilité des versions

Principales fonctions de LMQL

Les capacités de LMQL ne sont pas un plateau « un outil avec plusieurs fonctions », mais une collaboration de quatre couches de capacités à travers la conception du langage : contraintes + flux de contrôle + algorithme de décodage + abstraction back-end. Chaque couche peut être utilisée indépendamment, mais sa véritable valeur se révèle lorsqu'elle est combinée.

• Constraint Decoding : la capacité de différenciation de base de LMQL. Déclarez les contraintes de sortie via la clause where, telles que len(TOKENS(ANSWER)) < 120, STOPS_AT(ANSWER, "."), INT(NUM), REGEX(RESPONSE, r"[0-9]{2}/[0-9]{2}"). Les contraintes sont forcées de prendre effet via le masquage logit pendant la phase de décodage, plutôt que par une correspondance régulière de chaîne après la génération. Cela signifie que le modèle ne produira pas du tout de sortie illégale lorsque les contraintes ne sont pas respectées - ceci est essentiellement différent de la "vérification post-traitement" et réduit le nombre de tentatives et le gaspillage de jetons.

• Sortie structurée de type sécurisé : la sortie LLM peut être directement contrainte à être un objet structuré valide via type(VAR) is Person (où Person est une classe de données Python). LMQL traduit automatiquement les définitions de type en contraintes de décodage, garantissant que la sortie peut être correctement analysée en tant qu'objets Python. Ceci est particulièrement utile lors de l’extraction de données au format JSON à partir de texte non structuré : pas besoin d’écrire des analyseurs de sortie complexes ni d’insister sur le format de sortie dans l’invite.

• Requêtes imbriquées et programmation d'invites procédurales (requêtes imbriquées) : la fonctionnalité "Programmation d'invites procédurales" introduite dans la version 0.7. Les développeurs peuvent encapsuler la logique d'invite sous la forme d'une fonction « @lmql.query » et l'appeler comme une fonction normale dans la requête de niveau supérieur. Par exemple, définissez une fonction chain_of_thought pour effectuer un raisonnement en chaîne de pensée et appelez-la au niveau supérieur [ANSWER: chain_of_thought]. Les requêtes imbriquées exécutent automatiquement le processus « injection d'instructions → génération → suppression d'instructions », qui est similaire à l'appel de fonction et à l'expansion de la pile dans la programmation traditionnelle.

• Prise en charge de plusieurs algorithmes de décodage : prend en charge plusieurs stratégies de décodage telles que argmax (décodage gourmand), sample(temperature=1.2) (décodage par échantillonnage), beam(N) (recherche de faisceau) et best_k. Les développeurs peuvent changer de méthode de décodage à différentes étapes de la même requête, par exemple, utiliser d'abord sample pour la génération exploratoire, puis utiliser argmax pour une sortie déterministe.

• Caching Layer : une structure de cache arborescente qui met en cache tous les jetons, logits et métadonnées générés par LLM. Dans le scénario multivariable modèle, la consommation de jetons peut être réduite de 77 % et le nombre de requêtes de 75 % ; dans le scénario de court-circuit à contrainte longue, la consommation de jetons peut être réduite de 80 % ; dans le scénario d'amélioration de l'outil, le nombre d'interactions peut être réduit de 33 %. Le cache peut être conservé sur le disque et réutilisé entre les requêtes.

• Améliorations de l'outil (Actions) : fonctionnalité de prévisualisation qui permet à LLM d'appeler des fonctions Python arbitraires (telles que wiki(q), calc(expr)) pendant l'inférence. Le protocole d'appel est géré automatiquement par le runtime LMQL et les développeurs n'ont qu'à déclarer les outils disponibles dans inline_use(REASONING, [wiki, calc]).

Évolution du modèle et des versions LMQL

L'historique des versions de LMQL montre clairement le chemin évolutif du « prototype académique » au « langage entièrement fonctionnel ». D’avril à octobre 2023 est une période d’itération intensive, après laquelle le projet entre dans un état de maintenance stable.

Premiers travaux (2023-04 à 2023-06)

• LMQL 0.0.5 (2023-04-17) : première version stable, axée sur l'optimisation des performances et l'amélioration de la stabilité. Le premier lot de contributions communautaires est fusionné, marquant la transition du projet d'un prototype de recherche individuel à un projet collaboratif communautaire.
• LMQL 0.0.6 (01/05/2023) : version Milestone - introduction de la couche de mise en cache. La mise en cache de l'arborescence réduit la consommation de jetons des requêtes de modèles de 77 % et celle des scénarios de contraintes longues de 80 %. Il s’agit de l’innovation la plus critique de LMQL en matière d’efficacité technique.
• LMQL 0.0.6.1 (2023-05-03) : Réparation et optimisation des bugs de la couche cache, nouvel écrivain de sortie HTTP/WebSocket/SSE, afin que LMQL puisse être intégré dans les services Web.
• LMQL 0.0.6.3 (2023-05-11) : runtime plus léger (supprime la dépendance obligatoire aux transformateurs), nouvelle fonction de contrainte TOKENS(...) et capacité d'arrêt conditionnel.
• LMQL 0.0.6.4 (2023-06-08) : améliorations techniques majeures - Azure OpenAI prend en charge le protocole LMTP pour accélérer l'inférence de modèle local de 5 à 6 fois, et l'API Python synchrone simplifie l'utilisation du backend de segmentation de mots tiktoken.

Simplification de la syntaxe et backends multiples (2023-07)

• LMQL 0.0.6.5 (2023-07-14) : Réforme de la "minimisation" de la syntaxe. Le code LMQL est plus proche du Python standard et les requêtes peuvent être définies sur une seule ligne ; un nouveau décorateur @lmql.query et une fonction lambda lmql.F sont ajoutés ; de nouvelles contraintes backend et en ligne llama.cpp sont ajoutées. Cette refactorisation a considérablement abaissé le seuil de démarrage.
• LMQL 0.0.6.6 (2023-07-25) : lmql.F prend en charge les paramètres de position, améliore la gestion des erreurs llama.cpp, prend en charge le modèle de quantification auto_gptq. Les contributions communautaires ont considérablement augmenté.

Explosion de fonctions (2023-10)

• LMQL 0.7 (2023-10-10) : La plus grande mise à jour et la dernière version majeure. Présentation des requêtes imbriquées (programmation d'invite procédurale), de l'API Generations (interface de génération légère + notation), de l'API Chat (déploiement en un clic de chatbots), des certificats de raisonnement (enregistrements de raisonnement reproductibles), des décorateurs de variables et des extensions multi-backend (Répliquer, phrase). Les actions LMQL (appels d'outils), les contraintes regex et les contraintes de type/classe de données sont également publiées sous forme d'aperçu.
• LMQL 0.7.1 (2023-10-12) : Correction du problème de compatibilité entre la clause de distribution et le traçage d'inférence.
• LMQL 0.7.2 (2023-10-13) : Assurez-vous que la commande lmql Playground est disponible dans le package PyPI.
• LMQL 0.7.3 (2023-10-15) : Correction d'un problème où les fichiers de ressources de l'API Chat n'étaient pas inclus dans le package PyPI.

Depuis lors, le projet n'a pas publié de mises à jour majeures, se concentrant principalement sur l'amélioration des documents et la maintenance communautaire.

Avantages techniques de LMQL

La différence technique de LMQL ne réside pas dans "plus de fonctions", mais dans "le remplacement des paramètres d'invite par la conception du langage" - il élève l'ingénierie LLM des expériences de mots d'invite au niveau d'abstraction d'un langage de programmation.

Mécanisme et effet du décodage des contraintes : l'approche traditionnelle consiste à écrire « Veuillez sortir le format JSON » dans l'invite, puis à analyser et à réessayer via le post-traitement. LMQL masque directement les jetons illégaux via le masquage logit au niveau de la couche de décodage - si la contrainte nécessite la sortie d'entiers, la probabilité de jetons non numériques est directement mise à zéro lorsque le modèle de langage est généré à chaque étape. Cela entraîne deux effets : ① La conformité des résultats passe de « haute probabilité » à « déterministe » ; ② Aucune logique de post-traitement et de nouvelle tentative n'est requise, ce qui réduit le gaspillage de jetons. Le court-circuit des contraintes est encore optimisé : une fois que le modèle génère le résultat d'une contrainte déterminée (telle que "l'option A" est sélectionnée), les jetons restants sont automatiquement complétés par les contraintes sans appeler LLM.

La valeur technique de la couche de cache arborescente : dans les appels LLM traditionnels, les modèles multivariables nécessitent plusieurs requêtes indépendantes : chaque requête contient le même préfixe de contexte, ce qui entraîne une grande quantité de jetons et un gaspillage de délais. Le cache d'arborescence de LMQL stocke toutes les branches candidates (logits, jetons, métadonnées) pour chaque position de jeton en tant que nœuds réutilisables. Lorsque le même modèle est exécuté, si la sortie de LLM est alignée sur le modèle, les variables sont remplies directement sans rappel - les données officielles peuvent réduire le nombre de demandes de 33 à 80 %. Le cache peut être conservé sur le disque, ce qui est particulièrement utile pendant la phase de développement de la requête : lors de l'itération plusieurs fois de la même requête, le cache atteint automatiquement les parties inchangées et seuls les appels sont effectués pour les parties nouvellement modifiées.

Couche d'abstraction backend : LMQL n'est pas un langage qui lie des modèles spécifiques. Le même morceau de code LMQL peut être basculé entre les backends en modifiant la clause « from » - OpenAI, Azure, HuggingFace Transformers, lama.cpp, Replicate sont tous pris en charge. Cela signifie que vous pouvez utiliser des modèles légers pour le débogage pendant la phase de développement et passer à des modèles plus volumineux pendant la phase de production sans modifier la logique de requête. Cependant, il convient de noter que différents backends ont différents niveaux de prise en charge du décodage des contraintes : l'API Completions d'OpenAI prend en charge le biais logit, tandis que l'API Chat a une prise en charge limitée des contraintes. Il s’agit d’une limitation qui doit être prise en compte lors de la sélection.

Comment utiliser LMQL

Le chemin d'utilisation de LMQL est divisé en trois étapes : "installation locale → écriture de requête → exécution et débogage", couvrant différents besoins, depuis les premiers utilisateurs rapides jusqu'à l'intégration en production.

Comment utiliser	Convient à la foule	Caractéristiques	Coût
Installation locale (pip)	Tous les développeurs	pip install lmql, s'exécute entièrement localement	Gratuit
IDE de terrain de jeu	Expérience rapide	Côté navigateur lmql.ai/playground, zéro installation	Gratuit
Intégration API (Python)	Développeurs d'applications	Intégrer dans des projets Python existants	Gratuit (facturé par API backend)
Privatisation + modèle local	Scénario de conformité des données	HuggingFace ou llama.cpp inférence locale	Gratuit (coût de la puissance de calcul du GPU)

Installation rapide avec Hello World :

pip installer lmql

Après l'installation, vous pouvez utiliser la commande « lmql Playground » pour démarrer l'IDE du navigateur ou écrire directement un fichier Python à exécuter.

importerlmql

# La requête LMQL la plus simple : les contraintes déclaratives
@lmql.query
par défaut bonjour() :
    '''lmql
    "Dites 'c'est un test' :[RÉPONSE]"
    où len(JETONS(RÉPONSE)) < 25
    '''
    retourner la RÉPONSE

imprimer(bonjour())

Configuration du backend OpenAI : Si vous utilisez le modèle OpenAI, vous devez définir la variable de contexte OPENAI_API_KEY, ou créer le fichier api.env dans le répertoire actuel :

openai-org : <identifiant de l'organisation>
openai-secret : <secret API>

Il est également possible d'utiliser les variables contextuelles spécifiques à LMQL LMQL_OPENAI_SECRET et LMQL_OPENAI_ORG.

Exécuter le programme LMQL :

• lmql Playground : lance l'IDE du navigateur (nécessite Node.js), y compris un exemple d'affichage et un panneau de débogage.
• lmql run <file>.lmql : exécute le fichier local .lmql.
• lmql serve-model : Démarrez le service API d'inférence du modèle HuggingFace local (cette commande doit être exécutée en premier lors de l'utilisation du modèle local).
• Intégration Python : intégrez des requêtes LMQL dans le code Python standard via le décorateur @lmql.query.

Exemple de sortie structurée (fonctionnalité d'aperçu des contraintes de type) :

importerlmql
à partir des classes de données importer une classe de données

@dataclass
Personne de classe :
    nom : str
    âge : entier
    travail : str

@lmql.query
def extract_person() :
    '''lmql
    "Alice est une ingénieure de 21 ans chez LMQL Inc.\n"
    "Structuré : [PERSON_DATA]\n"
    où type(PERSON_DATA) est Personne
    '''
    retourner PERSON_DATA

résultat = extrait_personne()
print(result) # Personne(name='Alice', age=21, job='ingénieur')

Intégration API : l'API Generations de LMQL 0.7 fournit une interface légère de génération et de notation sans avoir besoin d'écrire des requêtes LMQL complètes :

importerlmql

m : lmql.LLM = lmql.model("openai/gpt-3.5-turbo-instruct")
résultat = m.generate_sync("Bonjour", max_tokens=10)
print(result) # "Bonjour, je suis une femme de 23 ans."

Prix des produits pour LMQL

LMQL lui-même est entièrement open source et gratuit (licence Apache-2.0). La vraie différence dans la structure des coûts vient du backend LLM branché :

Côté C/Individuel : Zéro frais. Après avoir installé LMQL localement, si vous utilisez le modèle local de HuggingFace ou «llama.cpp», il n'y a pas de frais d'API et tout ce dont vous avez besoin est un PC pour l'exécuter. Si vous utilisez des backends cloud tels qu'OpenAI et Azure, vous devez prendre en charge les frais d'appel API. La couche de mise en cache de LMQL peut aider à réduire la consommation de jetons et indirectement à réduire les coûts back-end.

Intégration développeur/API : Aucune facturation d'appel pour la bibliothèque LMQL elle-même. Une fois que les développeurs ont intégré LMQL dans leurs applications, la consommation des jetons détermine directement la facture back-end. En prenant comme exemple OpenAI « gpt-3.5-turbo-instruct », le court-circuit contraint et le cache arborescent de LMQL peuvent réduire l'utilisation des jetons de 33 à 80 %, ce qui constitue la principale incitation économique à utiliser LMQL au lieu d'appeler directement l'API.

Entreprise/Privé : la licence Apache-2.0 de LMQL autorise toute utilisation commerciale, y compris la modification et la redistribution. Les entreprises peuvent déployer la combinaison LMQL + modèles locaux complètement hors ligne sans payer de frais d'API à un tiers. La structure des coûts à l'heure actuelle est la suivante : achat/location de serveurs GPU (tels que A100, H100), électricité, personnel d'exploitation et de maintenance et licence du modèle lui-même (selon le modèle sélectionné, les modèles open source tels que Llama sont gratuits, les modèles de niveau entreprise peuvent nécessiter des licences supplémentaires).

Dans l'ensemble, la valeur économique de LMQL ne réside pas dans "si l'utilisation de LMQL est coûteuse", mais dans "dans quelle mesure le coût des appels LLM peut être réduit en utilisant LMQL" - c'est une question qui nécessite des mesures dans des scénarios spécifiques.

Scénarios d'application de LMQL

Les capacités de LMQL se concentrent sur des scénarios techniques qui nécessitent un contrôle précis de la sortie LLM, des coûts de post-traitement réduits et une fiabilité de sortie améliorée.

• Extraction de données structurées : extrayez des données structurées au format JSON à partir de texte non structuré (e-mails, rapports, journaux de discussion). Les contraintes de type de LMQL garantissent le format correct des champs de sortie sans post-traitement régulier. Conseil de mise en œuvre : dans les scénarios de conformité réglementaire, vous pouvez d'abord utiliser des contraintes de type pour contraindre le format de sortie, puis combiner le certificat d'inférence pour enregistrer le lien d'inférence complet de chaque extraction à des fins de traçabilité d'audit.

• Pipeline LLM par lots et tâches ETL : dans les pipelines qui nécessitent la classification, la synthèse et l'extraction d'entités de gros lots de texte, la couche de mise en cache de LMQL peut réduire considérablement la consommation répétée de jetons. Par exemple, en effectuant une classification des sentiments sur 10 000 conversations du service client, le cache d'arborescence de LMQL réutilisera la sortie LLM du préfixe de requête, réduisant ainsi le nombre d'appels d'API d'environ 50 %. Conseils de mise en œuvre : vérifiez d'abord l'exactitude des contraintes sur un petit échantillon, puis exécutez-le dans son intégralité pour éviter les échecs de lots causés par des définitions de contraintes incorrectes.

• Prototype amélioré d'agent et d'outil : les actions LMQL (préversion) permettent à LLM d'appeler des fonctions externes (telles que des recherches, des calculs, des requêtes de base de données) lors de l'inférence. Bien que cette fonctionnalité soit en phase de préversion, elle fournit une méthode d'exploration à faible coût permettant à l'équipe technique de vérifier la faisabilité d'une « application LLM de style agent ». Conseil de mise en œuvre : La fonctionnalité d'aperçu est instable et son utilisation n'est pas recommandée dans les systèmes d'agent de niveau production. Il peut être utilisé comme outil de validation de principe lors de la phase de conception du prototype.

• Recherche comportementale et expériences LLM : la clause @distribution de LMQL peut obtenir la distribution de probabilité au niveau du jeton, et le certificat d'inférence peut enregistrer le contexte et les paramètres d'inférence complets. Pour les chercheurs en PNL et les ingénieurs Prompt, il s'agit d'un outil utile pour analyser le comportement des sorties LLM, tester les effets des contraintes et comparer différentes stratégies de décodage. Conseils de mise en œuvre : La fonction de certificat d'inférence a été introduite dans la version 0.7. Il s'agit d'une fonctionnalité stable qui convient aux expériences sur papier et aux comparaisons d'effets rapides.

Groupes applicables de LMQL

Le public de LMQL est concentré parmi les développeurs et les chercheurs dotés de fortes capacités techniques - il ne s'agit pas d'un outil « prêt à l'emploi », mais d'un ensemble de langages de programmation qui nécessitent un investissement dans les coûts d'apprentissage.

• Développeurs d'applications LLM : pour les développeurs qui créent des applications LLM nécessitant une sortie structurée ou un raisonnement en plusieurs étapes, les contraintes au niveau du langage de LMQL peuvent réduire considérablement le code de post-traitement et accélérer le temps de débogage. Prérequis : Nécessite une connaissance de la syntaxe Python et des concepts d'appel LLM de base.

• Chercheur AI/ML : un chercheur universitaire qui étudie le comportement de sortie du LLM et l'effet de décodage des contraintes. Distribution de probabilité des jetons. Le langage de contraintes et les certificats d'inférence de LMQL fournissent un contexte expérimental standardisé. Prérequis : Il est nécessaire de comprendre le contexte théorique de LMQL (masquage logit, décodage par recherche de faisceau).

• Ingénieur Prompt : praticiens qui ont besoin de tester fréquemment les limites des contraintes d'invite et de comparer différentes stratégies de décodage. L'IDE Playground et la couche de mise en cache de LMQL offrent une itération plus efficace que les appels d'API manuels. Précondition : Vous devez comprendre la différence entre la syntaxe déclarative et la syntaxe impérative.

• Ne convient pas au grand public : ① Scénarios qui nécessitent uniquement un simple dialogue ou une génération de texte et n'ont pas d'exigences strictes sur le format de sortie - La capacité de contrainte de LMQL ajoute une surcharge de syntaxe inutile ; ② Applications en temps réel extrêmement sensibles à la latence - le calcul de masquage logit introduit par le décodage par contrainte ajoutera une latence supplémentaire ; ③ Équipes qui préfèrent les outils low-code/no-code - LMQL est essentiellement un langage de programmation et nécessite l'écriture de code ; ④ Utilisez les scénarios de chat OpenAI où les modèles (gpt-3.5-turbo, gpt-4) servent de backend principal - l'API Chat d'OpenAI a une prise en charge limitée du biais logit et certaines contraintes LMQL ne peuvent pas prendre pleinement effet.

Résumé et perspectives de LMQL

Les compétences principales de LMQL et ses limites actuelles sont très claires. Le concept de « contrôle du LLM avec un langage de programmation » proposé par lui en 2023 est toujours tourné vers l'avenir aujourd'hui, et sa conception du décodage des contraintes et du cache d'arborescence a directement affecté plusieurs chaînes d'outils LLM ultérieures. Cependant, pour la sélection effective en 2026, le niveau d'activité actuel du projet doit être pris en considération.

Valeur fondamentale : LMQL est l'un des très rares projets qui résout le problème de contrôlabilité de LLM au « niveau du langage » plutôt qu'au « niveau de la bibliothèque ». Son mécanisme de décodage des contraintes est techniquement supérieur aux solutions d'ingénierie et de post-traitement rapides, et l'effet de sauvegarde des jetons de la couche cache dispose de données quantitatives vérifiables. Pour les applications LLM structurées à forte production, LMQL peut réduire considérablement la complexité du développement et les coûts de fonctionnement.

Limites actuelles : ① La principale période de développement active du projet reste en 2023, et la dernière version 0.7.3 a près de trois ans. Il manque une adaptation native et une optimisation des performances pour les nouveaux modèles (tels que la série GPT-4, la série Claude, la série Gemini) ; ② Les restrictions de l'API OpenAI Chat sur le biais logit entraînent l'indisponibilité de certaines capacités de contrainte de LMQL sur ce backend ; ③ Les fonctionnalités en avant-première (Actions, contraintes de type) restent au stade expérimental et n'ont pas évolué vers la stabilité ; ④ La taille de la communauté est limitée (4,2 000 étoiles), et l'intégration de tiers et le support écologique sont bien inférieurs à ceux des cadres traditionnels tels que LangChain et LlamaIndex.

Évaluation des risques d'approvisionnement/d'adoption : Si vous envisagez d'adopter LMQL en production en 2026, vous devez vous concentrer sur l'évaluation des points suivants : ① Activité du projet - Il est recommandé de vérifier l'engagement de GitHub et la fréquence de réponse des émissions au cours des 6 derniers mois pour confirmer si la maintenance communautaire répond aux exigences de financement pour les dépendances de production ; ② Compatibilité des modèles - Vérifiez la compatibilité du backend LLM cible (en particulier le modèle Chat) avec le décodage des contraintes LMQL, ce qui peut être effectué via Playground. Faites d'abord un test à petite échelle ; ③ Comparaison des alternatives - Guidance (Microsoft), Outlines, Instructor et autres projets similaires auront des itérations plus actives entre 2024 et 2026. Il est recommandé de comparer leur couverture fonctionnelle et leur activité de maintenance ; ④ Faisabilité à long terme - Si le projet n'a pas de mises à jour majeures pendant une longue période, il peut être nécessaire de positionner LMQL comme une « référence technique » plutôt que comme une « dépendance à long terme », et réserver un chemin de remplacement dans la conception de l'architecture. Pour les prototypes de recherche et les projets de développement personnel, LMQL reste le meilleur point d'entrée pour expérimenter le concept de « décodage par contraintes ».

Liste ouverte des outils (syntaxe LMQL et constructions de langage)

LMQL n'expose pas une interface RESTful Tool au sens traditionnel du terme, mais fournit un contrôle précis du comportement LLM via des constructions au niveau du langage. Voici les constructions syntaxiques de base qui peuvent être appelées directement dans les programmes LMQL :

• argmax / sample(temperature=1.2) / beam(N) / best_k : Contrôlez la stratégie de décodage. argmax est un décodage gourmand déterministe, sample introduit le caractère aléatoire, et beam et best_k utilisent la recherche de faisceau pour explorer plusieurs chemins de génération.
• Clause de contrainte where : Le mécanisme de contrainte de base au niveau du langage. Prend en charge len(TOKENS(VAR)) < N (contrainte de longueur du jeton), STOPS_AT(VAR, ".") (phrase d'arrêt), INT(VAR) (contrainte entière), REGEX(VAR, r"...") (contrainte régulière), type(VAR) est DataClass (contrainte de type).
• @lmql.query decorator : marque la fonction comme une requête LMQL. Prend en charge « modèle », « température », « cache » et d'autres paramètres, permettant au code LMQL d'appeler, de transmettre des paramètres et de renvoyer des valeurs comme les fonctions Python ordinaires.
• inline_use(VAR, [func1, func2]) : fonctionnalité de prévisualisation, exposant les fonctions Python externes que LLM doit appeler dans la boucle d'inférence. LMQL gère automatiquement le protocole d'appel et l'insertion des résultats.
• Boucle FOR et flux de contrôle : LMQL est un sur-ensemble de Python et prend en charge les flux de contrôle standard tels que for et if/else. Les variables de modèle peuvent être insérées dynamiquement dans la boucle pour obtenir une génération dynamique de longueur.
• @distribution : Obtenez la distribution de probabilité au niveau du jeton, qui est utilisée pour analyser la préférence de génération de LLM.
• @decorator : fonction de décorateur de variable personnalisée, qui peut effectuer une conversion en streaming sur la sortie du modèle (telle que la majuscule, le formatage, la conversion de type).
• Requête imbriquée [VAR : query_func] : appelez une autre fonction @lmql.query en tant que sous-requête dans la requête de niveau supérieur pour effectuer automatiquement le masquage des instructions et l'extraction des résultats.

Lien architectural

Code source LMQL (.lmql / @lmql.query)
    │
    ▼
analyseur LMQL
    │ (analyser la syntaxe LMQL en représentation intermédiaire)
    ▼
Interpréteur principal LMQL
    │ (Gérer le flux de contrôle, l'état des variables, l'enregistrement des contraintes)
    ▼
compilateur de contraintes
    │ (Compiler la clause Where dans le masque logit/filtre de jetons)
    ▼
couche d'adaptateur back-end
    │
    ├── Adaptateur OpenAI → API de complétion/chat OpenAI
    ├── Adaptateur Azure → API Azure OpenAI
    ├── Adaptateur HF → Transformateurs HuggingFace (local/à distance)
    ├── Adaptateur llama.cpp → moteur d'inférence llama.cpp C++
    └── Répliquer l'adaptateur → Répliquer l'inférence cloud
    │
    ▼
Décodeur de contraintes (masquage logit)
    │ (appliquer un filtre de contrainte avant chaque étape de décodage)
    ▼
Cache basé sur une arborescence
    │ (Jetons de cache, logits, métadonnées, prise en charge de la réutilisation des branches)
    │
    ▼
Boucle de génération/retour en plusieurs étapes
    │
    ▼
Sortie structurée/variables Python

Direction du flux de contrôle : code source LMQL → (analyse → exécution → contraintes → décodage) → backend LLM → (flux de jetons → vérification des contraintes → cache) → sortie Python. Chemin de retour des données : le flux de jetons généré par LLM est filtré par le décodeur de contraintes, enregistré par la couche de cache arborescente et finalement mappé à la valeur d'une variable Python.

Guide des pièges d'ingénierie

1. Boucle sans issue et contrôle de l'inflation des jetons : LMQL prend en charge la boucle « FOR » et le branchement conditionnel, mais si les contraintes ne sont pas correctement définies (par exemple, la phrase vide ne correspond pas ou la contrainte de longueur est trop lâche), cela peut amener LLM à générer un nombre illimité de jetons. Solution : définissez toujours une limite supérieure stricte de len(TOKENS(VAR)) < N dans la clause where ; définir un « max_tokens » raisonnable lors de l'utilisation de « sample » pour décoder ; pour les chaînes d'inférence à plusieurs étapes, définissez une limite sur le nombre total d'étapes dans le code Python externe.

2. Compatibilité des contraintes de l'API OpenAI Chat : le décodage des contraintes de LMQL est implémenté via le masquage logit, mais l'API Chat Completion d'OpenAI a une prise en charge limitée de logit_bias (seul l'ajustement du biais jusqu'à 20 jetons est pris en charge), ce qui entraîne des contraintes complexes qui ne prennent pas pleinement effet sur les modèles de la série « gpt-3.5-turbo » ou « gpt-4 ». Solution : donnez la priorité à l'utilisation du modèle d'API Completions d'OpenAI (tel que gpt-3.5-turbo-instruct) ou du modèle local HuggingFace pour obtenir une prise en charge complète du décodage des contraintes ; si vous devez utiliser le modèle Chat, positionnez LMQL comme « disposition des mots d'invite » plutôt que « application des contraintes ».

3. Extension du cache et gestion de la mémoire : le cache arborescent est une structure à ajout uniquement et continuera à croître sur une longue période, provoquant éventuellement un débordement de mémoire. Solution : désactivez la mise en cache (cache=False) dans les requêtes de longue durée ; utiliser des fichiers de cache persistants pour gérer par session ; définir une stratégie de nettoyage périodique du cache pour les applications liées à la production.

4. Différences de comportement des contraintes entre les backends : Le comportement de décodage du même morceau de code LMQL sur différents backends peut être incohérent - la couverture et la précision des contraintes sur HuggingFace sont plus élevées que sur OpenAI. Solution : effectuez le verrouillage du backend pendant la phase de développement et ne changez pas fréquemment de backend dans l'environnement de production ; si plusieurs backends doivent être pris en charge, écrivez des cas de test de requête indépendants pour chaque backend.

Démarrez rapidement en 3 minutes

# Installer LMQL (nécessite Python 3.10)
pip installer lmql

# Vérifier l'installation
lmql --aide

# hello.lmql ou utilisez-le directement en Python
importerlmql

# Méthode 1 : @lmql.query décorateur
@lmql.query
def saluer() :
    '''lmql
    "Salut LMQL :[SALUTATION]\n"
    où STOPS_AT(GREETING, ".") et non "\n" dans GREETING
    '''
    retour SALUT

imprimer(salut())

# Méthode 2 : lmql.run_sync (API de synchronisation)
programme = """
argmax
    "La capitale de la France est :[REPONSE]"
de
    "openai/text-davinci-003"
où
    STOPS_AT(ANSWER, ".") et len(TOKENS(ANSWER)) < 10
"""
résultat = lmql.run_sync (programme)
imprimer(résultat)

# Méthode 3 : Démarrer l'IDE Playground
# Exécuter dans le terminal : terrain de jeu lmql
# Accès au navigateur : http://localhost:3000

Configuration de déploiement (LMQL n'est pas exposé via le protocole MCP, mais est utilisé comme une bibliothèque Python sans fichier de configuration de serveur séparé. Pour un déploiement privé, vous pouvez vous référer à l'image Docker officielle) :

# Utilisez Docker pour exécuter LMQL Playground
docker run -p 3000:3000 lmql/lmql

Les exemples de code ci-dessus sont basés sur la documentation officielle de LMQL 0.7.x et sur GitHub README. Pour des détails spécifiques sur l'API et la syntaxe, veuillez vous référer au README de github.com/eth-sri/lmql et à la documentation officielle lmql.ai/docs. Pour les détails du fonctionnement réel tels que la méthode de configuration des informations d'identification de l'API OpenAI et les dernières balises de l'image Docker, veuillez vous référer aux dernières instructions du référentiel officiel.

Informations de version

• LMQL 0.7.3 ：Correction du problème selon lequel les ressources requises par l'API LMQL Chat ne sont pas incluses dans le package PyPI. Il s'agit d'une version de maintenance de la série 0.7. （2023-10-15）
• LMQL 0.7.2 ：Assurez-vous que la commande lmql Playground est correctement distribuée dans le cadre du package PyPI. （2023-10-13）
• LMQL 0.7.1 ：Correction de problèmes mineurs dans la version 0.7, notamment la compatibilité des clauses de distribution avec le suivi des inférences, l'optimisation automatique de chunk_size, etc. （2023-10-12）
• LMQL 0.7 ：La plus grande mise à jour, introduisant l'API de génération de requêtes imbriquées, l'API Chat, les certificats d'inférence, les décorateurs, la prise en charge multi-backend et les fonctions de prévisualisation telles que les actions, les contraintes régulières et les contraintes de type. （2023-10-10）
• LMQL 0.0.6.6 ：lmql.F prend en charge les paramètres de position, améliore la gestion des erreurs backend llama.cpp, corrige le problème d'utilisation élevée du processeur du planificateur LMTP sans charge et prend en charge le modèle de quantification auto_gptq. （2023-07-25）
• LMQL 0.0.6.5 ：Simplification majeure de la syntaxe : la syntaxe LMQL est plus proche du Python standard et les requêtes peuvent être écrites sur une seule ligne ; nouveau backend d'inférence llama.cpp, contraintes en ligne, décorateur de fonction @lmql.query, fonction lambda lmql.F. （2023-07-14）
• LMQL 0.0.6.4 ：La nouvelle prise en charge d'Azure OpenAI, le Language Model Transfer Protocol (LMTP) accélère l'inférence de modèle local de 5 à 6 fois et l'API Python synchrone prend en charge l'image Docker du backend de segmentation de mots tiktoken. （2023-06-08）
• LMQL 0.0.6.1 ：Corrections de bogues de la couche de cache, optimisation des phrases vides, point de terminaison de sortie HTTP/WebSocket/SSE de l'écrivain de sortie asynchrone. （2023-05-03）
• LMQL 0.0.6 ：En introduisant la couche de cache LMQL pour mettre en cache les jetons et les logits en fonction de la structure arborescente, les requêtes de modèle peuvent réduire la consommation de jetons de 77 % et le nombre de requêtes de 75 % ; le court-circuitage des contraintes peut réduire de 80 % la consommation de jetons dans les scénarios à contraintes longues. （2023-05-01）
• LMQL 0.0.5 ：Une première version stable, axée sur l'optimisation des performances et l'amélioration de la stabilité, et le premier lot de contributions de la communauté sont fusionnés. （2023-04-17）