Docs

Tipler

Özet

  • Bir tip, platformun bir bileşenin çıktısının başka bir bileşenin girdisini besleyip besleyemeyeceğine karar vermek için kullandığı sözleşmedir. Tipler edit zamanında, deploy zamanında ve bir değerin sistemden aktığı her yerde kontrol edilir.
  • Tipler üç kategoride gelir: atomik tipler (Int32, Double, String, Bool, …), diğer tiplerden inşa edilen bileşik tipler (listeler, tuple'lar, record'lar, opsiyoneller, toplamlar) ve register'dan gelen, tiplenmiş ikili payload'ları meta verileriyle birlikte taşıyan adlandırılmış tipler (Image, Tensor, AudioFrame, BoundingBox, …).
  • Tanımlayıcı büyük/küçük harfi anlamlıdır. Küçük harfli tanımlayıcılar (t, a, frame) generic tip değişkenleridir; büyük harfli tanımlayıcılar (Image, Double, BoundingBox) atomik tipler veya adlandırılmış tiplerdir. Platform, generic'leri edit zamanında onlara bağlanan somut tiplere karşı birleştirir.
  • Örtük zorlama (coercion) yoktur. Bir String, bir Image olamaz. İki slot anlaşmazsa, platform bağlantıyı reddeder ve önceki tipi, sonraki tipi ve birleşmenin nerede başarısız olduğunu raporlar. Çözüm bir dönüştürücü bileşendir.
  • Parametre değerleri JSON değil, pipelang literalleridir — string'ler çift tırnaklı, tuple'lar parantez, listeler köşeli parantez, record'lar süslü parantez kullanır. Literal, parametrenin bildirilmiş tipiyle eşleşmelidir; uyuşmazlıklar change-parameter çağrısında reddedilir.

Bu platformda bir tip nedir

Bir tip, bileşenler arasında hareket eden bir değerin bildirilmiş biçimidir: bir çıkış slotunun ne ürettiğini ve bir giriş slotunun ne kabul ettiğini söyleyen sözleşme. Yapay zeka iş akışları, farklı ekiplerden, model framework'lerinden ve platform nesillerinden bileşenleri aynı backend'e komponse eder, bu yüzden her wire'ın onu geçen verinin ortak bir açıklamasına ihtiyacı vardır — ham byte'lar yerine yapılandırılmış bir tensor, önceden yeniden boyutlandırılmış bir görüntü yerine tüketicinin yeniden boyutlandırması gereken biri, normalize edilmiş yerine piksel koordinatlarındaki bir bounding box listesi. Tip, o açıklamadır.

Her bileşen, her giriş slotunun, her çıkış slotunun, her konfigürasyon parametresinin ve her dosya slotunun tipini bildirir. Her backend, o slotları zorunlu kılınan tiplenmiş sözleşmeyle birbirine bağlar. Platformun tip çıkarımı, edit zamanında tüm grafik boyunca çalışır ve bir sözleşmeyi ihlal edecek herhangi bir mutasyonu reddeder — mutasyon denendiği anda, deploy'dan önce.

Bileşen yazarları sözleşmeyi yazar; sonraki herkes — grafik yazarları, gelecekteki sürdürücüler, platformu CLI'dan süren yapay zeka ajanları — onu bileşenin kaynak kodunu okumadan manifest'ten okur. Manifest, spesifikasyondur.

Zihinsel model

Bir pipelang tipi, platformun hakkında akıl yürüttüğü her değer için biçim dilidir. Üç kategori her şeyi kapsar:

atomic                 composite                   named
─────────              ────────────────            ─────────
Int32, UInt32          [Image]                     Image
Int64, UInt64          (Double, String)            AudioFrame
Float, Double          {x: Double, y: Double}      Tensor
Bool, Char             Image | AudioFrame          BoundingBox
String, Bytes          [BoundingBox]               Polygon<Double>

Atomik tipler dil düzeyindeki skalerlerdir: çoğu tip sisteminin tanıdığıyla eşleşen on sayısal ve değer tipi. Bytes tek kasıtlı kaçış noktasıdır — opak ikili blob, daha zengin bir tip uymadığında az kullanılır.

Bileşik tipler yapıcılar kullanılarak diğer tiplerden inşa edilir. Listeler [t], tuple'lar (a, b, c), record'lar {x: A, y: B}, toplam tipler a | b. Bir bileşik tip, başka bir bileşik tip dahil herhangi başka bir tipi sarabilir — [[Image]] görüntü listelerinin bir listesidir.

