Ajouter de l'IA à une application Ruby on Rails : par où commencer

La plupart des équipes n'ont pas besoin d'une « stratégie IA » pour commencer. Elles ont besoin d'une tâche concrète, lente, répétitive et tolérante à une erreur occasionnelle. Cet article explique comment choisir cette tâche et comment la brancher dans une application Rails existante sans créer une nouvelle catégorie de problèmes en production.

Partir d'une tâche, pas d'un modèle

La question « quel modèle utiliser ? » arrive trop tôt. Commencez par noter une tâche qu'une personne fait aujourd'hui à la main : trier des demandes entrantes, extraire des champs de documents, rédiger une première réponse, résumer un long fil de discussion. Demandez-vous ensuite ce qui se passe quand le résultat est faux. Si la réponse est « quelqu'un le corrige en dix secondes », la tâche est un bon premier candidat. Si la réponse est « de l'argent bouge », ce n'est pas le cas.

Trois schémas qui couvrent la plupart des premiers projets

• Traitement de documents et de texte : classification, extraction, résumé de contenus que vous stockez déjà.
• Questions-réponses sur vos propres données : récupérer les enregistrements pertinents, puis laisser un modèle répondre à partir de ceux-ci.
• Automatisation de workflows internes : un modèle prépare un brouillon ou une décision, une personne la valide.

Ne jamais appeler un modèle depuis une requête web

Les appels à un modèle sont lents, variables et échouent parfois. Les exécuter dans un contrôleur lie votre temps de réponse à la latence d'un tiers. Placez-les dans un job en arrière-plan, avec un timeout, des tentatives et une garde pour qu'une nouvelle tentative ne refasse pas un travail déjà terminé.

class ClassifyTicketJob
  include Sidekiq::Job
  sidekiq_options retry: 5

  def perform(ticket_id)
    ticket = Ticket.find(ticket_id)
    return if ticket.category.present?

    result = LlmClient.complete(
      prompt: TicketPrompt.build(ticket),
      timeout: 20,
      response_schema: TicketPrompt::SCHEMA
    )

    ticket.update!(category: result.fetch("category"), category_source: "model")
  end
end

Le retour anticipé rend le job sûr à rejouer. Le timeout empêche un fournisseur lent de remplir votre file. Le schéma et le fetch strict font échouer le job bruyamment quand la réponse n'est pas celle attendue, et la colonne source vous dit plus tard quelles valeurs viennent d'un modèle.

Traiter la sortie comme une entrée non fiable

Une réponse de modèle est un texte produit par un système que vous ne contrôlez pas. Validez-la avec un schéma, limitez-la aux valeurs que votre code accepte, et ne la transmettez jamais telle quelle à quoi que ce soit qui a des effets de bord. Pour les actions difficiles à annuler, gardez une personne dans la boucle et journalisez qui a validé quoi.

Garder le contrôle de vos données

Décidez ce qui a le droit de quitter vos systèmes avant le premier appel. Lisez les conditions du fournisseur sur la conservation et l'entraînement, retirez ce dont la tâche n'a pas besoin, et enregistrez les prompts, les réponses et les coûts pour pouvoir répondre aux questions plus tard. Les données personnelles méritent une décision délibérée, pas un réglage par défaut.

La recherche sur vos propres données

Pour les questions-réponses, vous n'avez généralement pas besoin d'une nouvelle base de données. PostgreSQL avec l'extension pgvector stocke les embeddings à côté des lignes qu'ils décrivent, ce qui garde permissions, sauvegardes et migrations au même endroit. Commencez par la recherche la plus simple qui retourne les bons enregistrements, et n'ajoutez de la mécanique que lorsque vous pouvez montrer qu'elle est le goulot d'étranglement.

Mesurer avec un petit jeu de test

Réunissez quelques dizaines d'exemples réels avec la réponse qu'une personne donnerait, et passez chaque changement de prompt ou de modèle dessus. Cela prend un après-midi, et remplace les opinions par un chiffre que vous pouvez suivre.

Si vous cherchez où l'IA a sa place dans votre produit, un court atelier de cadrage peut vous faire gagner des semaines d'essais dans le mauvais ordre. La page intégration IA explique comment nous le menons.