Jak jakość, koszt i opóźnienie są oceniane przez ocenę agenta

Ważne

Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

W tym artykule wyjaśniono, w jaki sposób ocena agenta ocenia jakość, koszt i opóźnienie aplikacji sztucznej inteligencji oraz udostępnia szczegółowe informacje na temat ulepszeń jakości oraz optymalizacji kosztów i opóźnień. Obejmuje ona następujące kwestie:

• Jak jakość jest oceniana przez sędziów LLM.
• Sposób oceniania kosztów i opóźnień.
• Jak metryki są agregowane na poziomie przebiegu platformy MLflow pod kątem jakości, kosztów i opóźnień.

Aby uzyskać informacje referencyjne dotyczące poszczególnych wbudowanych sędziów LLM, zobacz Mozaika AI Agent Evaluation LLM sędziów.

Jak jakość jest oceniana przez sędziów LLM

Ocena agenta ocenia jakość przy użyciu sędziów LLM w dwóch krokach:

1. Sędziowie LLM oceniają konkretne aspekty jakości (takie jak poprawność i uziemienia) dla każdego wiersza. Aby uzyskać szczegółowe informacje, zobacz Krok 1: Sędziowie LLM oceniają jakość każdego wiersza.
2. Ocena agenta łączy oceny poszczególnych sędziów w ogólny wynik powodzenia/niepowodzenia i główną przyczynę wszelkich niepowodzeń. Aby uzyskać szczegółowe informacje, zobacz Krok 2. Łączenie ocen sędziów LLM w celu zidentyfikowania głównej przyczyny problemów z jakością.

Aby uzyskać informacje o zaufaniu i bezpieczeństwie sędziego LLM, zobacz Informacje o modelach, które napędzają sędziów LLM.

Krok 1. Sędziowie LLM oceniają jakość każdego wiersza

W przypadku każdego wiersza danych wejściowych ocena agenta używa zestawu sędziów LLM do oceny różnych aspektów jakości danych wyjściowych agenta. Każdy sędzia generuje wynik tak lub nie i pisemne uzasadnienie dla tego wyniku, jak pokazano w poniższym przykładzie:

Aby uzyskać szczegółowe informacje na temat używanych sędziów LLM, zobacz Dostępne sędziowie LLM.

Krok 2. Łączenie ocen sędziów LLM w celu zidentyfikowania głównej przyczyny problemów z jakością

Po uruchomieniu sędziów LLM ocena agenta analizuje swoje dane wyjściowe, aby ocenić ogólną jakość i określić ocenę jakości pass/fail na zbiorczych ocenach sędziego. Jeśli ogólna jakość nie powiedzie się, ocena agenta identyfikuje, który konkretny sędzia LLM spowodował awarię i zawiera sugerowane poprawki.

Dane są wyświetlane w interfejsie użytkownika platformy MLflow i są również dostępne w przebiegu MLflow w ramce mlflow.evaluate(...) danych zwracanej przez wywołanie. Zobacz dane wyjściowe oceny, aby uzyskać szczegółowe informacje na temat uzyskiwania dostępu do ramki danych.

Poniższy zrzut ekranu jest przykładem analizy podsumowania w interfejsie użytkownika:

Wyniki dla każdego wiersza są dostępne w interfejsie użytkownika widoku szczegółów:

Dostępni sędziowie LLM

Poniższa tabela zawiera podsumowanie zestawu sędziów LLM używanych w ocenie agenta do oceny różnych aspektów jakości. Aby uzyskać więcej informacji, zobacz Sędziowie odpowiedzi i sędziowie pobierania.

Aby uzyskać szczegółowe informacje o modelach, które zasilają sędziów LLM, zobacz Informacje o modelach obsługujących sędziów LLM. Aby uzyskać informacje referencyjne dotyczące poszczególnych wbudowanych sędziów LLM, zobacz Mozaika AI Agent Evaluation LLM sędziów.

Nazwisko sędziego	Krok	Aspekt jakości oceniany przez sędziego	Wymagane dane wejściowe	Wymaga podstawowej prawdy?
relevance_to_query	Response	Czy adres odpowiedzi (jest istotny dla) żądania użytkownika?	- response, request	Nie.
groundedness	Response	Czy wygenerowana odpowiedź jest uziemiona w pobranym kontekście (nie halucynacja)?	- response, trace[retrieved_context]	Nie.
safety	Response	Czy w odpowiedzi występuje szkodliwa lub toksyczna zawartość?	- response	Nie.
correctness	Response	Czy wygenerowana odpowiedź jest dokładna (w porównaniu z prawem podstawy)?	- response, expected_response	Tak
chunk_relevance	Pobieranie	Czy retriever znalazł fragmenty, które są przydatne (istotne) w odpowiedzi na żądanie użytkownika? Uwaga: Ten sędzia jest stosowany oddzielnie do każdego pobranego fragmentu, tworząc wynik i uzasadnienie dla każdego fragmentu. Te wyniki są agregowane w chunk_relevance/precision wynik dla każdego wiersza, który reprezentuje % fragmentów, które są istotne.	- retrieved_context, request	Nie.
document_recall	Pobieranie	Ile znanych istotnych dokumentów znalazło program retriever?	- retrieved_context, expected_retrieved_context[].doc_uri	Tak
context_sufficiency	Pobieranie	Czy program retriever znalazł dokumenty z wystarczającą ilością informacji, aby wygenerować oczekiwaną odpowiedź?	- retrieved_context, expected_response	Tak

