DEVİMDEVİM

BOOK · FRAMEWORK DOCUMENTATION

Computational Dialectics

Diyalektik düşünceden hesaplanabilir bir temsil ve revizyon rejimine.

YAŞAYAN DOKÜMANv0.1 · 15.09.2026
ARAŞTIRMA DURUMUBu yaşayan metin nihai teori değildir. Mimari iddialar deneysel statüleriyle birlikte okunmalıdır.

Bölüm 6 / 10

V. Computational Dialectics Core nasıl bir sistem olabilir?

World/concept state, Devim candidate cognitive architecture ve mimari olgunluk eşiklerini açıklar.

V. Computational Dialectics Core nasıl bir sistem olabilir?

14. Gerçekliği sayıya indirgemek değil, ilişkileri işlenebilir kılmak

“Toplumsal ilişkileri nasıl hesaplayacağız?” sorusu kolayca yanlış anlaşılabilir. Computational Dialectics bütün gerçekliğin birkaç sayıya çevrilebileceğini iddia etmez. İnsanların deneyimleri, tarihsel özgüllük, anlam, kurumlar ve toplumsal ilişkiler bir tabloya sıkıştırıldığında tüketilmiş olmaz.

Hesaplanabilir kılmaya çalıştığımız şey daha sınırlıdır: bir modelin belirli bir problem üzerinde kullandığı temsilin yapısı ve bu yapının kanıt karşısında nasıl değiştiği.

Örneğin “A işçisi B şirketinde çalışıyor” yalnız iki node arasındaki bir edge değildir. Analiz için önemliyse ilişkinin türü, zaman aralığı, sözleşme biçimi, karar yetkisi, gelir bağımlılığı, üretim sürecindeki konumu ve başka kurumlarla bağlantısı da temsilin parçası olabilir. Başka bir problemde bunların çoğu gereksiz olabilir.

Dolayısıyla amaç “dünyanın final ontology'sini” kurmak değil, soruya göre gerekli belirlenimleri seçen fakat neyi dışarıda bıraktığını unutmayabilen bir temsil rejimi geliştirmektir.

Bu bizi önemli bir ilkeye götürür:

Hesaplanabilirlik, ontolojik indirgeme olmak zorunda değildir. Bir ilişkinin belirli yönlerini işlenebilir hale getirmek, o ilişkinin bundan ibaret olduğunu iddia etmek değildir.

15. Geçici ama süreklilik taşıyan concept/world state

Uzun vadeli mimari hipotezimizde sistem yalnız input token dizisi üzerinde anlık hesap yapmaz. Girdilerden beslenen ve yeni kanıtla değişebilen geçici bir world/concept state taşır.

Bunu tek bir zorunlu veri yapısıyla tanımlamıyoruz. Anlatmak için şu kavramsal parçaları ayırabiliriz:

  • entities / referents: o problemde ayrıştırılması gereken şeyler veya aktörler;
  • relations: bunların birbirini nasıl koşulladığına ilişkin bağlantılar;
  • process state: ilişkilerin zaman içinde nasıl değiştiği;
  • scope: bir belirlenimin nerede ve ne zaman geçerli olduğu;
  • evidence: state'in hangi gözlem veya kayıtlara dayandığı;
  • rivals: aynı kanıtla hâlâ uyumlu alternatif reconstruction'lar;
  • history / lineage: state'in hangi revizyonlardan geçtiği;
  • failure conditions: hangi yeni kanıtın mevcut representation'ı zorlayacağı.

Bunların final sistemde açık semboller olması şart değildir. Continuous vector state, relational slots, graph-like latent, recurrent memory veya başka bir yapı aynı semantik işlevi yerine getirebilir.

Kritik soru veri yapısının adı değil, şudur:

Model, bu ayrımlara davranışsal ve nedensel olarak erişebiliyor mu; yoksa bütün anlatı sonradan üretilmiş bir açıklama mı?

16. Core'un mimarideki yeri

Bugünkü çalışma hipotezini en basit biçimde şöyle çizebiliriz:

