4.5 — Apresentação Técnica: Defendendo Decisões de Arquitetura e Produto (Pitch Técnico)

Minuto 0-1: Problema (não a solução)

  "Advogados perdem 2h/dia procurando cláusulas específicas em contratos PDF.

   Antes desta solução, a busca era manual — palavra por palavra."



Minuto 1-2: Demo ao vivo — happy path

  Mostrar o fluxo mais simples que resolve o problema central.

  NÃO abrir terminais, NÃO mostrar código durante a demo.

  Preparar todos os arquivos de exemplo com antecedência.



Minuto 3-5: Caso real com dados reais

  Usar um documento do domínio real (não "exemplo.pdf")

  Fazer uma pergunta que a audiência reconhece como difícil

  Mostrar a resposta COM a fonte citada



Minuto 5-7: Arquitetura (1 slide, máximo)

  "RAG com pgvector, Claude para geração, streaming via SSE"

  Focar em por que cada decisão foi tomada, não no que é

  "Escolhi pgvector em vez de Pinecone para não depender de serviço externo"



Minuto 7-9: Métricas e limitações

  Mostrar números reais (recall@5, latência mediana, custo/query)

  Antecipar a limitação mais óbvia: "o que acontece com documentos escaneados?"



Minuto 9-10: Próximos passos (honesto)

  O que você construiria se tivesse mais 2 semanas

  "Fine-tuning para vocabulário jurídico" vs "mais UX"

Recall@5: dos 5 chunks recuperados, quantos % contêm a resposta correta?

  Medido com: conjunto de 20 pares (pergunta, resposta esperada)

  Meta mínima: >80%



Latência end-to-end (P50, P95):

  Do click do usuário até primeiro token na tela

  Meta: P50 < 2s, P95 < 5s



Custo por conversa:

  Tokens input × preço + tokens output × preço

  Meta: < R$0.10 por conversa (R$0.50/dia para usuário ativo)



Taxa de citação de fonte:

  % das respostas que incluem referência ao documento/página

  Meta: >90% (indica que o modelo está usando o RAG, não hallucinating)

Formato: "Escolhi X porque Y. A alternativa seria Z, mas traria W."



Exemplo 1 — Vector DB:

"Escolhi pgvector porque já usamos PostgreSQL e evita dependência externa.

A alternativa seria Pinecone, que oferece melhor performance em escala (>1M vetores),

mas adiciona custo ($70+/mês) e um ponto de falha externo que não é necessário no MVP."



Exemplo 2 — Modelo:

"Uso Claude Haiku por padrão porque é 12x mais barato que Sonnet com qualidade adequada

para recuperação de informações factuais. Mudaria para Sonnet se houvesse muitas perguntas

de análise comparativa complexa, onde o raciocínio mais profundo do Sonnet justifica o custo."



Exemplo 3 — Chunking:

"Escolhi chunking por cláusula (hierárquico) em vez de chunking fixo porque contratos

jurídicos têm estrutura semântica clara por cláusula. Chunking fixo quebra cláusulas no meio,

o que reduz o recall. Medido: recall 88% (hierárquico) vs 71% (fixo de 500 chars)."

"E se o usuário fizer perguntas que não estão nos documentos?"

→ O sistema responde "Não encontrei informação sobre isso nos documentos indexados."

   Implementado: se similarity score < 0.65, responder sem contexto e avisar.



"O sistema alucina?"

→ Com RAG, alucinação é minimizada porque o modelo recebe as fontes.

   Sem RAG (pergunta fora dos documentos): sim, como qualquer LLM.

   Por isso: sempre citar a fonte e instruir o usuário a verificar.



"Funciona com PDFs escaneados?"

→ Não nesta versão. Precisaria de OCR (Tesseract ou Google Document AI).

   É o próximo item do roadmap.



"Como escala para 10.000 documentos?"

→ pgvector com ivfflat index: testado até ~500k vetores em produção.

   Acima disso: migrar para índice HNSW ou Pinecone.

Abertura ruim:

"Aqui vemos o pipeline de RAG com embeddings OpenAI e pgvector que indexa

os documentos e usa cosine similarity para recuperar os chunks mais relevantes..."



Abertura boa:

"Você tem 200 contratos de clientes em PDF. Eu vou perguntar:

'Qual o prazo de aviso prévio para rescisão no contrato da Empresa X?'

Olha o que acontece."

[demo ao vivo → resposta em 3s com fonte]

"Antes levava 20 minutos buscando manualmente."

- Pré-carregar documentos (não fazer upload ao vivo)

- Ter sessão de backup em outra aba se a primeira travar

- Testar o fluxo completo 3x no dia anterior

Problema → Demo → Arquitetura (1 slide) → Métricas → Limitações → Próximos passos

Nunca começar com arquitetura — ninguém se importa com a solução antes de entender o problema

Rede cai, API retorna erro, o LLM responde devagar

Solução: ter screen recording do fluxo como backup ("vou mostrar um recording")

Ruim: "O sistema tem upload de PDF, chat com histórico, busca semântica..."

Bom: "Resolve: encontrar qualquer cláusula em qualquer contrato em menos de 5s"

Features são detalhes de implementação. Valor é o problema resolvido.

A audiência vai encontrar as limitações depois.

Antecipar as 2 principais (com o plano de solução) demonstra maturidade.

Esconder limitações → perde credibilidade quando descobrem.