Depuração do erro 'Invariant failed: context-faithfulness assertion requires string output from the provider' em avaliação de LLM com RAG

Contexto: Você é um engenheiro de ML responsável por depurar um pipeline de avaliação de LLMs usando um sistema de Recuperação com Geração (RAG). O cenário envolve avaliar um LLM finetunado no mesmo pipeline do modelo base, usando a avaliação PromptFoo. Durante a configuração da métrica de context-faithfulness, ocorreu o erro: 'Invariant failed: context-faithfulness assertion requires string output from the provider'. O fluxo utiliza a geração de testes a partir de um arquivo jsonl via um gerador de testes implementado em create_tests.py. Ao adicionar a métrica de context-faithfulness, o avaliador falha durante a avaliação com o payload de erro: { "providerId": "file://providers/provider_base_model.py", "providerLabel": "base", "promptIdx": 0, "testIdx": 0, "error": { "name": "Error", "message": "Invariant failed: context-faithfulness assertion requires string output from the provider" } }. O código de reprodução relevante envolve conig.yml (configuração de RAFT-Fine-Tuned-Adapter-Evaluation) e describe: RAFT-Fine-Tuned-Adapter-Evaluation, commandLineOptions, envPath: .env.local.

Instruções:
- Analise as causas prováveis desse erro (padrões de saída do provider, tipos de dados, serialização, ou validação de tipos na verificação de context-faithfulness).
- Forneça um plano de diagnóstico passo a passo com comandos úteis para logs, verificação de tipos e reprodução do erro, incluindo exemplos de mensagens de log esperadas.
- Proponha patches de código concretos (em Python) para garantir que a saída do provider seja convertida para string antes da asserção de context-faithfulness (inclua uso de str() e serialização JSON quando necessário).
- Sugira testes unitários e de integração para evitar regressões futuras (inclua esboços de testes que valida a saída do provider como string).
- Apresente uma estratégia de fallback caso o provider ocasionalmente retorne formatos não-string (por exemplo, como adaptar a verificação para aceitar saídas serializadas) sem comprometer a validade da métrica.
- Inclua perguntas rápidas para clarificar o ambiente (versões, configuração de prompts, formato esperado da saída).
- Ao final, forneça um resumo com 5 ações prioritárias e uma lista de verificação para evitar esse problema no futuro.

Exemplos de saída desejados (para guiar a correção):
- Verifique a função que consome o provider: se o retorno não for string, aplique serialização (por exemplo, json.dumps()) ou str() antes da asserção.
- Adicione validação explícita de tipo antes da verificação de context-faithfulness, com mensagens de erro mais detalhadas.
- Garanta que o test generator em create_tests.py produza saídas compatíveis com a expectativa de string.
- Adote logs estruturados (nivel de log, conteúdo da saída do provider, tipo de dados) para facilitar a reprodução.
- Documente as expectativas de saída no conig.yml e nos contratos entre os componentes.

Formato de saída sugerido para a correção (exemplo):
- Patch de código (provider wrapper):
  def call_provider(...):
      out = real_call(...)
      if not isinstance(out, str):
          try:
              import json
              out = json.dumps(out)
          except Exception:
              out = str(out)
      return out
- Verificação de context-faithfulness (exemplo hipotético):
  output = call_provider(...)
  if not isinstance(output, str):
      raise TypeError(f"context-faithfulness requires string output, got {type(output)}")
- Teste unitário mínimo: test_provider_output_is_string
  def test_provider_output_is_string():
      out = call_provider(...)
      assert isinstance(out, str)

Observações: Ajuste as referências de caminho e nomes de funções conforme o código real do seu repositório. Priorize preservar a semântica da métrica de context-faithfulness enquanto garante que a saída esteja no formato esperado. Priorize versões estáveis de dependências e inclua logs que facilitem o diagnóstico ao reproduzir o erro.