Adlandırılmış tipler platformun tip register'ında yaşar. Image, byte'ların bir tensor'u değildir; görüntü işleyen her bileşenin üzerinde anlaştığı, sonraki tüketicilerin yeniden türetmeden güvenebileceği biçim, kanal sırası ve meta veriyle birlikte gelen adlandırılmış tiptir. Aynısı AudioFrame (örnekleme hızı, kanal sayısı, encoding), Tensor (biçim, dtype), BoundingBox (koordinatlar, frame referansı) için. Adlandırılmış register, tiplenmiş sözleşme ile alan semantiği arasındaki köprüdür.

Image, Tensor ve geri kalanının arkasındaki register için bkz. Adlandırılmış tipler.

Generic'ler küçük harfli tanımlayıcılar kullanır

„t bir yer tutucu mu yoksa gerçek bir tip mi" diye merak ettiğinizde bu çerçeveyi kullanın.

Tanımlayıcı büyük/küçük harfi pipelang'de anlamlıdır. Küçük baş harfle yazılan bir tip (t, a, frame) bir generic tip değişkenidir: platformun nihayetinde bağlandığı somut tipe karşı birleştirdiği bir yer tutucu. Büyük baş harfli bir tip (Image, Double, BoundingBox) somut bir ilkel veya adlandırılmış bir tiptir — yer tutucu değil.

Büyük/küçük harf kuralı, bileşenleri polimorfik yapan şeydir. [t] → [t] olarak bildirilmiş bir geçişli (passthrough) tampon, [Image], [AudioFrame], [Tensor] veya herhangi başka bir eleman tipi üzerinde çalışır — platform t'yi bileşenin bildirimi boyunca tutarlı şekilde birleştirir. Tampon yazarı bileşeni bir kez yazar; grafik yazarı onu her yerde yeniden kullanır.

Büyük/küçük harf anlamı seçer. [T] (büyük harf) yazmak, register'da muhtemelen var olmayan T adlı bir adlandırılmış tipi kabul eden bir slot bildirir — platform onu „unknown named type" ile reddeder. [t] yazmak generic bir slot bildirir. Kural: küçük harf = değişken; büyük harf = somut.

Kontrol edit zamanında çalışır

Platformun bir connect çağrısını neden reddettiğini merak ettiğinizde bu çerçeveyi kullanın.

Bir backend iki vertex'i birbirine bağladığında, platformun tip çıkarımı önerilen kenar boyunca — ve tüm grafik boyunca — çalışır ve bağlantının sağlam olup olmadığına karar verir. Başarılı bir wire, kaynağın çıkış tipinin hedefin giriş tipiyle, tutarlı şekilde örneklenmesi gereken generic değişkenleri de hesaba katarak birleştiğini gösterir. Başarısız bir wire, platformun operasyonu reddettiğini ve önceki tipi, sonraki tipi ve birleşmenin başarısız olduğu noktayı raporladığını gösterir. Operasyon kaydedilmez; grafik geçerli kalır.

Kontrol, tiplerin göründüğü her yeri kapsar. Bir Image çıkışını bir [BoundingBox] girişine bağlamak reddedilir. Bir parametreyi bildirilmiş tipe uymayan bir literale ayarlamak change-parameter'da reddedilir. file_type: öğesi tüketen slota uymayan bir dosyayı bağlamak add-file'da reddedilir. Bir vertex'in pinlenmiş release'ini, I/O tipleri sonraki bağlantıyla birleşmeyen daha yeni bir sürüme değiştirmek deploy'dan önce işaretlenir. Platformun deploy ettiği grafik, yapısı gereği platformun doğruladığı aynı biçimdir.

Örtük zorlama yoktur. Bir String değerini bir Image slotuna beslemek için, aralarına bir dönüştürücü bileşen yerleştirin; platform boşluğu sessizce kapatmaz. Edit zamanı kontrolü, kod tabanlı kompozisyon sistemlerinde sessiz zorlamanın aksi takdirde tip uyuşmazlıklarını ortaya çıkardığı çalışma zamanı yolundan onları uzaklaştırır.

Açık tipler ve nasıl çözümlendikleri

