O Diabo do Parâmetro - Como defini-los quando não é possível nenhuma validação contra a verdade básica [fechado]

Questão:

Quero iniciar uma discussão sobre como as pessoas definem parâmetros algorítmicos quando não é possível uma validação contra a groundtruth (talvez porque a groundtruth simplesmente não possa ser obtida ou seja muito difícil / tediosa de obter).

Li vários artigos e implementei os algoritmos subjacentes, nos quais se diz que um conjunto de parâmetros foi definido "empiricamente" --- e muitas vezes descobri que esses são os que afetam a generalidade do algoritmo (mesmo que o teoria subjacente ao método é elegante, atraente e sólida).

Eu apreciaria se você pudesse compartilhar seus pensamentos. E, não há resposta certa ou errada para esta pergunta. Eu só quero saber como todo mundo lida com isso.

Antecedentes / Fonte da pergunta:

Eu sou um cientista da computação trabalhando nas áreas de análise de imagem, visão computacional e aprendizado de máquina, e essa pergunta está no meu pensamento há algum tempo, pois enfrentei esse dilema várias vezes sempre que desenvolvo um novo algoritmo. encontrei-me gastando uma quantidade considerável de tempo ajustando os parâmetros.

Além disso, eu acho que minha pergunta aqui é mais geral em qualquer área em que os algoritmos computacionais estão fortemente envolvidos, e eu quero convidar os pensamentos de pessoas de todas as áreas envolvidas.

Eu queria dar um exemplo concreto, só para ajudar você a pensar:

--- Veja o caso da detecção de recursos (digamos, bolhas circulares ou pontos salientes). Você executa alguns filtros (precisa de parâmetros) em diferentes escalas (parâmetros de escala) e provavelmente limita a resposta (parâmetro de limite). Geralmente, não é possível obter uma base para validar e, assim, ajustar automaticamente seus parâmetros em tais cenários.

--- Pegue qualquer estrutura computacional que envolva muitos componentes de processamento de sinal. Sempre existem parâmetros a serem ajustados e, geralmente, não existe uma verdade básica e quando você os ajusta subjetivamente em um pequeno subconjunto aleatório do seu conjunto de dados, algum dia encontrará o caso para o qual ele não se generaliza.

Este parâmetro diabo é mais problemático quando você está definindo parâmetros para algumas etapas intermediárias do seu algoritmo.

E muitas vezes descobri que não é possível lançar o problema de encontrar bons valores para esses parâmetros como um problema de otimização com uma função objetiva da qual você pode obter uma derivada e, assim, usar algoritmos de otimização padrão para encontrar bons valores.

Além disso, em muitos cenários, expor esses parâmetros a um usuário final não é uma opção, pois geralmente desenvolvemos aplicativos / software para usuários finais não computacionais (digamos biólogos, médicos) e eles geralmente ficam sem noção quando você pede que sintonizem. a menos que seja muito intuitivo (como tamanho aproximado do objeto).

Por favor, compartilhe seus pensamentos.

Assumindo que não é uma verdade chão, ( pelo menos teoricamente ) uma das possíveis maneiras de superar o problema "tédio" é um "bootstrap" criação verdade terrestre. Se você já possui um algoritmo decente que executa o trabalho em cerca de 80% a 90% dos casos, é possível executar o algoritmo em um grande conjunto de instâncias e pedir ao usuário que marque apenas os erros. Essa abordagem possui suas próprias falhas, como o viés em relação ao seu algoritmo.

No entanto, existem alguns casos em que não há nenhuma verdade básica, apenas trocas de sistema diferentes. Por exemplo, é necessário um sistema de processamento de imagem para gerar uma imagem nítida, com cores precisas e sem ruído. Obviamente, você não pode tê-los todos ao mesmo tempo. Nesse caso, você deve usar métricas objetivas que possam ser calculadas sobre o resultado do seu sistema. (Veja Imatest , analisador DXO para processamento de imagem).

Depois de os ter, existem métodos de otimização de múltiplos objetivos que podem criar um mapeamento a partir das compensações (que são claras para o usuário) até os parâmetros intrínsecos.

De qualquer forma, você nunca deve fornecer ao usuário um parâmetro que ele não possa entender. Se tudo falhar, simplesmente codifique o parâmetro.

Esse é um problema muito, muito difícil, mas há muito trabalho na área. Por um exemplo, dê uma olhada neste artigo de Ramani & Fessler sobre a abordagem SURE. A introdução tem uma ótima visão geral dos métodos de seleção de parâmetros, verifique suas referências.