253 lines
7.9 KiB
Markdown
253 lines
7.9 KiB
Markdown
# Teoria da Informação Aplicada a Código e Sistemas
|
||
|
||
## 1. Entropia de Shannon em Software
|
||
|
||
### Definição Aplicada
|
||
```
|
||
H(X) = -Σ p(xᵢ) · log₂ p(xᵢ)
|
||
|
||
Interpretação em código:
|
||
- X = variável aleatória "qual estado o sistema está"
|
||
- p(xᵢ) = probabilidade de estar no estado i
|
||
- H(X) = incerteza sobre o estado → complexidade de teste
|
||
|
||
Exemplo VoicePipeline:
|
||
Estados: IDLE(70%), RECORDING(15%), TRANSCRIBING(5%),
|
||
QUERYING_LLM(5%), SPEAKING(4%), ERROR(1%)
|
||
|
||
H = -(0.70·log₂0.70 + 0.15·log₂0.15 + 0.05·log₂0.05 +
|
||
0.05·log₂0.05 + 0.04·log₂0.04 + 0.01·log₂0.01)
|
||
H ≈ 1.45 bits
|
||
|
||
Máximo teórico (uniform): log₂(6) ≈ 2.58 bits
|
||
Eficiência de entropia: 1.45/2.58 ≈ 56% — baixa entropia = sistema bem estruturado
|
||
```
|
||
|
||
### Entropia de Interface
|
||
```
|
||
Para uma função f: I → O
|
||
H(O) = entropia dos possíveis outputs
|
||
H(O|I) = entropia de O dado I (incerteza residual)
|
||
|
||
Informação mútua I(I;O) = H(O) - H(O|I)
|
||
= quanto a entrada reduz a incerteza sobre a saída
|
||
|
||
Objetivo ideal: I(I;O) = H(O) → entrada determina completamente saída
|
||
Equivale à função sendo determinística (sem nondeterminismo)
|
||
|
||
Caso problemático em Auri:
|
||
BluetoothController.connect() — output depende de estado do dispositivo BT
|
||
H(success|deviceAddress) > 0 (conexão pode falhar por razões externas)
|
||
→ sistema inerentemente não-determinístico neste ponto
|
||
→ tratamento de erro é mandatório, não opcional
|
||
```
|
||
|
||
---
|
||
|
||
## 2. Complexidade de Kolmogorov
|
||
|
||
### Definição
|
||
```
|
||
K(x) = comprimento do menor programa que produz x
|
||
|
||
Interpretação prática:
|
||
- K(código) = complexidade algorítmica intrínseca
|
||
- Código não pode ser comprimido abaixo de K(código)
|
||
- Se código tem padrões repetitivos → K(código) << |código|
|
||
→ oportunidade de abstração/refatoração
|
||
```
|
||
|
||
### Aplicação: Detectar Código Duplicado
|
||
```
|
||
Princípio: se compress(file1 + file2) << |file1| + |file2|
|
||
então file1 e file2 têm estrutura compartilhada → extrair abstração
|
||
|
||
Ferramenta prática: medir ratio de compressão
|
||
ratio = compress(código) / |código|
|
||
|
||
Limites heurísticos:
|
||
ratio < 0.3: muito código repetitivo → refatorar urgente
|
||
ratio 0.3-0.5: alguma repetição → oportunidade de refatoração
|
||
ratio > 0.5: código diverso/expressivo → aceitável
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Capacidade de Canal e Throughput
|
||
|
||
### Modelo de Ruído para Sistemas BT
|
||
```
|
||
Canal de Shannon com ruído:
|
||
- Capacidade C = B · log₂(1 + S/N) bits/s
|
||
B = bandwidth (Hz), S/N = signal-to-noise ratio
|
||
|
||
Para SCO (Bluetooth headset mic):
|
||
- B = 8kHz (narrowband) ou 16kHz (wideband)
|
||
- Qualidade de voz: S/N típico 20-30dB em ambiente silencioso
|
||
- C ≈ 8000 · log₂(101) ≈ 53,000 bits/s ≈ 53 kbps
|
||
|
||
PCM recording no app:
|
||
- 16kHz, 16-bit → 256 kbps bruto
|
||
- Compressão efetiva do canal BT SCO: 64 kbps (CVSD codec)
|
||
- Perda de qualidade: ~75% da resolução PCM
|
||
→ justifica preferência por BLE Audio sobre SCO quando disponível
|
||
```
|
||
|
||
### Pipeline de Throughput
|
||
```
|
||
Modelo de gargalo (teoria de filas em série):
|
||
Pipeline: Audio → STT → LLM → TTS
|
||
|
||
Capacidade de cada estágio:
|
||
Stage | Rate | Buffer | Observação
|
||
Audio cap. | 256 kbps | Ring buf | Contínuo
|
||
STT online | ~500ms/req| 1 req | Latência dominante
|
||
LLM (API) | ~500 tok/s| 1 req | Throughput alto
|
||
LLM (Ollama)| ~3 tok/s | 1 req | GARGALO A04
|
||
TTS | ~200 ms | 1 req | Rápido
|
||
|
||
Throughput do pipeline = min(taxas) = 3 tok/s (Ollama A04)
|
||
Equivale a ~15 palavras/minuto (muito lento para conversa fluida)
|
||
→ Justifica recomendação de usar OpenAI API para conversação real-time
|
||
```
|
||
|
||
---
|
||
|
||
## 4. Teoria da Codificação Aplicada a APIs
|
||
|
||
### Redundância e Robustez
|
||
```
|
||
Um protocolo com redundância tem:
|
||
- Taxa de código: r = k/n (k = bits úteis, n = bits transmitidos)
|
||
- r = 1: sem redundância (frágil)
|
||
- r < 1: com redundância (tolerante a erros)
|
||
|
||
Em APIs REST/LLM:
|
||
- Retry logic = redundância temporal: r = 1/(tentativas)
|
||
- Idempotency keys = deduplicação: garante exatamente 1 processamento
|
||
- Checksum/hash = redundância de verificação
|
||
|
||
Para Auri AuriToolExecutor:
|
||
- Sem idempotency keys: r = 1 (frágil a retries)
|
||
- Com idempotency keys: r = 1/max_retries (robusto)
|
||
```
|
||
|
||
### Compressão e Eficiência de Contexto LLM
|
||
```
|
||
LLMs têm contexto finito (ex: 128k tokens para Claude)
|
||
Cada conversa consome: Σ len(mensagem_i) tokens
|
||
|
||
Otimização de contexto como problema de compressão:
|
||
- Manter apenas informação essencial para resposta seguinte
|
||
- Sumarizar histórico para economizar tokens
|
||
- "Esquecimento" estratégico de contexto irrelevante
|
||
|
||
Para Auri:
|
||
Estratégia ótima de gerenciamento de contexto:
|
||
1. Manter últimas N trocas completas (N=5-10)
|
||
2. Sumarizar trocas mais antigas em 1-2 frases
|
||
3. Sempre manter: contexto do sistema + última mensagem do usuário
|
||
4. Custo estimado por requisição: ~200-500 tokens com esta estratégia
|
||
```
|
||
|
||
---
|
||
|
||
## 5. Teoria da Decisão Bayesiana
|
||
|
||
### Diagnóstico de Bugs como Inferência Bayesiana
|
||
```
|
||
P(bug=B | observação=O) = P(O|B) · P(B) / P(O)
|
||
|
||
Onde:
|
||
- P(B) = prior: frequência histórica deste tipo de bug
|
||
- P(O|B) = likelihood: probabilidade de ver este log/comportamento dado o bug
|
||
- P(O) = evidência: normalização
|
||
|
||
Exemplo Auri:
|
||
Bug: "pipeline trava em TRANSCRIBING"
|
||
Observação: "STT retorna resultado vazio, UI congela"
|
||
|
||
Hipóteses e priors estimados:
|
||
H1: STT result handler não atualiza state (P = 0.3)
|
||
H2: coroutine canceled antes de processar resultado (P = 0.25)
|
||
H3: exception silenciosa em emit() (P = 0.2)
|
||
H4: MainActivity lifecycle issue (P = 0.15)
|
||
H5: outra causa (P = 0.1)
|
||
|
||
Após análise do código:
|
||
P(vazio|H1) = 0.9 → P(H1|vazio) ≈ 0.52 — MAIS PROVÁVEL
|
||
P(vazio|H2) = 0.7 → P(H2|vazio) ≈ 0.34
|
||
P(vazio|H3) = 0.3 → P(H3|vazio) ≈ 0.11
|
||
|
||
Diagnóstico bayesiano: investigar H1 primeiro (52%), depois H2 (34%)
|
||
```
|
||
|
||
### Estimativa de Confiança em Análises
|
||
```
|
||
Quando Prof. Euler faz afirmações, deve incluir calibração:
|
||
|
||
"[Afirmação] — confiança: X%"
|
||
|
||
Calibração típica:
|
||
90%+: baseado em código lido + padrões bem estabelecidos
|
||
70-89%: inferência razoável + experiência com padrões similares
|
||
50-69%: hipótese plausível, necessita verificação
|
||
<50%: especulação, explicitamente marcada como tal
|
||
```
|
||
|
||
---
|
||
|
||
## 6. Complexidade de Descrição Mínima (MDL)
|
||
|
||
### Princípio MDL para Escolha de Arquitetura
|
||
```
|
||
Princípio: escolha a arquitetura que minimiza:
|
||
MDL = comprimento(modelo) + comprimento(dados|modelo)
|
||
|
||
Aplicado a padrões de design:
|
||
- MVVM: modelo compacto (3 camadas), dados bem organizados → MDL baixo
|
||
- God Class: modelo compacto (1 classe), dados confusos → MDL alto
|
||
- Microservices: modelo complexo, dados bem distribuídos → MDL médio
|
||
|
||
Para Auri MainViewModel:
|
||
Se MainViewModel tem CC > 50 e 300+ linhas:
|
||
- MDL(atual) = 1 arquivo grande = baixo overhead de modelo, alto custo de entendimento
|
||
- MDL(refatorado) = 5 ViewModels especializados = overhead de modelo, baixo custo cada
|
||
- MDL(refatorado) < MDL(atual) quando complexidade total > threshold ≈ CC 30
|
||
|
||
Recomendação: decompor quando CC total > 30 por arquivo
|
||
```
|
||
|
||
---
|
||
|
||
## 7. Teoria da Informação para Logging
|
||
|
||
### Entropia de Logs (Detectar Anomalias)
|
||
```
|
||
Log normal: mensagens seguem distribuição estacionária
|
||
- Calcular baseline: H_baseline = entropia nos primeiros N logs
|
||
- Monitor: H_current = entropia janela deslizante
|
||
|
||
Anomalia se: |H_current - H_baseline| > 2σ
|
||
|
||
Tipos de anomalias detectáveis:
|
||
1. Muitas mensagens idênticas (spamming) → entropia cai abruptamente
|
||
2. Mensagens inesperadas (novo tipo de erro) → entropia sobe
|
||
3. Sequência de eventos anormal → informação mútua entre logs muda
|
||
|
||
Para Auri FileLogWriter:
|
||
- Logar timestamps + tipo de evento + módulo
|
||
- Post-process: calcular entropia por módulo por minuto
|
||
- Threshold: alertar se H(módulo, minuto) < 0.5 ou > 3.5 bits
|
||
```
|
||
|
||
### Compressão de Logs como Detecção de Padrões
|
||
```
|
||
compress(logs) / |logs| = ratio de compressão
|
||
|
||
Baixo ratio (< 0.2): logs muito repetitivos → possível loop ou spam
|
||
Alto ratio (> 0.7): logs muito variados → possível estado errático
|
||
|
||
Sistema saudável: ratio ≈ 0.3-0.5
|
||
```
|