Progettazione di programmi fenotropici

Di recente mi sono imbattuto in un'idea di Jaron Lanier chiamata "programmazione fenotropica".

L'idea è di utilizzare interfacce "di superficie" anziché interfacce a punto singolo nei programmi per computer che utilizzano statistiche per rilevare errori minori che in genere causerebbero un arresto anomalo di un programma "classico".

La descrizione a due righe è qui:

Secondo Jaron, la "vera differenza tra l'attuale idea di software, che è l'adesione al protocollo, e l'idea [di cui] sta discutendo, il riconoscimento di schemi, ha a che fare con il tipo di errori che stiamo creando" e se "non lo facciamo trovare un modo diverso di pensare e creare software, non scriveremo programmi più grandi di circa 10 milioni di righe di codice, non importa quanto velocemente diventino i nostri processori. "

La spiegazione leggermente più lunga è qui . E la spiegazione ancora più lunga è qui .

Quindi, la domanda, guardando oltre le ovvie connotazioni robot-signore che le persone tendono a scegliere, come si potrebbe effettivamente progettare e scrivere un "programma fenotropico?"

Lanier ha inventato una parola di 50 cent nel tentativo di gettare una rete attorno a una serie specifica di idee che descrivono un modello computazionale per la creazione di programmi per computer con determinate caratteristiche identificabili.

La parola significa:

Un meccanismo per l'interazione tra componenti che utilizza il riconoscimento di schemi o la cognizione artificiale al posto di invocazione di funzioni o passaggio di messaggi.

L'idea viene in gran parte dalla biologia. Il tuo occhio si interfaccia con il mondo, non attraverso una funzione simile See(byte[] coneData), ma attraverso una superficie chiamata retina. Non è una distinzione banale; un computer deve scansionare tutti i byte coneDatauno per uno, mentre il cervello elabora tutti quegli input contemporaneamente.

Lanier afferma che quest'ultima interfaccia è più tollerante ai guasti, e lo è (un singolo bit inserito coneDatapuò rompere l'intero sistema). Afferma che consente la corrispondenza dei modelli e una serie di altre funzionalità che sono normalmente difficili per i computer, cosa che fa.

Il meccanismo "fenotropico" per antonomasia in un sistema informatico sarebbe la rete neurale artificiale (ANN). Prende una "superficie" come input, piuttosto che un'interfaccia definita. Esistono altre tecniche per ottenere una certa misura del riconoscimento di modelli, ma la rete neurale è quella più strettamente allineata con la biologia. Fare una ANN è facile; ottenerlo per eseguire l'attività che si desidera svolgere in modo affidabile è difficile, per una serie di motivi:

1. Che aspetto hanno le "superfici" di input e output? Sono stabili o variano di dimensioni nel tempo?
2. Come si ottiene la struttura della rete giusta?
3. Come si allena la rete?
4. Come si ottengono adeguate caratteristiche prestazionali?

Se sei disposto a separarti dalla biologia, puoi rinunciare al modello biologico (che tenta di simulare il funzionamento di neuroni biologici reali) e costruire una rete che è più strettamente connessa con gli attuali "neuroni" di un sistema informatico digitale (logica porte). Queste reti sono denominate reti logiche adattive (ALN). Il modo in cui funzionano è creando una serie di funzioni lineari che si avvicinano a una curva. Il processo è simile al seguente:

... dove l'asse X rappresenta un input per l'ALN e l'asse Y rappresenta un output. Ora immagina il numero di funzioni lineari che si espandono in base alle necessità per migliorare l'accuratezza e immagina che il processo si verifichi in n dimensioni arbitrarie, implementato interamente con porte logiche AND e OR, e hai un'idea di come appare un ALN.

Gli ALN hanno alcune caratteristiche molto interessanti:

1. Sono abbastanza facilmente addestrabili,
2. Sono molto prevedibili, cioè lievi cambiamenti nell'input non producono oscillazioni selvagge nell'output,
3. Sono velocissimi, perché sono costruiti a forma di albero logico e funzionano in modo molto simile a una ricerca binaria.
4. La loro architettura interna si evolve naturalmente a seguito del set di formazione

