"Tasarım Ne Bekler" kitabındaki yapay zeka sohbetim

GELECEKTE YAZI OLACAK MI? EMİN DEĞİLİM…
Deniz Yüret
Hazırlayan: Meriç Tuncez
Tasarım Ne Bekler, © 2019 KUAR Yayınları

Konumuzla alakalı araştırma yaparken 2015 yılında Google’ın siyahi bir çiftin fotoğrafını goriller olarak etiketlediğine dair bir haberle karşılaştım. Benzer şekilde Google’ın iş önerilerinde bulunurken erkeklere kadınlara oranla altı kat daha yüksek maaşlı işler önerdiğine dair bir haber var. Bu bilgiden yola çıkarsak yapay zekânın algoritma kaynaklı (algorithmic) önyargıdan yani onu üreten kişinin ön yargılarından uzaklaşması mümkün mü? Ya da nasıl mümkün olabilir?

Öncelikle programın niye bu ön yargılara sahip olduğunu kısaca anlatayım. Bu bahsettiğin teknolojilerin hepsi eski usul “Yazılım 1.0” diyebileceğimiz birilerinin oturup bilgisayara bir şeyler programlaması şeklinde geliştirilmiyor.

Bana 20 sene önce bu soru sorulsaydı derdim ki “Bunu yazan programcı ırkçı ya da cinsiyetçi. Dolayısıyla bu adamı işten atın.” Ama şu anda artık bu yeni teknolojiler bu şekilde geliştirilmiyor. Onun yerine örneklere bakarak istatistikler üzerinden geliştiriliyor.

Yani iş bulma ya da resimden bir şeyler tanıma konusunda bir sürü etiketlenmiş veri hazırlıyorsunuz. Bu etiketlendirilmiş veriyi bilgisayara veriyorsunuz. Bilgisayar milyonlarca örnek üzerinden birtakım şeyleri öğrenip ondan sonra sizin sorularınıza cevap vermeye başlıyor.

Şimdi verdiğiniz veride bir önyargı var ve orada cinsiyetçi ya da ırkçı birtakım şeyler varsa programın önyargıyı da bu algoritmaların içine alması gayet normal. Bu durum algoritmanın suçu değil, verdiğimiz verinin suçu. Dolayısıyla biz eğer bu önyargı konusunda gerçekten duyarlı davranmak istiyorsak veriyi ona göre hazırlamamız lazım.

Yani bilgisayarda onu eğitim verisi olarak kullanmadan önce veriyi dengelememiz lazım. Benzer bir olay geçen sene Microsoft’ta yaşandı. Bir “sohbet robotu” (chatbot) hazırlayıp bunu Twitter’a saldılar. 24 saat sonra kapatmak zorunda kaldılar çünkü insanlardan birçok kötü, ırkçı cinsiyetçi dil elemanlarını öğrenip bunları taklit etmeye başlamıştı.

Yani bu öğrenme algoritmalarını masum birer bebek olarak düşünebiliriz. Ona ne öğretirsek o da aynı şekilde onu tekrarlamayı öğreniyor. Dolayısıyla bu öğretmenin kabahati olabilir.

Örneğin bir AlphaGo (Google DeepMind tarafından geliştirilmiş Go oyununu oynayan bir program) problemini ele aldığımızda bizim kazandığımız nokta belli. Yani nasıl kazanabileceğimiz o oyunda belli ve skorumuz var. Ama mesela bir tasarım probleminde aynı şekilde olmuyor bu, birçok farklı sonuca gitme yolu olduğunu görüyoruz. Örneğin bir iklim değişikliği için tasarım yapılacağı zaman “yapay zekâ”yı nasıl kullanabiliriz? Bizim çıktımız ne olacak burada? Yani sadece “iklimdeki sıcaklığı düşürmek” mi çıktımız? Yoksa başka bir şey mi? Yani böyle karışık bir problemde sonuçlarını ve neyin doğru olduğunu bilemediğimiz durumlarda biz yapay zekâyı ya da “özdevimli öğrenme”yi (machine learning) nasıl tasarımlarımızda kullanabiliriz?

Bu bence şu anda dahi çözümlenememiş bir soru. Çünkü yapay zekâ modellerini eğitirken verdiğimiz verinin yanı sıra bir de “objektif fonksiyon” (objective function) ya da “hata fonksiyonu” (error function) denilen bir değer atamamız gerekli.