TEXT / IMAGE / AUDIO / ACTION / MEASUREMENT
                    │
                    ▼
        neural encoder / language substrate
                    │
                    ▼
          binding + state construction
                    │
                    ▼
       dynamic relational / process state
                    │
                    ▼
      COMPUTATIONAL DIALECTICS CORE
       ├─ frame/scope alignment
       ├─ mismatch diagnosis
       ├─ selective revision
       ├─ rival reconstruction
       ├─ discriminating action
       ├─ schema/concept revision
       └─ mediated reconstruction
                    │
                    ▼
        revised active latent state
                    │
                    ▼
         decoder / policy / action

Bu diyagram final architecture değildir. Bir sorumluluk ayrımıdır.

16.1 Devim Candidate Cognitive Architecture

Bu noktadan itibaren kitap iki şeyi özellikle ayıracaktır: mimari tez ile kanıtlanmış mimari. Devim için bugün en güçlü aday hat şudur:

observation / language / action
            │
            ▼
neural perception / encoder
            │
            ▼
concept binding
(entity / event / relation)
            │
            ▼
dynamic world / concept state
(relations / scope / evidence / history / rivals)
            │
            ▼
Computational Dialectics Core
(abstraction / mediation / contradiction diagnosis /
rival reconstruction / discriminating action / revision)
            │
            ▼
latent state transition / rollout
            │
            ▼
decoder / policy / action

Bunun temel iddiası, düşünmenin zorunlu olarak token dizisi içinde ilerlemek zorunda olmadığıdır. Tokenlar güçlü giriş ve çıkış yüzeyleri olabilir; fakat sistemin üzerinde düşündüğü geçici nesne, ilişkileri ve revizyon koşulları olan bir world/concept state olabilir. Bu görüşte word != concept ve embedding != concept: embedding kavrama erişimin bir parçası olabilir, fakat kavramın kendisi yalnızca tek bir vektör veya kelime olarak tanımlanmaz.

Bu bölüm bugün bir candidate architecture anlatır. Kitap, ileride deney sonucu değişirse diyagramı korumak uğruna sonuçları eğip bükmeyecektir. Mimari deneylerden öğrenerek değişecektir.

16.2 Mimari olgunluk etiketleri

Bundan sonra bu kitabın mimari parçaları dört statüden biriyle izlenecektir:

  • HYPOTHESIS: teorik olarak gerekçeli, fakat henüz kontrollü deney desteği yok;
  • TESTING: executable benchmark veya ablation ile aktif olarak sınanıyor;
  • SUPPORTED: matched baseline ve preregistered gate altında tekrarlanabilir davranışsal/causal evidence var;
  • INTEGRATED: mekanizma Devim'in gerçek model hattına bağlanmış ve entegrasyon sonrası capability/failure testlerinden geçmiş.

Bugün selective relational revision TESTING durumundadır. Rival reconstruction, discriminating action, concept/schema revision ve mediated reconstruction HYPOTHESIS düzeyindedir. B0-v2'nin stability sonucu yalnız deneysel baseline'ın çalıştırılabilir olduğunu destekler; Dialectical Core capability'sini desteklemez. Devim'in bütün üst mimarisi ise henüz INTEGRATED değildir.

16.3 Ne zaman “Devim mimarisi” diyeceğiz?

Bir parçayı kitapta anlatmak için Devim'e entegre edilmiş olmasını beklemeyeceğiz; aksi halde araştırmanın nasıl doğduğunu ve neden değiştiğini kaybederiz. Fakat onu Devim'in doğrulanmış mimarisi olarak adlandırmak için daha sert bir eşik kullanacağız:

  1. primitive kendi kontrollü benchmark'ında ordinary/generic alternatiflere karşı gerekçesini göstermeli;
  2. avantaj farklı seed veya distribution altında ayakta kalmalı;
  3. causal/ablation evidence davranışsal skoru açıklayabilmeli;
  4. Devim'e entegrasyon sonrası dil üretimini veya temel FORM capability'sini bozmamalı;
  5. aynı capability daha basit bir mekanizmayla elde edilebiliyorsa özel dialectical primitive iddiası geri çekilmeli;
  6. entegrasyon sonrası gerçek kullanımda state revision veya reasoning avantajı ölçülebilmeli.