Quindi un programma fenotropico sarebbe simile a questo; avrebbe una "superficie" per l'input, un'architettura e un comportamento prevedibili e tollererebbe input rumorosi.

Ulteriori letture
Introduzione alle reti logiche adattive con un'applicazione per il controllo della valutazione del rischio
"Orientamento agli oggetti" vs "Orientamento ai messaggi" di Alan Kay

Penso che siamo all'inizio di uno dei passi che ci vorranno per arrivarci e che sta raccogliendo molti dati in formati che possono essere analizzati. Internet, ricerche su Google, Fitbit (ogni passo che fai, ogni mossa che fai, ti guarderò.), FourSquare, una posizione geografica dello smartphone, post di Facebook e dati di domande SO sono tutti raccolti. Non siamo vicini alla quantità di dati sensoriali che l'essere umano medio sta compilando nel corso di una vita, ma ci stiamo avvicinando.

Inizia a categorizzare milioni di immagini di uccelli e ricevi feedback dalle persone che ti dicono che non è un uccello e puoi iniziare a creare un algoritmo. Da lì si può creare un'impressione più sfacciata (lo definirei un modello, ma è troppo esatto per quello che stiamo cercando di codificare.).

class Birdish

Come fa un cane a sapere così tanto del proprietario? Perché la osserva molto. Il cane ha ascoltato le macchine che entravano nel vialetto e che correlavano il fatto che con il proprietario che apriva la porta d'ingresso sembrava che il cane potesse riconoscere un'auto dal suo suono. Potremmo farlo anche noi, ma non vediamo alcun motivo per occuparcene. E questo è ciò che non va nel software attuale, non presta attenzione a ciò che l'utente sta facendo. Aspetta solo che l'utente faccia ciò che l'IT si aspetta che faccia.

Qualcosa di semplice come impostare una sveglia potrebbe essere fatto con una piccola osservazione / analisi delle mie abitudini attuali. Abbiamo rinunciato a impostare i timer del videoregistratore prima che la tecnologia fosse sostituita dal digitale. E sarebbe successo così velocemente se avessimo potuto interfacciare la Guida TV con il videoregistratore? Ho guardato lo stesso programma TV per 4 settimane di fila contemporaneamente, ma il quinto non ho nemmeno acceso la TV. Ovviamente lo voglio registrato. Non puoi dire che rimango tardi al lavoro a scrivere questo post e con il mio tipico pendolarismo non lo farò a casa in tempo? Hai i dati, fai i conti.

Raccogli sempre più dati e poi puoi trovare modi migliori per analizzarli, riconoscerli e convertirli. Andiamo oltre ciò che può essere immesso solo da una tastiera con le nostre fotocamere telefoniche e presto le fotocamere a specchio. È solo l'inizio.

Ecco una serie di diapositive per la definizione di un linguaggio di programmazione probabilistico in Scala .

È il primo esempio di implementazione decente per alcuni dei componenti principali del sistema proposto da Jaron Lanier.

Un pensiero che ho avuto di recente:

Se hai utilizzato idee di alto livello come Maybe Monad di Haskell per avvolgere chiamate di procedure remote verso altri sistemi. Si invia una richiesta al server. Ma non torna nulla (il server è rotto). Oppure torna una Promessa (il server è occupato) e i tuoi programmi continuano a funzionare con quei valori Nessuno o Promesso. È un po 'come la tolleranza agli errori che Lanier sta cercando.

Forse ci sono modi per incapsulare altre eventualità. Ad esempio, le chiamate remote che ritornano con un'approssimazione che è sempre più raffinata nel tempo da una sorta di negoziazione in background. vale a dire. ciò che ritorna è qualcosa di simile a una Promessa, ma non solo "continuare a trattenere e lavorare con questo e un valore adeguato apparirà a breve" ma "continuare a trattenere e lavorare con questo e una migliore approssimazione apparirà a breve". (E ancora e ancora). Ciò sarebbe in grado di nascondere molti errori al programmatore, così come i protocolli di rete nascondono un errore di rete molto basso al programmatore.