dhanush kumar

10 questions que j'ai posées avant de construire notre agent de connaissances interne

· rag · ai-native

Also available in English →

Nous voulions un agent de connaissances interne : poser une question en langage naturel, obtenir une réponse ancrée dans notre Notion et notre Drive, avec les sources. La tentation était de commencer par la partie amusante — les embeddings, le retrieval, une interface de chat en streaming. J'ai déjà vu ce film, alors j'ai passé la première semaine à écrire des questions et à leur chercher des réponses.

Voici les dix, regroupées selon la manière dont elles ont réellement compté.

Périmètre

  1. Quelles sources dans la v1 ? Notion et Drive. C'est écrit, donc « est-ce qu'il peut aussi lire Slack » a une réponse : v2, peut-être.
  2. Quelles sources sont explicitement exclues ? Les emails, les tickets, les documents RH. « Explicitement exclu » n'est pas « pas mentionné » — ça survit à la réunion où quelqu'un pose la question.
  3. À quels types de questions doit-il bien répondre ? Les questions de process et de comment-faire. Pas d'analytics, pas de « résume le T3 ».

Permissions

  1. Qu'a-t-il le droit d'indexer ? Uniquement les documents déjà visibles par toute l'entreprise. Pas de réplication des permissions par utilisateur en v1 — cette seule décision a supprimé un mois de travail.
  2. Quel fournisseur de LLM est approuvé pour les données internes ? Celui que le juridique avait déjà validé, pas celui qui avait le meilleur benchmark cette semaine-là.
  3. Où tourne-t-il et qui paie ? Notre cloud, notre projet, une ligne budgétaire nommée. Un agent sans propriétaire devient un abandonware avec une clé d'API.

Succès

  1. Pour qui est-il fait, et combien sont-ils ? Objectif : 20 utilisateurs actifs par semaine. Un bot de wiki d'entreprise utilisé par cinq personnes est un projet raté qui continue de coûter de l'argent.
  2. À quoi ressemble une bonne réponse ? Ancrée dans une source, avec un lien, et honnête quand elle ne sait pas. Nous avons fixé la barre à 60 % de réponses jugées utiles.
  3. Que deviennent les questions sans réponse ? Elles sont journalisées et passées en revue — les questions sans réponse sont une carte de la documentation manquante. Ce rapport s'est révélé être la moitié de la valeur du projet.
  4. Quand est-ce qu'on l'arrête ? Si l'usage ou l'utilité reste sous l'objectif après deux mois, on l'éteint. Décidé à l'avance, quand personne n'était sur la défensive.

Ce n'est qu'après tout cela que nous avons écrit du code, et le code était presque ennuyeux : le périmètre était petit, le modèle de permissions trivial par construction, et le jeu d'evals découlait directement de la question 8.

La leçon que je ne cesse de réapprendre : les questions sont l'ingénierie. Le pipeline de retrieval a pris deux semaines. Obtenir dix réponses sur lesquelles tout le monde était d'accord, c'est ce qui a permis au projet de survivre au contact de l'entreprise.

← Tous les articles