Keenable SELECT exécute du SQL sur le web pour extraire des données

Principe de fonctionnement

Keenable SELECT propose un agent capable d’interroger le Web via des requêtes SELECT classiques. L’utilisateur formule une question, par exemple « Which AI researchers moved between frontier labs since 2025 », puis le système traduit la demande en une instruction SQL qui combine les opérateurs WEB_SEARCH, SEM_EXTRACT et SEM_MATCH. Le moteur exécute la recherche sur plus de 1 000 pages, applique un filtre WHERE directement dans la requête, puis extrait les champs pertinents (nom du chercheur, laboratoire d’origine, nouveau laboratoire, mois du mouvement) avec un appel LLM limité à chaque ligne.

SELECT
  SEM_EXTRACT(content, 'researcher'),
  SEM_EXTRACT(content, 'left lab'),
  SEM_EXTRACT(content, 'joined lab'),
  SEM_EXTRACT(content, 'move month')
FROM WEB_SEARCH(8 diverse queries)
WHERE SEM_MATCH(content,
  'named researcher moving between frontier labs, 2025+')

Architecture technique

Le cœur du service est un serveur MCP qui expose un unique outil nommé select. Ce serveur délègue les opérations de recherche et de récupération (WEB_SEARCH, WEB_FETCH) à des modules externes, puis réinjecte leurs résultats sous forme de colonnes temporaires dans le jeu de lignes. La phase finale s’effectue dans DuckDB, une base de données analytique en‑memory, qui exécute le SELECT complet. Chaque jeu de résultats est stocké avec un identifiant unique, permettant aux requêtes subséquentes de le lire via generate_html_report. Le rapport HTML est produit par un second agent qui exécute du Python sandboxé, transforme les dataframes en HTML, puis renvoie le lien partageable.

Analyse des performances et des limites

En déplaçant le filtrage et la sélection dans la clause WHERE, le système évite de faire parcourir chaque page par le LLM, ce qui réduit le coût d’inférence proportionnel au nombre de pages (plus de 1 000 pages avec un seul appel). Cependant, chaque ligne nécessite toujours un appel SEM_EXTRACT, ce qui crée un facteur linéaire de consommation de tokens en fonction du nombre de résultats pertinents. Le modèle reste en lecture seule : aucune écriture ou mise à jour du Web n’est possible, ce qui limite les scénarios d’interaction dynamique. La latence dépend de la vitesse des opérateurs externes (API de recherche, extraction sémantique) et du temps de chargement de DuckDB, qui peut devenir un goulot d’étranglement pour des jeux de données supérieurs à plusieurs dizaines de milliers de lignes.

Cas d’usage et perspectives

Le showcase de Keenable SELECT montre des rapports automatisés où un agent de recherche collecte les données et un agent de rédaction génère le rendu final. Cette séparation permet de réutiliser les jeux de résultats dans plusieurs rapports, d’ajuster le budget d’exécution et de corriger les erreurs JavaScript détectées lors du rendu. À l’avenir, l’ajout de caches persistants pour les appels WEB_SEARCH ou l’intégration de modèles plus petits pour SEM_EXTRACT pourrait diminuer davantage le coût et la latence, tout en conservant la capacité de requêter le Web avec la syntaxe SQL familière.