Yani genel olarak “Ben sana böyle girdiler verdiğimde böyle çıktılar istiyorum” gibi bir eğitim verisi veriyoruz bu öğrenen programlara. Ama onun yanı sıra “Sen bu istediğim çıktıyı değil ondan biraz daha farklı bir çıktı üretirsen de ben senin hata oranını şu şekilde ölçeceğim, senin objektif fonksiyonun bu olacak.” şeklinde tasarımcının karar vermesi gerekiyor. Dolayısıyla neyi en uygun şekilde kullanacağımıza bizim karar vermemiz lazım. Bu dediğim gibi çok kolay bir problem değil. Özellikle iklim değişikliği gibi karmaşık konularda problem daha da zorlaşıyor.

Elon Musk’ın bu “Robotlar dünyayı fethedecek.” senaryosunu aydınlatabilecek çalışmalar yapılmakta günümüzde ve araştırmacıların en çok kaygılandığı konu bu. Yani biz yapay zekâya bir hedef belirlerken o hedef belirleme konusunda çok dikkatli olmazsak bu sistemlerin bizim o anda hiç beklemediğimiz birtakım yönlere gitmesi mümkün.

Diyelim ki dünyanın ısısını düşürmeyi bir hedef olarak verirsek bize verdiği çözümler yeni bir buz çağına sebep olabilir. Ama diğer yandan bu yeni bir problem değil ve yapay zekâya mahsus bir problem de değil. Geçenlerde yapay zekânın bu objektif fonksiyon problemi ile finansal marketleri ya da politik sistemleri karşılaştıran bir makale okudum. İnsanlar uzun zamandır karmaşık sistemler tasarlamakta güçlük çekiyorlar.

Dolayısıyla gayet iyi niyetlerle tasarlanmış Avrupa Birliği ya da Menkul Kıymetler Borsası gibi karmaşık sosyal sistemler düşünün. Bu sistemlerde de tasarlayanların kötü bir niyeti olmamasına rağmen sistem kendi dinamikleri içerisinde hiç beklemediğimiz birtakım sonuçlara sebep olup bize zarar verecek yönlere gidebiliyor.

Dolayısıyla bu bence üzerinde çalışmamız gereken bir sorun. Bunun bu arada teknik olarak kullanılan adı “hizalama” (alignment). “Sizin değerlerinizle geliştirdiğiniz sistemin ya da programın değerlerinin birbirine paralel hale getirilmesi nasıl mümkün olabilir?” Bu halen üzerinde çalışılan açık bir problem.

Gerisini oku




Full post...

Team Howard Beale at SemEval-2019 Task 4: Hyperpartisan News Detection with BERT

Osman Mutlu, Ozan Arkan Can and Erenay Dayanık. 2019. In International Workshop on Semantic Evaluation (SemEval-2019 at NAACL-HLT-2019). (paper, proceedings)

Abstract: This paper describes our system for SemEval-2019 Task 4: Hyperpartisan News Detection (Kiesel et al., 2019). We use pretrained BERT (Devlin et al., 2018) architecture and investigate the effect of different fine tuning regimes on the final classification task. We show that additional pretraining on news domain improves the performance on the Hyperpartisan News Detection task. Our system ranked 8th out of 42 teams with 78.3% accuracy on the held-out test dataset.

Full post...

Learning from Implicit Information in Natural Language Instructions for Robotic Manipulations

Ozan Arkan Can, Pedro Zuidberg Dos Martires , Andreas Persson , Julian Gaal , Amy Loutfi , Luc De Raedt , Deniz Yuret and Alessandro Saffiotti. 2019. In Proceedings of the Combined Workshop on Spatial Language Understanding (SpLU) & Grounded Communication for Robotics (RoboNLP) at NAACL-HLT-2019. (abstract, paper, poster, proceedings)

Abstract: Human-robot interaction often occurs in the form of instructions given from a human to a robot. For a robot to successfully follow instructions, a common representation of the world and objects in it should be shared between humans and the robot so that the instructions can be grounded. Achieving this representation can be done via learning, where both the world representation and the language grounding are learned simultaneously. However, in robotics this can be a difficult task due to the cost and scarcity of data. In this paper, we tackle the problem by separately learning the world representation of the robot and the language grounding. While this approach can address the challenges in getting sufficient data, it may give rise to inconsistencies between both learned components. Therefore, we further propose Bayesian learning to resolve such inconsistencies between the natural language grounding and a robot’s world representation by exploiting spatio-relational information that is implicitly present in instructions given by a human. Moreover, we demonstrate the feasibility of our approach on a scenario involving a robotic arm in the physical world.

Full post...

A Task Set Proposal for Automatic Event Information Collection across Multiple Countries

