Naar de inhoud springen

Zoek in de documentatie

Typ om elke pagina van de documentatie te doorzoeken.

Documentatiemenu
GidsDoelgroep · Ontwikkelaars, onderzoekers & bijdragers

Testen & simulaties

Twee harnesses: integratietests op echte infrastructuur en agentsimulaties met LLM-as-judge

Deze pagina is automatisch vanuit het Engels vertaald. Bij verschillen geldt het origineel.Het origineel in het Engels lezen

Het testen van agents is een volwaardige functie van het framework, geen bijzaak. Agent-Lab bevat twee complementaire harnesses waarmee je zowel het framework zelf kunt valideren als de agents die je erop bouwt:

  • Integratietests testen het systeem tegen echte infrastructuur (Postgres, Redis, Keycloak, embeddings, headless Chrome) die op aanvraag wordt opgestart met testcontainers — en dekken externe services, databasebewerkingen, vector search en API-endpoints af.
  • Agentsimulaties evalueren het gedrag van agents end-to-end tegen live LLM's, beoordeeld door een LLM-as-judge en in de tijd gevolgd in Langfuse en LangWatch.

De belangrijkste configuratie voor integratietests staat in tests/conftest.py; pas die aan je omgeving aan.

Let op: integratietests en simulaties doen echte aanroepen naar externe services en kunnen kosten met zich meebrengen. Voer ze uit in een gecontroleerde omgeving en houd het gebruik in de gaten.

Integratietests

Vereist Docker (of een andere container-runtime) — de suite richt echte containers in via testcontainers.

make test_unit         # fast lane: boots the app with no infrastructure
make test_integration  # the full real-infrastructure suite
make test              # both, with coverage (gate: 90%)

De eerste uitvoering kan enkele minuten duren — Docker-images en embeddingmodellen worden eenmalig gedownload. De coverage van agent_lab/ wordt in CI afgedwongen (SonarCloud).

De gescaffolde projecten doen hetzelfde: tests/ bevat smoketests zonder containers plus een optionele testcontainers-suite.

Agentsimulaties

End-to-end-agentsimulaties staan in tests/simulation/ en roepen live LLM-providers aan. Ze zijn gemarkeerd met agent_test en worden standaard overgeslagen; voer ze uit met:

make test_simulations
# or a single track:
make scenario_simulation
make langwatch_simulation
make langfuse_simulation

Drie complementaire tracks delen de bootstrap-helpers voor agents, de judge en de datasetdefinities onder tests/simulation/datasets/:

  • tests/simulation/scenario/ — conversationele simulaties met het langwatch-scenario-framework: een gebruikerssimulator stuurt de agent aan terwijl een judge-agent de interactie beoordeelt.
  • tests/simulation/langfuse/ — datasetgestuurde experimenten met Langfuse-datasets. Elke run synchroniseert de datasetdefinities, roept de agent per item aan, beoordeelt de output met een client-side LLM-as-judge en legt de run en de scores vast in Langfuse, zodat je ze in de tijd kunt vergelijken. Wordt automatisch overgeslagen als LANGFUSE_BASE_URL (of het verouderde LANGFUSE_HOST), LANGFUSE_PUBLIC_KEY en LANGFUSE_SECRET_KEY niet zijn ingesteld.
  • tests/simulation/langwatch/ — dezelfde datasetexperimenten, gespiegeld naar LangWatch via langwatch.experiment, waarbij per item de score van de judge wordt gelogd. Definities worden idempotent gesynchroniseerd naar één geconsolideerde simulations-dataset (een dataset-kolom geeft de brondefinitie aan, omdat het gratis abonnement van LangWatch maximaal 3 datasets per project toestaat). Wordt automatisch overgeslagen als LANGWATCH_ENDPOINT en LANGWATCH_API_KEY niet zijn ingesteld.

De referentieagents die in de tracks aan bod komen: de coordinator-planner-supervisor-, react RAG-, vision/document-, browserautomatiserings-, voice memos- en adaptive RAG-agents.

LLM-configuratie van judge en agent

De judge (en de gebruikerssimulator van scenario) gebruiken litellm-model-id's tegen elk OpenAI-API-compatibel endpoint:

Omgevingsvariabele Standaard Doel
SIMULATION_JUDGE_MODEL openai/gpt-5-nano litellm-model-id dat de LLM-as-judge gebruikt
SIMULATION_JUDGE_API_BASE standaard van provider eigen OpenAI-compatibel endpoint voor het judge-model
SIMULATION_JUDGE_API_KEY standaard van provider API-sleutel voor het eigen endpoint

De geteste agents draaien op een standaard-LLM die wordt aangeboden door een willekeurig OpenAI-compatibel endpoint (bijv. een inferentieserver in het LAN), per test ingericht door tests/simulation/common/llm_factory.py. De uitzondering is de voice memos-agent, die op OpenAI blijft (die heeft audio-invoer in de chat nodig). Embeddings blijven de EMBEDDINGS_ENDPOINT-fallback gebruiken (de Ollama-testcontainer die bge-m3 aanbiedt), passend bij de pgvector-dump. Het endpoint moet tool calling / structured output ondersteunen voor de suites op basis van een supervisor (browserautomatisering, supervisor):

Omgevingsvariabele Standaard Doel
SIMULATION_LLM_MODEL geen (verplicht) modeltag die de simulaties uitvoert (bijv. qwen3:30b)
SIMULATION_LLM_API_BASE geen (verplicht) OpenAI-compatibel endpoint dat het model aanbiedt
SIMULATION_LLM_API_KEY dummy-key API-sleutel, als het endpoint er een vereist

De evaluatieplatforms inrichten

make test_simulations (en de targets per track) voeren eerst de stap sync_simulation_evals uit, die de datasetdefinities spiegelt naar elk geconfigureerd platform. Om ook de server-side evaluatiesetup van Langfuse in te richten (een LLM-verbinding voor het judge-model, een simulation_llm_as_judge-evaluator en één evaluatieregel per simulatiedataset — zichtbaar in de sectie Evaluations van Langfuse), voer je uit:

uv run python tests/setup_simulation_evals.py

Het script is idempotent en kan veilig opnieuw worden uitgevoerd.