Na poniższych zrzutach ekranu przedstawiono przykłady wyświetlania tych sędziów w interfejsie użytkownika:

Jak określana jest główna przyczyna

Jeśli wszyscy sędziowie uchwalą, jakość jest uważana za pass. Jeśli jakikolwiek sędzia nie powiedzie się, główna przyczyna jest określana jako pierwsza sędzia, która nie powiodła się na podstawie listy uporządkowanej poniżej. To uporządkowanie jest używane, ponieważ oceny sędziów są często skorelowane w sposób przyczynowy. Na przykład jeśli context_sufficiency oceni, że element pobierający nie pobrał odpowiednich fragmentów lub dokumentów dla żądania wejściowego, prawdopodobnie generator nie zsyntetyzuje dobrej odpowiedzi i dlatego correctness również zakończy się niepowodzeniem.

Jeśli jako dane wejściowe podano podstawowe informacje, używana jest następująca kolejność:

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. Dowolny sędzia LLM zdefiniowany przez klienta

Jeśli nie podano podstawy prawdy jako danych wejściowych, używana jest następująca kolejność:

1. chunk_relevance - czy istnieje co najmniej 1 odpowiedni fragment?
2. groundedness
3. relevant_to_query
4. safety
5. Dowolny sędzia LLM zdefiniowany przez klienta

Jak usługa Databricks utrzymuje i poprawia dokładność sędziego LLM

Usługa Databricks jest przeznaczona do zwiększania jakości naszych sędziów LLM. Jakość jest oceniana przez pomiar tego, jak dobrze sędzia LLM zgadza się z wskaźnikami ludzkimi, używając następujących metryk:

• Zwiększone Kappa Cohena (miara umowy między rater).
• Zwiększona dokładność (procent przewidywanych etykiet, które pasują do etykiety człowieka ratera).
• Zwiększony wynik F1.
• Zmniejszona liczba wyników fałszywie dodatnich.
• Obniżona fałszywie ujemna stopa.

Aby mierzyć te metryki, usługa Databricks używa różnych, trudnych przykładów z zestawów danych akademickich i zastrzeżonych, które są reprezentatywne dla zestawów danych klientów w celu oceny porównawczej i ulepszania sędziów przed najnowocześniejszymi metodami sędziego LLM, zapewniając ciągłą poprawę i wysoką dokładność.

Aby uzyskać więcej informacji na temat sposobu, w jaki usługa Databricks mierzy i stale poprawia jakość sędziów, zobacz Databricks ogłasza znaczące ulepszenia wbudowanych sędziów LLM w ocenie agenta.

Wypróbuj sędziów przy użyciu zestawu databricks-agents SDK

Zestaw databricks-agents SDK zawiera interfejsy API do bezpośredniego wywoływania sędziów w danych wejściowych użytkownika. Możesz użyć tych interfejsów API do szybkiego i łatwego eksperymentu, aby zobaczyć, jak działają sędziowie.

Uruchom następujący kod, aby zainstalować databricks-agents pakiet i ponownie uruchomić jądro języka Python:

%pip install databricks-agents -U
dbutils.library.restartPython()

Następnie możesz uruchomić następujący kod w notesie i edytować go w razie potrzeby, aby wypróbować różnych sędziów na własnych danych wejściowych.

from databricks.agents.eval import judges

SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
        {
            "content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
        }
    ]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."

# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
  request=SAMPLE_REQUEST,
  expected_response=SAMPLE_EXPECTED_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  expected_response=SAMPLE_EXPECTED_RESPONSE
)

# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For safety, the required inputs are `request` and `response`.
judges.safety(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

Ocenianie kosztów i opóźnień

Ocena agenta mierzy liczbę tokenów i opóźnienie wykonywania, aby ułatwić zrozumienie wydajności agenta.

Koszt tokenu

Aby ocenić koszt, ocena agenta oblicza łączną liczbę tokenów we wszystkich wywołaniach generacji LLM w śladzie. Jest to przybliżony całkowity koszt podany jako więcej tokenów, co zwykle prowadzi do większego kosztu. Liczby tokenów są obliczane tylko wtedy, gdy trace element jest dostępny. model Jeśli argument zostanie uwzględniony w wywołaniu metody mlflow.evaluate(), zostanie automatycznie wygenerowany ślad. Możesz również bezpośrednio podać kolumnę trace w zestawie danych oceny.

Następujące liczby tokenów są obliczane dla każdego wiersza:

Pole danych	Type	Opis
total_token_count	integer	Suma wszystkich tokenów wejściowych i wyjściowych we wszystkich zakresach LLM w śladzie agenta.
total_input_token_count	integer	Suma wszystkich tokenów wejściowych we wszystkich zakresach LLM w śladzie agenta.
total_output_token_count	integer	Suma wszystkich tokenów wyjściowych we wszystkich zakresach LLM w śladzie agenta.

Opóźnienie wykonywania

Oblicza opóźnienie całej aplikacji w sekundach dla śledzenia. Opóźnienie jest obliczane tylko wtedy, gdy ślad jest dostępny. model Jeśli argument zostanie uwzględniony w wywołaniu metody mlflow.evaluate(), zostanie automatycznie wygenerowany ślad. Możesz również bezpośrednio podać kolumnę trace w zestawie danych oceny.

Dla każdego wiersza obliczana jest następująca miara opóźnienia:

Nazwa/nazwisko	opis
latency_seconds	Kompleksowe opóźnienie na podstawie śladu

Jak metryki są agregowane na poziomie przebiegu platformy MLflow pod kątem jakości, kosztów i opóźnień

Po obliczeniu wszystkich ocen jakości, kosztów i opóźnień dla poszczególnych wierszy ocena agenta agreguje te asessments do metryk na przebieg, które są rejestrowane w przebiegu platformy MLflow i podsumowują jakość, koszt i opóźnienie agenta we wszystkich wierszach wejściowych.

Ocena agenta tworzy następujące metryki:

Nazwa metryki	Type	Opis
retrieval/llm_judged/chunk_relevance/precision/average	float, [0, 1]	Średnia wartość chunk_relevance/precision wszystkich pytań.
retrieval/llm_judged/context_sufficiency/rating/percentage	float, [0, 1]	% pytań, w których context_sufficiency/rating jest oceniana jako yes.
response/llm_judged/correctness/rating/percentage	float, [0, 1]	% pytań, w których correctness/rating jest oceniana jako yes.
response/llm_judged/relevance_to_query/rating/percentage	float, [0, 1]	% pytań, w których relevance_to_query/rating ocenia się jako yes.
response/llm_judged/groundedness/rating/percentage	float, [0, 1]	% pytań, w których groundedness/rating jest oceniana jako yes.
response/llm_judged/safety/rating/average	float, [0, 1]	% pytań, w których ocenia się safety/rating jako yes.
agent/total_token_count/average	int	Średnia wartość total_token_count wszystkich pytań.
agent/input_token_count/average	int	Średnia wartość input_token_count wszystkich pytań.
agent/output_token_count/average	int	Średnia wartość output_token_count wszystkich pytań.
agent/latency_seconds/average	float	Średnia wartość latency_seconds wszystkich pytań.
response/llm_judged/{custom_response_judge_name}/rating/percentage	float, [0, 1]	% pytań, w których {custom_response_judge_name}/rating jest oceniana jako yes.
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average	float, [0, 1]	Średnia wartość {custom_retrieval_judge_name}/precision wszystkich pytań.

Na poniższych zrzutach ekranu pokazano, jak metryki są wyświetlane w interfejsie użytkownika:

Informacje o modelach, które napędzają sędziów LLM

• Sędziowie LLM mogą korzystać z usług innych firm do oceny aplikacji GenAI, w tym azure OpenAI obsługiwanych przez firmę Microsoft.
• W przypadku usługi Azure OpenAI usługa Databricks zrezygnowała z monitorowania nadużyć, więc w usłudze Azure OpenAI nie są przechowywane żadne monity ani odpowiedzi.
• W przypadku obszarów roboczych Unii Europejskiej (UE) sędziowie LLM używają modeli hostowanych w UE. Wszystkie inne regiony używają modeli hostowanych w Stanach Zjednoczonych.
• Wyłączenie funkcji pomocniczych sztucznej inteligencji opartej na sztucznej inteligencji platformy Azure uniemożliwia sędziego LLM wywoływanie modeli opartych na sztucznej inteligencji platformy Azure.
• Dane wysyłane do sędziego LLM nie są używane do trenowania modelu.
• Sędziowie LLM mają pomóc klientom ocenić swoje aplikacje RAG, a wyniki sędziów LLM nie powinny być używane do trenowania, ulepszania ani dostrajania LLM.