Bu eşikler geçildiğinde kitapta statü SUPPORTED → INTEGRATED olarak değişir ve bu diyagram artık yalnız araştırma programı değil, Devim'in reference architecture'ının bir parçası haline gelir.

Language substrate metni işleyebilir; fakat core'un işi felsefi cümle üretmek değildir. Core, state'in nasıl kurulduğu ve değişen kanıt karşısında nasıl yeniden kurulduğu üzerinde etkili olmalıdır.

Ayrıca core dışarıdan çalışan bir Python kural motoru olup neural modele yalnız son cevabı yazdırırsa, araştırdığımız neural architecture iddiasını gerçekleştirmiş olmayız. Hybrid sistemler yararlı olabilir, fakat neyin neural, neyin symbolic ve hangisinin asıl capability'yi taşıdığı causal ablation ile ayrılmalıdır.

17. Transformer bu resimde nerede?

Transformer üç farklı rolden birini veya birkaçını taşıyabilir:

  1. güçlü bir dil encoder/decoder substrate'ı;
  2. state içindeki ilişkileri işleyen hesaplama katmanı;
  3. core'un kendisinin bir kısmı.

Araştırma Transformer'ı dışlamaz. Fakat core fikrini Transformer'ın bugünkü biçimiyle özdeşleştirmez.

Eğer vanilla veya memory-augmented Transformer aynı state-revision davranışını matched compute altında öğreniyorsa, özel architecture eklemek için sebep azalır. Eğer recurrent state, slots, SSM veya özel relational update belirgin avantaj sağlıyorsa o zaman mimari değişiklik gerekçelendirilmiş olur.

Bu nedenle “Transformer yerine ne?” sorusuna bugün tek bir isim vermek erken olur. Doğru sıra şöyledir:

hangi computation gerekiyor → hangi representation bunu taşıyor → hangi architecture bunu en iyi öğreniyor → scale arttığında avantaj sürüyor mu?

18. Tarihsel bağlam nasıl state'e girer?

Tarihsel düşünmek, modele tarih bilgisi yüklemekten daha fazlasıdır. Aynı ilişki farklı dönemlerde farklı koşullar altında başka bir rol oynayabilir. Bu yüzden state yalnız “ne oldu?” sorusunu değil, “hangi yapı içinde ne anlama geliyordu?” sorusunu da taşıyabilmelidir.

Burada iki grafiği zihinsel olarak ayırmak yararlıdır:

Olay grafiği: hangi olay hangi olaydan önce veya sonra gerçekleşti?

Yapısal/bağımlılık grafiği: hangi ilişki veya mekanizma hangi sonucu koşulluyor veya yeniden üretiyor?

Bu ikisi aynı değildir. Bir kurum tarihsel olarak önce kurulmuş olabilir fakat açıklamada temel mekanizma olmayabilir. Tersine, analitik olarak önce anlattığımız bir ilişki tarihsel olarak daha sonra biçimlenmiş olabilir.

Bir computational system bu ayrımı koruyamazsa tarihsel anlatıyı nedensel açıklama sanabilir veya yapısal açıklamayı kronolojik hikâyeye çevirebilir.

19. Toplumsal ilişkiyi örnek üzerinden düşünmek

Şöyle bir gözlem düşünelim:

“Otomasyon üretkenliği artırdı ama çalışma süresi aynı oranda azalmadı.”

Kötü bir “diyalektik” sistem hemen “kapitalizmin çelişkisi” etiketi basabilir. Bu bizim istediğimiz davranış değildir.

Daha dikkatli sistem önce hangi belirlenimlerin eksik olduğunu sorar:

  • üretkenlik nasıl ölçülüyor?
  • çalışma süresi kimler için ve hangi dönemde?
  • üretim miktarı değişti mi?
  • istihdam sayısı değişti mi?
  • ücret, mülkiyet, rekabet ve yatırım kararları nasıl değişti?
  • teknoloji maliyeti ve talep ne yaptı?
  • farklı sektörlerde aynı pattern var mı?

Sonra birden fazla reconstruction kurulabilir. Örneğin biri artan üretimin ek talebi karşılamak için kullanıldığını, diğeri rekabet baskısının kazanımı çalışma süresine değil üretim hacmine yönelttiğini, üçüncüsü ölçümün farklı işçi gruplarını karıştırdığını öne sürebilir.

