Model Router peut être compris comme une couche de planification qui « vous aide à décider quel modèle utiliser en premier ». Il ne répond pas directement aux questions, mais distribue les requêtes vers des modèles ou fournisseurs plus adaptés en fonction du type de tâche, du budget, des exigences de vitesse, de la longueur du contexte, des exigences de l’outil, etc., après l’entrée de la requête dans le système. Récemment, ce concept est devenu de plus en plus populaire car le multi-modèle est passé d’une question à choix multiples à une question opérationnelle, et de nombreux produits ne peuvent plus s’appuyer sur un seul modèle pour dominer le monde.
Au début, de nombreuses équipes étaient très simples : choisir le modèle le plus fort et l’utiliser dans tous les scénarios. Le problème a rapidement été révélé. Des tâches simples avec le modèle le plus coûteux : le gaspillage ; Les tâches en contexte long donnent des modèles de fenêtres courtes et plantent ; Les scènes en temps réel nécessitant une faible latence sont des modèles lents et offrent une expérience médiocre. En conséquence, de plus en plus d’équipes ont commencé à ajouter un routeur à l’avant du modèle, permettant au système de trier d’abord, puis de décider qui répondrait.
Un bon modèle de routeur combine généralement plusieurs types de signaux. Par exemple, la question est de savoir si c’est du code, si c’est mathématique, s’il s’agit d’un long document, d’une tâche vocale en temps réel, quel fournisseur est actuellement moins cher ou plus stable, si un modèle a déclenché une limite de courant, et si le contexte a dépassé le seuil. C’est en réalité un compromis en temps réel : trouver une meilleure solution entre qualité, coût et latence.
C’est aussi l’une des différences entre celui-ci et le modèle. La passerelle est une entrée d’infrastructure responsable de l’authentification unifiée, de la journalisation, de la facturation et des interfaces compatibles. Le routeur prend davantage la décision et décide « qui y va cette fois ». Bien sûr, les deux apparaissent souvent ensemble dans le système réel, donc tout le monde en discute ensemble.
Pourquoi est-ce de plus en plus proche de la norme ? Parce que l’écologie du modèle est trop rapide. De nouveaux modèles sortent constamment, les prix changent constamment, et les limites des capacités évoluent également. Si le produit écrit toujours un modèle d’ordre mort, la vitesse d’itération sera ralentie ; Une fois la couche de routage indépendante, l’équipe peut changer de modèle plus flexiblement, faire des A/B, contrôler les coûts et gérer les résultats financiers. Pour les applications entreprises, c’est plus réaliste que de simplement poursuivre le modèle le plus solide.
Mais le routeur ne l’ajoute pas simplement. Cela nécessite des critères d’évaluation, une logique de secours, un suivi et un support des données historiques. Des règles de routage écrites trop dangereuses rendront le système de plus en plus complexe ; Laisser cela à un autre modèle de routage peut ajouter des coûts et de la latence supplémentaires. Ce qui est encore plus problématique, c’est qu’une fois la route erronée, les utilisateurs se demandent généralement « comment ce produit a-t-il pu devenir stupide aujourd’hui », et réalisent rarement qu’il y a un problème avec la stratégie de triage.
Ainsi, la popularité de Model Router montre que l’orientation de l’industrie s’est déplacée de « la disponibilité de modèles » à « comment organiser les capacités multi-modèles ». À l’avenir, de nombreux produits d’IA ressemblent à un assistant, mais derrière cela se trouve en réalité plus un système de planification. Les utilisateurs ne voient que la réponse, et c’est souvent la couche de routage qui prend vraiment la décision en premier.
