Modelin gördüğü ile tesisteki gerçek arasındaki uçurum
Bir LLM'e "bu alarm logunu analiz et" dediğinizde model size alarm kodlarının olası anlamlarını genel endüstriyel bilgiye dayanarak söyler. Ancak sizin tesisinizde o alarm kodunun gerçek tanımını, hangi müdahalenin işe yaradığını veya kaç kez aynı kod çıkıp kendiliğinden düzeldiğini bilmez. Bu farkı görmezden gelen kullanıcılar model çıktısını "analiz" zanneder; oysa iyi yazılmış bir tahmin yürütme egzersizinden fazlası değildir.
Sensör sapması, eksik örnekleme ya da yanlış birim dönüşümü varsa LLM yine de size bir cevap üretir; çoğu zaman çok ikna edici cümlelerle. Kök neden analizi için olay öncesi ve sonrası zaman serisi, tam alarm metni ve sürücü hata kodu birlikte olmak zorundadır. Bu üçü tutulmazsa model ne kadar gelişmiş olursa olsun boş yerden konuşur.
LLM'lerin gerçekten işe yaradığı durumlar da vardır: alarm açıklamalarını operatör dilinde Türkçeleştirmek, rutin bakım checklist'ini metinden üretmek, hata loglarının haftalık özet raporunu hazırlamak. Bu kullanımlar saatlerce süren tekrar işlerini dakikaya indirir. Amaç doğru belirlenince LLM güçlü bir araçtır; "tesisi görsün ve her şeyi çözsün" beklenince hayal kırıklığı kaçınılmazdır.
Veri disiplini olmadan AI projesi olmaz
AI projesine başlamadan önce sorulması gereken ilk soru: hangi değişken kaynak gerçektir? Aynı anda PLC, HMI ve SCADA farklı değerler gösteriyorsa — ki bu nadir değildir — hangisine güveneceğinizi bilmeden modele ne verirseniz verin çıktı güvenilmez olur. Bu soruyu "AI belirler" diye geçiştirmek mümkün değildir; mühendislik kararıdır.
Örnekleme hızı ve filtre seçimi kritiktir. Tekstil hattında bir kopuk olayını anlamak için 10 saniyelik trend yeterliyken, yüksek hızlı eksen problemlerini milisaniye çözünürlüğünde bakmanız gerekebilir. "Her şeyi en yüksek frekansta topla" yaklaşımı disk, lisans ve ağ maliyeti üretir; üstelik veriyi analiz edilemez hale getirebilir.
Etiketleme meselesi de göz ardı edilemez. "Duruş kodu 47" dediğinizde model bunun ne anlama geldiğini bilmez; ancak "duruş kodu 47 = üst silindir aşınması kaynaklı kopuk, vardiya A'da haftada ortalama 2 kez" yazılmışsa artık anlamlı bir bağlam vardır. Bu etiketleri kurmak AI'nın değil, operatör ve mühendis deneyiminin işidir. OT tarafı toparlanmadan — zaman senkronu, alarm metni, güncel yedek proje, okunabilir SCADA — üzerine kurulacak hiçbir analitik uzun ömürlü olmaz.
Sahada pratik: önce ne yapılır?
İlk adım veri envanteri çıkarmaktır: hangi PLC hangi veriyi tutuyor, hangi alarm loglanıyor, hangi SCADA etiketleri gerçekten güvenilir? Bu soruları yanıtlayan bir tablo olmadan AI konuşmak teorik kalır. Bursa ve Marmara'da ziyaret ettiğimiz tesislerin büyük çoğunluğunda bu envanter yazılı değildir; mühendislerin kafasındadır.
İkinci adım öncelik belirlemektir: en pahalı duruşa sebep olan arıza nedir? Tekstil hattında fantazi iplik kopuğu günde iki vardiyayı etkiliyor ve kök neden bulunamamışsa oradan başlamak doğrudur. Tüm üretime AI "sürümek" yerine, en net sorunun en net verisini toplayıp küçük bir döngü kurmak çok daha hızlı sonuç verir.
Üçüncüsü ve belki en önemlisi: hangi soruların insanı, hangilerinin veriyi gerektirdiğini ayırt etmek. Bir operatörün yirmi yıllık makine bilgisi bazen binlerce satır logdan daha hızlı sonuç verir. AI bu bilgiyi yapılandırmaya ve belgeye dönüştürmeye yardım eder; onu yoktan üretemez. Sahada gördüğümüz başarılı örnekler, deneyimli operatörü devre dışı bırakmayı değil, onun bilgisini sisteme yazmayı hedefleyenlerdir.
Ne vaat ediyoruz, ne etmiyoruz
Mace olarak otomasyon projelerinde veri altyapısını kurmanın önce geldiğini düşünüyoruz. Alarm metni Türkçe, anlaşılır ve doğru; SCADA zaman damgası PLC ile uyumlu; yedek proje versiyonlanmış; sürücü parametreleri arşivli — bunlar sağlamsa üstüne kurulacak analitik katmanı için zemin hazırdır.
Ölçülmemiş yüzde verimlillik artışı veya "AI ile kapalı kalma sıfır" gibi vaatler üretmiyoruz. Kişisel veri veya üretim sırrı taşıyan loglar dışarı çıkmadan önce KVKK kapsamı ve tesis bilgi güvenliği politikası ayrıca değerlendirilmek zorundadır.