Siz oluştururken generic bir bileşenin veya bir oneof[…] slotunun neden „kararsız" kalmasına izin verildiğini merak ettiğinizde bu çerçeveyi kullanın.

Edit zamanı kontrolü her tipin somut olmasını zorlamaz — generic ve polimorfik bileşenleri mümkün kılan budur. [t] → [t] olarak bildirilmiş bir tampon, ona somut bir akış bağlanana kadar t'yi açık tutar; bir oneof[Image, DepthImage] slotu, çevreleyen bağlantılar onu tek bir varyanta zorlayana kadar çözümlenmemiş bir bound olarak kalır. Platform bu açık tipleri, grafik oluşturuldukça bağlandıkları somut tiplere karşı birleştirir. Etiketli bir bound oneof t[…] daha ileri gider — korelasyon yapar, aynı etiketli her oluşumu aynı varyanta pinler, böylece bir seçim geri kalanını sabitler.

Refinement'lar açmak yerine daraltır. Int32<0..=255>, String<"a" | "b" | "c">, Int64<%8> ve String<email>, zaten somut bir tabana bir yüklem ekler ve tiple birlikte çıkarım boyunca kimliğinin parçası olarak yolculuk eder — Int64 ve Int64<%8> ayrı tiplerdir. Bir refinement'ın tabanı her zaman somut olduğundan, bir refinement bir tipi asla çözümlenmemiş tutmaz; yalnızca tipin kabul ettiği değerleri kısıtlar. (Bir parametrenin refinement'ını değiştirmek veya kaldırmak parametreyi yeniden tipler ve platform yeni tipin artık kabul etmeyeceği saklanan herhangi bir değeri temizler.)

Deploy her tipin somut olmasını gerektirir

Bir backend'i editlemekle deploy etmek arasında neyin değiştiğini merak ettiğinizde bu çerçeveyi kullanın.

Edit zamanı kontrolü açık tiplere karşı hoşgörülüdür; deploy değildir. Bir backend'i deploy etmek, tüm grafik boyunca katı çıkarım çalıştırır ve her wire ile her konfigürasyon parametresi tamamen somut bir tipe çözümlenmelidir. Hâlâ açık olan herhangi bir şey — kalıntı bir tip değişkeni, bir pack değişkeni, çözümlenmemiş bir oneof[…] bound — belirsiz bir sözleşmeyle bir konteyner başlatmak yerine deploy'u başarısızlığa uğratır. Çözümlenmemiş bir bound, somut bir pin gerektirir olarak raporlanır.

Grafiği tiplemenin getirisi budur: bir backend, herhangi bir wire üzerinde belirsiz bir biçimle çalışma zamanına ulaşamaz. Deploy zamanına kadar, her generic bağlanmış ve her oneof, çevresindeki bağlantılarla tek bir varyanta daraltılmıştır. Bir slot hiç kısıtlanmadıysa — hiçbir somut şeye bağlanmamış generic bir bileşen, grafiğin asla pinlemediği sınırlı bir slot — çözüm, deploy etmeden önce kabloyu tamamlamaktır. Çalışan sistem, tam olarak katı çıkarımın tamamen çözümlediğidir.

Pipelang literalleri JSON değildir

change-parameter'a ilk kez uzandığınızda ve platform geçerli JSON gibi görünen şeyi reddettiğinde bu çerçeveyi kullanın.

Parametre değerleri JSON değil, pipelang literalleridir. Dilbilgisi küçük ama spesifiktir: string'ler çift tırnaklı, tuple'lar konumsal elemanlarla parantez kullanır, listeler köşeli parantez, record'lar adlandırılmış alanlarla süslü parantez kullanır, boolean'lar küçük harflidir, kayan noktalılar bir ondalık nokta içermelidir (1.0, 1 değil) ve boş tuple () kanonik „değer yok" / unit'tir.

Hatırlamaya değer birkaç literal biçimi:

  • String'ler: "google/vit-base-patch16-224". Her zaman çift tırnaklı.
  • Sayılar: 42 (tamsayı), 0.5 (kayan noktalı — ondalığa dikkat), 0x2a (hex), -1.
  • Boolean'lar: true, false. Küçük harfli.
  • Tuple'lar: (0.0, 0.0, 0.0). Tek elemanlı tuple'lar sonda virgül gerektirir: (42,).
  • Listeler: [0.1, 0.2, 0.3], [(8, 0.1), (4, 0.3)]. Sonda virgül opsiyoneldir.
  • Record'lar: {x: 1.0, y: 2.0}. Adlandırılmış alanlar, opsiyonel sonda virgül.

Shell çağrıları, shell pipelang parse etmeden önce parantezleri, köşeli parantezleri veya tırnakları yemesin diye tam literali tek tırnağa almalıdır:

ppl backend change-parameter <bid> --vertex 3 --name threshold \    --type Double --value '0.5'ppl backend change-parameter <bid> --vertex 3 --name class_thresholds \    --type '[(UInt64, Double)]' --value '[(8, 0.1), (4, 0.3)]'

Tam dilbilgisi — her literal biçimi, JSON-pipelang farkları, adlandırılmış-tip register kuralları, generic'ler kısıtlamaları — Tip sözdizimi referansı içinde yer alır.

Hangi biçime ne zaman başvurulur

Bu bölümü tip kategorilerine hızlı bir rehber olarak kullanın.

Atomik tipler bariz durumlar için doğrudur — sayılar, string'ler, boolean'lar, opak byte'lar. Onları konfigürasyon parametreleri olarak, skaler çıktılar olarak, daha zengin bileşik tipler içindeki elemanlar olarak kullanın.

Record'lar, veri yapısal olduğunda (opak byte yok, medya meta verisi yok) ve hiçbir katalog adlandırılmış tipi uymadığında doğrudur. Bir 3D nokta için bir {x: Double, y: Double, depth: Double}, üç ayrı parametreden daha açıktır. Record'lar inline tanımlıdır; register'da adlandırılmış bir giriş olarak değil, yazdığınız tip olarak var olurlar.

Listeler ve tuple'lar, değer bir koleksiyon olduğunda doğrudur. Listeler homojendir ([BoundingBox] bounding box'ların bir listesidir); tuple'lar heterojen konumsaldır ((Image, [Double], String) farklı tiplerden üç değer taşır). Konumlar anlamlı olduğunda tuple'lara başvurun; konumların adlara ihtiyacı olduğunda record'lara başvurun.