Ali Hürriyetoğlu, Erdem Yörük, Deniz Yuret, Çağrı Yoltar, Burak Güler, Fırat Duruşan and Osman Mutlu. 2019. In ECIR (CLEF Organizers Lab Track), Germany. (paper, proceedings)

Abstract: We propose a coherent set of tasks for protest information collection in the context of generalizable natural language processing. The tasks are news article classification, event sentence detection, and event extraction. Having tools for collecting event information from data produced in multiple countries enables comparative sociology and politics studies. We have annotated news articles in English from a source and a target country in order to be able to measure the performance of the tools developed using data from one country on data from a different country. Our preliminary experiments have shown that the performance of the tools developed using English texts from India drops to a level that are not usable when they are applied on English texts from China. We think our setting addresses the challenge of building generalizable NLP tools that perform well independent of the source of the text and will accelerate progress in line of developing generalizable NLP systems.

Full post...

Knet v1.2.0: iterators, iterators, iterators...

The new Knet release is all about iterators: iterators for minibatching, iterators for training, iterators for monitoring, convergence etc. Why am I so excited about iterators all of a sudden? Allow me to explain:

Knet has used iterators for data generation since 2015. That was about it until recently when I was looking for a way to improve the training interface. See, at the core of every deep learning project there is a training loop that looks like this:

function train(model,data)
    for (x,y) in data
        # improve model parameters so model(x) approaches y
    end
end

And these things can run for hours or days. You want the user to have full control of this loop: how many iterations to go, how to detect convergence and quit, how to monitor progress, how to take model snapshots or measure dev accuracy every n iterations etc.

My original (non)solution was to write a new `train` function for every experiment. Why restrict the user with a bad interface when they can write their own 5 line loop? (of course then why write any package at all but that's another discussion).

My next (pseudo)solution was to provide a `train` function with lots of keyword arguments. I soon gave up on that idea when it became clear that I was on my way to implementing a Turing complete programming language using keyword arguments.

Then I thought I had a brilliant flash of insight based on callback functions. See if `train` just accepts a callback function that gets called inside the for loop, the user can implement any behavior:

function train(model,data,callback)
    for (x,y) in data
        callback() || break
        # improve model parameters so model(x) approaches y
    end
end

You want to display a progress bar, do something every n iterations, or quit after N iterations? Just implement some callback function with state and you are all set! Brilliant? Everybody hated it. Including me. It turns out callback functions are awkward to write and do not lead to very readable code.

Then finally I rediscovered iterators and iterators that wrap other iterators (inspired by Tqdm.jl). I knew iterators can be these lazy collections that produce their next element only when asked. (Here is a summary with doc links to refresh your memory). See, once you implement the training loop as an iterator you can pause, restart and terminate it whenever you want:

train(model,data) = ((update model and return loss) for (x,y) in data)

What I realized iterators also do is turn the for loop inside out! Make its guts visible so one has explicit control: You can monitor and display its progress, take snapshots or whatever all with very explicit and readable code. Here are some actual examples from Knet v1.2.0. (`sgd` is a train iterator, f is the model, d is the data):

* To display a progress bar use progress(sgd(f,d)).
* To run until convergence use converge(sgd(f,cycle(d))).
* To run multiple epochs use sgd(f,repeat(d,n)).
* To run a given number of iterations use sgd(f,take(cycle(d),n)).
* To do a task every n iterations use:
(task(x) for x in every(n, sgd(f,cycle(d)))).

Each of the functions like `progress`, `converge`, `sgd` etc. take and return iterators. So they can be composed like crazy. Here is how to (1) train a model on dtrn, (2) measuring loss on dtst every 100 iterations, (3) quitting when dtst performance converges, and (4) displaying a progress bar from the Knet tutorial:

a = adam(model,cycle(dtrn))
b = (model(dtst) for _ in every(100,a))
c = converge(b, alpha=0.1)
progress!(c, alpha=1)

The code reads like the English description! Imagine trying to implement this using keyword arguments or callback functions... and that is why I am excited about iterators.

Notes:
* the more nitpicky reader will probably point out that I should have called these things generators or coroutines or streams or something rather than iterators, but you get the idea.
* every(n,itr) = (x for (i,x) in enumerate(itr) if i%n == 0) should be a Julia primitive! (Thank you @CarloLucibello for pointing out that `IterTools.takenth` does the same thing.)
* @lostella has a wonderful post on iterators.
* Here are the relevant links in Julia docs: Interfaces, Collections, Iteration Utilities and Generator expressions.
* Here is a link to the discussion on Julia discourse.

Full post... Related link