Aller au contenu principal

Identifier les Endpoint de recherche IA inutilisés

Les Endpoint de recherche IA inutilisés consomment des Ressources et entraînent des coûts sans apporter de valeur. La table system.access.audit logs chaque appel d'API de recherche IA, afin que vous puissiez trouver les endpoints dont les index ne reçoivent aucun trafic de query et les nettoyer pour réduire les coûts.

Exigences

  • Un Workspace compatible avec Unity Catalog.
  • Accès à la table system.access.audit. Par default, seuls les administrateurs de compte ont accès. Pour accorder l’accès à d’autres utilisateurs, consultez la référence de la table système de log d’audit.
  • Un SQL Warehouse ou un compute serverless pour exécuter des queries.

Comment cela fonctionne

La table system.access.audit journalise chaque appel d'API AI Search comme un événement avec service_name = 'vectorSearch'. Ceci inclut la création d'index, la suppression, les requêtes, les upserts et les analyses.

Un seul Endpoint peut desservir plusieurs index. Pour trouver les endpoints inutilisés, comparez l'ensemble des index existants (créés mais non supprimés) avec l'ensemble des index ayant reçu du trafic de requête dans une fenêtre de temps donnée, puis agrégez au niveau de l'endpoint. Un endpoint est inutilisé seulement lorsqu'**aucun** de ses index n'a reçu de queries.

L'audit log conserve 365 jours de données, de sorte que vous pouvez consulter l'historique jusqu'à un an.

remarque

Le journal d'audit enregistre les queries au niveau de l'index, et non au niveau de l'Endpoint. Les queries de ce guide mappent les index à leurs Endpoints en utilisant le endpoint_name enregistré au moment de la création de l'index.

Rechercher les Endpoint inutilisés

La query suivante identifie les Endpoint où aucun index n'a reçu de queries au cours des 30 derniers jours. Il utilise les événements de logs d'audit pour déterminer quels index ont été créés, lesquels ont été supprimés et lesquels ont reçu du trafic de query, puis s'agrège au niveau de l'Endpoint.

important

Cette query détermine les index actifs en comparant les événements createVectorIndex et deleteVectorIndex dans le log d'audit. Si un index a été créé il y a plus de 365 jours (avant la fenêtre de rétention des logs d'audit), il n'apparaît pas dans les résultats. Pour une vue d'ensemble complète, recoupez ces résultats avec la sortie de la méthode SDK d'AI Search list_indexes.

SQL
WITH created_indexes AS (
-- All indexes created in the last year
SELECT DISTINCT
request_params['name'] AS index_name,
request_params['endpoint_name'] AS endpoint_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),

deleted_indexes AS (
-- Indexes that have been deleted
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'deleteVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),

active_indexes AS (
-- Indexes that exist (created but not deleted)
SELECT ci.index_name, ci.endpoint_name
FROM created_indexes ci
LEFT JOIN deleted_indexes di ON ci.index_name = di.index_name
WHERE di.index_name IS NULL
),

queried_indexes AS (
-- Indexes that received queries in the last 30 days
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'queryVectorIndexRouteOptimized',
'scanVectorIndex',
'scanVectorIndexRouteOptimized'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
),

index_status AS (
SELECT
ai.endpoint_name,
ai.index_name,
CASE WHEN qi.index_name IS NOT NULL THEN 1 ELSE 0 END AS is_queried
FROM active_indexes ai
LEFT JOIN queried_indexes qi ON ai.index_name = qi.index_name
)

SELECT
endpoint_name,
COUNT(*) AS total_indexes,
SUM(is_queried) AS queried_indexes,
COUNT(*) - SUM(is_queried) AS unqueried_indexes
FROM index_status
GROUP BY endpoint_name
HAVING SUM(is_queried) = 0 -- Only fully unused endpoints
ORDER BY total_indexes DESC

Trouver les index inutilisés dans les endpoints actifs

Même si un Endpoint sert activement des query pour certains index, il peut avoir d'autres index qui ne reçoivent aucun trafic. Ces index inutilisés consomment toujours des ressources sur l’Endpoint. La suppression des index inutilisés d'un Endpoint actif peut réduire son empreinte mémoire et l'empêcher de monter en puissance inutilement.

La requête suivante identifie les index individuels inutilisés, y compris ceux sur les Endpoint qui ont d’autres index actifs.

SQL
WITH created_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name,
request_params['endpoint_name'] AS endpoint_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),

deleted_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'deleteVectorIndex'
AND event_date >= current_date() - INTERVAL 365 DAYS
),

active_indexes AS (
SELECT ci.index_name, ci.endpoint_name
FROM created_indexes ci
LEFT JOIN deleted_indexes di ON ci.index_name = di.index_name
WHERE di.index_name IS NULL
),

queried_indexes AS (
SELECT DISTINCT
request_params['name'] AS index_name
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'queryVectorIndexRouteOptimized',
'scanVectorIndex',
'scanVectorIndexRouteOptimized'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
)

SELECT
ai.endpoint_name,
ai.index_name
FROM active_indexes ai
LEFT JOIN queried_indexes qi ON ai.index_name = qi.index_name
WHERE qi.index_name IS NULL
ORDER BY ai.endpoint_name, ai.index_name

Obtenir les détails de l'activité des query par index

Pour comprendre les query patterns de tous vos index, et pas seulement ceux qui sont inutilisés, utilisez la query suivante. Cette query trouve l'heure de la dernière query et le volume de query pour chaque index, aidant à identifier les index qui sont interrogés mais qui voient très peu de trafic et pourraient également être des candidats pour le nettoyage.

SQL
SELECT
request_params['name'] AS index_name,
MAX(event_time) AS last_query_time,
DATEDIFF(current_date(), DATE(MAX(event_time))) AS days_since_last_query,
COUNT(*) AS query_count_30d,
COUNT(DISTINCT DATE(event_time)) AS active_days_30d
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name IN (
'queryVectorIndex',
'queryVectorIndexNextPage',
'queryVectorIndexRouteOptimized',
'scanVectorIndex',
'scanVectorIndexRouteOptimized'
)
AND event_date >= current_date() - INTERVAL 30 DAYS
GROUP BY 1
ORDER BY last_query_time ASC

Identifiez qui a créé les Endpoint inutilisés

Pour trouver qui a créé les Endpoints qui servent des index inutilisés, utilisez la query suivante. Cela peut vous aider à contacter la bonne équipe pour le nettoyage.

SQL
SELECT
request_params['name'] AS endpoint_name,
user_identity.email AS created_by,
event_time AS created_at
FROM system.access.audit
WHERE service_name = 'vectorSearch'
AND action_name = 'createEndpoint'
AND event_date >= current_date() - INTERVAL 365 DAYS
ORDER BY event_time DESC

Personnaliser la fenêtre de rétrospection

Les exemples ci-dessus utilisent une fenêtre de 30 jours pour définir « inutilisé. » Ajustez la valeur INTERVAL en fonction de votre cas d'utilisation :

  • 30 jours : bonne default pour la plupart des charges de travail.
  • 7 jours : À utiliser pour les charges de travail qui doivent être interrogées quotidiennement.
  • 90 jours : utilisez-le pour les charges de travail par batch ou saisonnières qui s'exécutent moins fréquemment.

Remplacez INTERVAL 30 DAYS dans le CTE queried_indexes par la fenêtre de votre choix.

Étapes suivantes