Bu rivals'in değeri politik etiketlerinde değil, farklı gözlem veya müdahale sonuçları üretmelerindedir. Hangi veri onları birbirinden ayırır? Hangi koşul değiştiğinde prediction farklılaşır? Computational Dialectics burada başlar.

Bu örnek aynı zamanda toplumsal teori ile computational mechanism arasındaki sınırı gösterir. Modelin görevi önceden doğru ilan edilmiş bir Marxist sonucu geri üretmek değildir. Görevi ilişkisel/historik representation kurmak, varsayımları görünür hale getirmek, rival explanations üretmek ve evidence'ın hangilerini desteklediğini sınamaktır.

20. Mediation: eksik halka uydurmak değil

Bir sistem doğrudan görünen A ve B arasındaki ilişkiyi açıklayamıyorsa araya “gizli mekanizma” uydurmak kolaydır. Bu, mediation değildir; confabulation olabilir.

Bizim çalışma kuralımız daha serttir:

Bir mediator adayı ancak yeni bir ayrım, prediction, observation veya intervention consequence üretiyorsa araştırma state'ine yükseltilmelidir.

Örneğin iki rival explanation aynı observable sonuçları her durumda veriyorsa aralarındaki “mekanizma farkı” henüz operasyonel değildir. Yeni veri onları ayıramıyorsa sistem unresolved kalabilmelidir.

21. Rival reconstruction ve discriminating action

Birden fazla açıklama tutmak tek başına başarı değildir. Model aynı cümleyi farklı kelimelerle üç kez yazabilir.

Gerçek rivals en az bir yerde ayrışmalıdır:

  • farklı prediction;
  • farklı scope;
  • farklı intervention sonucu;
  • farklı evidence-update davranışı.

Bir sonraki capability bunun doğal devamıdır: hangi yeni gözlem bu rivals'i en hızlı veya en güvenilir biçimde ayırır?

Bu, Computational Dialectics'i yalnız “yorum üreten” bir sistem olmaktan çıkarıp aktif araştırma döngüsüne bağlayabilir:

state → rivals → discriminating action → external result → revised state

Bu döngü insan praksisinin eşdeğeri değildir. Makine açısından daha dar bir external discrimination loop'tur.

22. Soyuttan somuta computational olarak ne demek olabilir?

“Somut” burada daha uzun cevap, daha çok node veya daha fazla ayrıntı demek değildir.

Çalışma hipotezimizde soyutlama, belirli bir relation'ı geçici olarak öne çıkarırken dışarıda bıraktığı koşulları kaydetme işlemidir. Concrete reconstruction ise gerekli determinations'ı yeniden ilişkilendirerek sistemin nasıl üretildiğini veya yeniden üretildiğini açıklayan bir bütün kurmaya çalışır.

Bu yüzden iyi reconstruction şu soruları taşımalıdır:

  • Hangi ilişkiler sonucu üretiyor?
  • Hangi aracı süreçler gerekli?
  • Hangi karşı eğilimler var?
  • Hangi koşullarda ilişki yön değiştiriyor?
  • Hangi kısım hâlâ unresolved?

Bunun ölçülmesi zordur ve bugün OPEN durumundadır. “Graph density” veya response length gibi kolay proxy'leri concreteness olarak kabul etmeyeceğiz.

23. Concept/schema revision ne zaman gerekir?

Bazen sorun mevcut şema içindeki bir değerin yanlış olması değildir. Şemanın kendisi yetersizdir.

Örneğin tek bir kategori iki farklı koşul kümesinde sistematik olarak zıt prediction üretiyorsa yalnız confidence değiştirmek yetmeyebilir. Concept split gerekebilir. Tersine, iki ayrı kavram sürekli aynı ilişkileri, aynı prediction'ları ve aynı intervention davranışını üretiyorsa merge daha iyi olabilir.

Uzun vadeli core'un güçlü iddialarından biri budur: representation'ın decomposition'ı da evidence altında değişebilir.

Ama bu capability henüz deneysel olarak kurulmuş değildir. D1-B'nin relation rebinding görevi, bu daha büyük problemin kontrollü bir öncülüdür.