Planejando a lotação com restrições reais
Eu passei uns três anos configurando modelos de programação linear pra operação logística de uma transportadora. O negócio parecia simples no papel, mas na prática você descobre que quase tudo tem ruído. Coisas como tempo de carga variável, motoristas que não aparecem e rotas que dão errado por causa de obras inesperadas. A programação linear é uma técnica matemática usada para otimizar recursos sob restrições lineares, e ela funciona até o dia em que seus dados são imperfeitos ou seu problema escala demais.
O que a programação linear é uma técnica matemática usada para otimizar, na prática
Você tem variáveis de decisão, uma função objetivo que quer maximizar ou minimizar, e um conjunto de restrições que definem o espaço viável. A matemática por trás é direta. O método simplex, desenvolvido por George Dantzig em 1947, percorre os vértices do politopo viável até encontrar o ótimo. Existem versões modernas como o método dos pontos interiores que também são amplamente utilizadas. O importante é entender que isso só se aplica quando tudo é linear: funções objetivo lineares, restrições lineares, variáveis contínuas ou inteiras. Se você já tentou modelar algo no papel antes de colocar no solver, sabe que a maior parte do trabalho é mesmo definir o modelo certo. Eu vejo gente gastar horas ajustando algoritmos quando o problema real era formular as restrições de forma correta. Um erro comum é colocar desigualdades invertidas. Você acha que está limitando um recurso, mas na verdade está permitindo que o solver explore uma região que não corresponde à realidade. Isso gera soluções que parecem viáveis no papel, mas que são completamente impossíveis no chão de fábrica.
Montando o modelo do zero
Vamos começar com algo concreto. Digamos que você precisa alocar três caminhões entre quatro rotas disponíveis, considerando custos fixos, capacidade de carga e demanda mínima de cada rota. A função objetivo seria minimizar o custo total de transporte. As restrições incluiriam a capacidade máxima de cada caminhão, a demanda obrigatória de cada rota e a disponibilidade limitada de veículos. A modelagem em si exige disciplina. Eu costumo seguir um fluxo: listar todas as variáveis, escrever cada restrição em linguagem natural antes de traduzir pra notação matemática, e então construir a função objetivo separadamente. Isso parece burocrático, mas evita erros de transcrição que são difíceis de detectar depois. Uma vez que o modelo estava pronto, eu testava com instâncias pequenas manualmente. Se o solver retornasse uma solução que não fazia sentido para o caso de três caminhões e duas rotas, eu sabia que havia um erro de formulação.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para resolver na prática, você pode usar bibliotecas como PuLP ou OR-Tools no Python, scipy.optimize.linprog, ou solvers comerciais como CPLEX e Gurobi. O PuLP é bastante acessível pra quem está começando. Com ele, você define as variáveis, adiciona restrições e chama o solver em poucas linhas. O resultado é um dicionário com os valores das variáveis na solução ótima, junto com o valor da função objetivo. Se o seu problema crescer, aí entra a questão da performance. Um modelo com dezenas de milhares de variáveis e restrições pode levar minutos ou horas pra resolver, dependendo da estrutura. Eu já vi um modelo de escala média levar cerca de 40 minutos no CPLEX, enquanto uma reformulação mais enxuta do mesmo problema resolvia em menos de dois minutos. A escolha do solver e a forma como as restrições são escritas fazem diferença real. Restrições esparsas são melhores que restrições densas, e evitar coeficientes com magnitudes muito distintas previne problemas numéricos.
Um caso específico que mostrou as limitações
Houve uma vez que precisei modelar uma operação de entrega com janelas de tempo e custos fixos de ativação de rota. A função custo tinha uma parte fixa por rota usada e uma parte variável proporcional à distância. O problema é que a parte fixa torna a função objetivo não linear — ela envolve variáveis binárias que indicam se uma rota foi ativada ou não. O modelo simples de programação linear pura não conseguia capturar isso. Eu tentei aproximações lineares, mas os resultados ficavam distorcidos, especialmente quando o número de rotas ativas era pequeno. A solução que funcionou foi transformar o problema em programação inteira mista. Adicionei variáveis binárias para cada rota e um grande M nas restrições de acoplamento. O solver precisou de bem mais tempo pra resolver, mas a solução foi factível e próxima do ideal. Esse caso me ensinou uma coisa útil: quando o problema não é estritamente linear, forçar um modelo linear puro frequentemente gera soluções piores do que aceitar um tempo de resolução maior com um modelo mais fiel à realidade. Se o seu cenário exige variáveis inteiras, considere usar um solver de programação inteira mista em vez de insistir no simplex.
Erros que todo mundo comete no início
O primeiro erro é ignorar a escala dos dados. Coeficientes muito grandes e muito pequenos na mesma matriz de restrições causam instabilidade numérica. O solver pode retornar soluções com resíduos altos ou até declarar inviabilidade quando o problema é viável. Normalizar as variáveis ajuda bastante. Outra armadilha é não verificar a viabilidade do problema antes de confiar no resultado. Às vezes o solver diz que encontrou uma solução ótima, mas ao checar as restrições com tolerância zero, alguma delas fica ligeiramente violada. Isso acontece por causa dos limites de tolerância do solver. Também é comum modelar restrições de integridade de forma errada. Se você precisa que uma variável seja inteira, declarar ela como contínua e arredondar depois é uma receita pra soluções inviáveis. Arredondar uma solução ótima de programação linear não garante que as restrições ainda serão satisfeitas. O correto é declarar as variáveis como inteiras no modelo desde o início, mesmo que isso aumente o tempo de resolução. E tem outro ponto que as pessoas subestimam: a análise de sensibilidade. Os solvers oferecem informações sobre intervalos de estabilidade dos coeficientes. Usar isso corretamente permite entender o quanto uma mudança nos parâmetros afeta a solução sem precisar rodar o modelo novamente. Ignorar essa funcionalidade é deixar informação valiosa na mesa.
Quando a programação linear não é a melhor opção
Se o seu problema tem funções não lineares, restrições geométricas complexas ou variáveis que precisam assumir valores discretos com relações não lineares entre si, a programação linear vai limitar suas opções. Nesses casos, programação não linear, programação inteira ou otimização por simulação podem ser alternativas mais adequadas. Outro cenário onde a abordagem linear falha é quando há incerteza significativa nos parâmetros. Programação estocástica ou otimização robusta tratam essa questão de forma mais estruturada. Também vale considerar que, para problemas de grande escala com estrutura especial, métodos de decomposição como Benders ou Dantzig-Wolfe podem ser mais eficientes do que resolver o modelo inteiro de uma vez. Na minha experiência, a programação linear continua sendo uma das ferramentas mais úteis da caixa de um analista. Ela resolve problemas reais todos os dias, desde que o modelo corresponda ao que você realmente precisa representar. O segredo não é encontrar o solver mais poderoso, e sim construir um modelo que capture as restrições essenciais sem adicionar complexidade desnecessária. Comece simples, valide com casos pequenos, verifique a sensibilidade e, quando o problema exigir, migre para formulações mais expressivas. O tempo que você gasta na formulação econômica retorna em qualidade de solução e tempo de resolução.
