# TC39 Temporal proposal – ça avance
par Alexandre Gille
Travailler sur les dates en JS n’a jamais été une sinécure. L’API n’est pas ergonomique et extrêmement error-prone.
Pas de gestion de TimeZone. Pas de Duration. Bon courage pour les calculs sur des dates sans notions d’heures sans représentation dédiée. La plupart des opérations basiques sur les dates peuvent s’avérer compliquées.
À tel point que la plupart des devs ayant besoin de gérer des dates se tournent vers des bibliothèques dédiées (feu moment.js, luxon…).
Temporal API à la rescousse
Heureusement, le sauveur qu’on attend tous arrive : la Temporal API.
Au menu :
- Une API ergonomique, beaucoup, beaucoup, beaucoup moins error prone, et bien plus feature-complete.
- Support des TimeZone.
- Tout est immuable.
- Des objets spécifiques dédiés Date, Time, DateTime, Duration et TimeZone.
Pour en apprendre plus sur l’API, n’hésitez pas à consulter la proposal, le cookbook ou la documentation.
Ce n’est malheureusement pas encore production ready mais ça avance !
La proposal est actuellement en stage 3. Des polyfills sont disponibles : https://github.com/tc39/proposal-temporal?#polyfills.
Une implémentation existe déjà côté Firefox, Safari et Chrome derrière un feature-flag, et Deno a ajouté un first-party support depuis sa version 1.40.
# Les bases de données orientées graphes, quel intérêt ?
par Olivier Beltramo-Martin
Si vous percevez dans l’IA générative une opportunité pour vos opérations ou votre entreprise — par exemple, à travers une application de Retrieval-Augmented Generation (RAG) — vous serez confronté, à un certain moment, au choix de la stack technique nécessaire pour couvrir vos besoins.
Ce choix inclura probablement la sélection d’une base de données vectorielle (VDB) à utiliser. Une VDB est déployée pour stocker des vecteurs obtenus à partir de la transformation de séquences (dans notre cas, des informations textuelles) via des modèles d’embeddings. Ces modèles sont entraînés (soit de manière indépendante, soit conjointement avec un modèle de langage de grande taille, ou LLM) à convertir une séquence en une liste de chiffres. La longueur de cette liste permet d’ajuster le compromis entre la sensibilité aux nuances sémantiques et le temps d’exécution.
Ces vecteurs sont ensuite comparés avec la représentation vectorielle de la requête pour identifier le contenu le plus pertinent. Des approches hybrides existent également, combinant à la fois la similarité vectorielle (par exemple, la distance cosinus) et la recherche de similarité sur le contenu textuel (via des algorithmes tels que TF-IDF ou BM25), ce qui entraîne un coût d’inférence supplémentaire tout en offrant une exactitude accrue des réponses générées.
Le choix de la VDB se fait généralement par habitude ; les utilisateurs de PostgreSQL pencheront vers PGVector.rs, tandis que d’autres pourraient rester sur Elasticsearch ou opter pour FAISS, développée par Meta. Parmi les différentes options, Neo4j (entre autres) propose une VDB orientée graphe. Quelles sont les différences et fonctionnalités distinctes de cette approche ?
La brique de base de Neo4j est le graphe, qui représente les relations entre les entités de départ (comme les documents, ou même des parties de documents). En une seule vue, il devient possible de comprendre comment les données du corpus sont organisées. Le graphe apporte donc une dimension supplémentaire à cette hiérarchisation par rapport à une recherche basée uniquement sur la similarité des vecteurs, qui calcule des distances entre points supposés indépendants alors qu’ils sont en réalité liés.
Ainsi, si les données sont stockées en clusters, le graphe permet d’identifier rapidement le groupe de documents le plus susceptible de répondre à la requête, optimisant ainsi le processus de retrieval sur de très grands corpus de données avec des relations entre documents complexes.
Laisser un commentaire