Toplam tipler (a | b), bir slot gerçekten iki ilişkisiz biçimi işlediğinde doğrudur — ya Image ya da AudioFrame yayan bir medya demultiplekseri, çıktısı girdisine bağlı çok modlu bir model. Toplam tipler bilinçli bir seçim olmalıdır, daha zengin bir adlandırılmış tip tanımlamaktan kaçınmanın bir yolu değil.

Adlandırılmış tipler, byte'larla birlikte yolculuk eden meta verisi olan alana özgü her şey için doğrudur — biçim ve kanal sırası olan görüntüler, örnekleme hızı olan ses, biçim ve dtype'ı olan tensor'lar. Adlandırılmış register, farklı ekiplerden bileşenlerin sözleşmeyi her seferinde yeniden türetmeden bir Image'ın ne olduğu üzerinde anlaşmasını sağlayan şeydir.

Generic'ler (t, a), biçim koruyan bileşenler için doğrudur — tamponlar, örnekleyiciler (sampler), kapılar (gate), bölücüler (splitter), herhangi bir eleman tipi üzerinde çalışan transformasyonlar. Aynı bileşen Image, AudioFrame, Tensor ve grafiğin onun içinden bağladığı herhangi başka bir tip boyunca yeniden kullanılır.

Bu nereye uyar

Tip sistemi, platformun geri kalanının üzerine inşa edildiği sözleşmedir. Backend'ler kötü kablolamayı edit zamanında reddetmek için ona güvenir. Bileşen release'leri değişmezliği anlamlı kılmak için ona güvenir — tiplenmiş sözleşme sürümün halka açık yüzüdür. Deployment'lar konteynerlerin başlangıçta ne beklediğini bilmek için ona güvenir. Kanıt döngüleri (proof loops) bir çıktının hangi biçimde olması gerektiğini bilmek için ona güvenir. Uygulamalar UI ihtiyaçlarını endpoint biçimlerine bağlamak için ona güvenir.

Bileşen başına ad-hoc doğrulamalı tipsiz akışlar yaygın alternatiftir ve kablolama uyuşmazlıklarını çalışma zamanına iter. Tipleme kontrolü edit zamanına taşır: yazarlar sözleşmeyi bir kez bildirir ve sistemin geri kalanı ona karşı komponse eder.

İlgili

Bu sayfa yardımcı oldu mu?