OCTATUS / YETENEKLER

Yapay zekâ

Yapay zekâyı model, veri ve süreç bağlamıyla kullanın; önerileri izlenebilir ve değerlendirilebilir tutun.

Bu konuda görüşelim ↗

Mühendislik modelini inceleyen uzman, temsili görsel

BAĞLAMA DUYARLI YARDIM

Bağlamı koruyarak ilerleyin.

Octatus içinde yapay zekâ yetenekleri, model ile gerçek dünya arasındaki ilişkiyi görünür ve çalışılabilir kılar.

Model, doküman ve operasyon bağlamında soruları doğal dille araştırın
Mühendislik ve operasyon ekipleri için bağlama dayalı değerlendirmeler hazırlayın
Yapay zekâ önerilerini kaynakları ve insan değerlendirmesiyle birlikte ele alın

UYGULAMA, MİMARİ VE TEKNİK KABUL

Yapay zekâ: mühendislik yaklaşımı

Yapay zekâ ve BIM/GIS birlikteliğinde asıl değer, mühendislik bilgisini kaynak ve fiziksel varlık bağlamında bulunabilir kılmaktır. Bu rehber RAG, semantik arama, model doğrulama, anomali analizi, siber güvenlik ve kullanıcı kabulü gibi konuları gerçekle hayal edilen yetenekleri karıştırmadan inceler.

TEKNİK BÖLÜM / 01

Yapay zekâyı varlık bağlamında kullanmak

Kurumsal mühendislik verisi üzerinde yapay zekâ kullanımı yalnızca genel sorulara akıcı cevap vermek değildir. Kullanıcının sorduğu ekipman, bulunduğu mahal, model revizyonu ve yetkili doküman doğru eşleştirilmelidir. Bir fanın arıza nedenini soran teknisyene başka üreticinin cihaz kılavuzundan cevap verilmesi risk yaratabilir. Aynı model nesnesinin tasarım ve as-built sürümlerinde farklı teknik özellikleri olabileceği için belge ve kaynak sürümünün cevapla ilişkili kalması gerekir.

Octatus fiziksel varlık ve BIM/GIS bağlamına odaklanırken yapay zekâ bu bağlama dayalı araştırma ve değerlendirme desteği sağlayabilir. Yanıtın hangi belge, ölçüm veya model öğesine dayandığı kullanıcı tarafından kontrol edilebilmelidir. Modelin kaynakları eksikse kesin bir teknik sonuç uydurmak yerine belirsizlik göstermesi beklenir. Kritik mühendislik kararı ve saha komutları ayrı uzman onayı ve süreçlerle yönetilir.

TEKNİK BÖLÜM / 02

RAG ve kaynak temelli soru cevaplama

Retrieval-Augmented Generation yaklaşımı soruyla ilgili belgeleri arayıp üretim modeline bağlam olarak sunabilir. Bunun değeri büyük miktarda proje dokümanı, teknik şartname ve bakım kaydı arasında kaynak bulmayı kolaylaştırmasıdır. Ancak arama sonucunun yüksek benzerlik puanı fiziksel olarak doğru ekipmana ait olduğunu göstermez. Dokümanlar farklı tesisler, revizyonlar ve çalışma izinleri kapsamında olabilir. Erişim sınırı ve varlık eşlemesi arama aşamasında uygulanmalıdır.

Arama sonucunda belge kimliği, sürüm, yayın durumu, ilgili varlık ve sayfa veya bölüm referansı korunmalıdır. Bir yanıt hazırlanırken alınan pasajların hangi kaynaktan geldiği denetlenebilir olmalıdır. Kaynak bulunmaması, kaynakların çelişmesi ve eski kaynak bulunması farklı durumlar olarak ele alınır. Pilot testte sistem yalnızca doğru cevap üretmekle değil, yanlış ekipmana ait belgeyi dışlayabilmekle de değerlendirilmelidir.

TEKNİK BÖLÜM / 03

Model öğeleri ve semantik arama

BIM nesneleri yalnızca geometriden ibaret değildir; sınıf, sistem, üretici, etiket ve mekânsal kapsama gibi bilgiler içerebilir. Bir kullanıcının 'ikinci kattaki klima santralleri' sorusu, dilsel eşlemenin yanı sıra kat hiyerarşisi ve ekipman sınıflandırması gerektirir. Sadece metin gömme vektörleri üzerinden benzer etiketleri aramak doğru sonuç için yeterli değildir. Mekânsal ve yapısal sorgular semantik aramayla birlikte çalışabilir.

Sorgu planı kullanıcının yetkisini, hedef tesis kimliğini ve soru türünü anlamalıdır. Gerektiğinde BIM/GIS varlık filtreleri deterministik olarak uygulanır; bulunan kaynaklar açıklama modeline aktarılır. Birden fazla aday eşleşmede kullanıcıdan veya uzman bağlamından ayrıştırıcı bilgi alınabilir. Sonuçlar kaynak modelin hangi revizyonuna ait olduğunu göstermelidir. Aynı model nesnesine birden fazla adla ulaşmak, bağımsız kopya sayfalar oluşturmayı gerektirmez.

TEKNİK BÖLÜM / 04

Mühendislik hesaplarının doğru sınırı

Yapay zekâ bir mühendislik problemi için yaklaşım önerebilir, hesap girdilerini sınıflandırabilir veya uygun çözücü türlerini açıklayabilir. Ancak resmi elektrik projesi, yapısal analiz, CFD ve yangın güvenliği hesabı yalnızca bir dil modelinin akıcı açıklamasıyla doğrulanmış olmaz. Fiziksel modelin sınır koşulları, birim sistemi ve teknik kabul kriterleri ayrı mühendislik incelemesi gerektirir. Yanlış sayısal sonuç güvenli görünen tasarım önerisine dönüşebilir.

Hesap adımı gerekiyorsa deterministik bir uzman araçla yapılmalı, girdileri ve araç sürümü kaydedilmelidir. Yapay zekâ hazırlık veya açıklama işinde görev alabilir; sonuç belirsizliği ve yetki sınırı korunur. Kullanıcı hesaplanan değer ile örnek açıklamayı açıkça ayırt etmelidir. Bir simülasyonun harici hesap motorundan geldiği doğrulanmadan sistem kendi üretimi gibi sunulmaz. Kritik kararların insan onayı atlanmamalıdır.

TEKNİK BÖLÜM / 05

Doküman hazırlama ve teknik rapor desteği

Mühendislik ekipleri revizyon notları, bakım raporları, toplantı kararları ve saha tutanakları hazırlamak için zaman harcar. Yapay zekâ bu içeriklerin taslağını kaynak veriden oluşturabilir ve eksik alanları işaretleyebilir. Ancak taslak rapora otomatik eklenen yorumun ölçülmüş sonuç, kullanıcı beyanı veya tahmin olduğu ayrılmalıdır. Aksi halde rapor görünüşte tamamlanmış fakat kaynağı bulunmayan iddialarla dolabilir.

Rapor şablonu zorunlu kaynak kimlikleri, tarih, sorumlu ve onay durumunu içermelidir. Otomatik özet değişiklikleri işaretlenerek kullanıcıya gösterilebilir. Bir operatörün girilmemiş alanını yapay zekânın tahminle doldurması yerine eksik bilgi olarak bırakması gerekir. Kabul edilen metnin hangi veri sürümü kullanılarak üretildiği saklanmalıdır. Böylece üretkenlik artışı kayıt doğruluğunu zayıflatmadan değerlendirilebilir.

TEKNİK BÖLÜM / 06

Tahmin ve anomali algılama

Enerji veya ekipman izleme senaryolarında istatistiksel modeller normal davranıştan sapmaları gösterebilir. Fakat normal davranış hava durumu, üretim takvimi, bakım durumu ve mevsimsel yüklerden etkilenebilir. Bir sıcaklık yükselişi gerçek arıza olabileceği gibi kullanım profilindeki değişimden de kaynaklanabilir. Anomali skoru tek başına güvenilir teşhis değildir. Özellikle etiketli olay verisi sınırlıysa modelin tahmin sınırları açıkça anlatılmalıdır.

Eğitim dönemi ve test dönemi ayrılmalı; aynı olayın verileri iki bölüme sızmamalıdır. Gerçek saha olaylarında yanlış pozitif ve kaçırılan olay oranları ölçülür. Veri dağılımı veya ekipman konfigürasyonu değiştiğinde model yeniden değerlendirilmelidir. Kullanıcının hangi göstergelerin uyarıya katkı verdiğini anlaması operasyonel kabul için önemlidir. Modelin eşik kararları insan müdahalesi olmadan güvenlik kritik kumanda üretmemelidir.

TEKNİK BÖLÜM / 07

Veri kalitesi, kayma ve yanlış güven

Bir yapay zekâ modelinin tutarlı metin üretmesi dayandığı verinin güncel veya doğru olduğunu kanıtlamaz. Sensör eksikliği, bozuk metin çıkarımı, yanlış model kimliği veya belgenin geçersiz sürümü hatalı bağlam oluşturabilir. RAG sisteminde teknik belge güncellense bile arama indeksinin ne zaman yenilendiği bilinmiyorsa eski cevap üretilebilir. Bu nedenle veri kalitesi kontrolleri model çıktısından bağımsız bir katman olmalıdır.

Kaynak indeksi ve model revizyonu sürümlenir, eksik veya çelişkili alanlar uyarıyla birlikte döndürülür. Belirli ekipman sınıfları için test soruları önceden tanımlanır. Yanlış kaynağa dayanan fakat dil açısından ikna edici yanıtlar özellikle değerlendirilmelidir. Kullanıcı düzeltmelerinin sonraki cevaplarda nasıl işlendiği ve kimin onay verdiği izlenebilir olmalıdır. Ölçüm verisindeki zaman gecikmesi ile doküman sürüm gecikmesi farklı risklerdir.

TEKNİK BÖLÜM / 08

Yetkilendirme ve hassas mühendislik bilgisi

BIM/GIS modeli güvenlik sistemlerinin konumunu, kritik ağ kablo güzergâhlarını ve tesis güç kapasitesini gösterebilir. Bu veriler her kullanıcıya açık olmayabilir. Yapay zekâ arama servisinde yetki filtresi uygulanmıyorsa kullanıcı normal arayüzde göremediği bilgiyi doğal dille sorarak elde edebilir. Çok kiracılı sistemlerde farklı müşteri belgelerinin aynı indekste karışması ayrıca veri sızıntısı riski oluşturur.

Erişim politikası yalnızca model cevabının sonunda metin temizleyerek değil, kaynak toplama ve retrieval aşamasında uygulanır. Kullanıcının hangi kaynakları sorguladığı ve hangi yanıtı aldığı denetim çerçevesinde kaydedilir. Hassas bilgi, model eğitimine veya üçüncü taraf servise gönderilmeden önce kurumsal gereksinimler doğrulanmalıdır. Yerel dağıtım ve ağ kısıtları gerekiyorsa ilgili modelin lisans ve çalıştırma altyapısı ayrıca test edilir.

TEKNİK BÖLÜM / 09

Prompt injection ve güvenilmeyen belgeler

Kurumsal dokümanlar ve saha açıklamaları her zaman güvenilir talimat kaynağı değildir. Bir raporun içine eklenmiş yönlendirici metin, yapay zekânın rolünü veya bilgi paylaşım sınırlarını değiştirmeye çalışabilir. Teknik veriyi okuyan model, bu metni çalışma talimatı gibi yorumlarsa beklenmeyen sonuçlar üretebilir. Harici kaynaktan gelen metin ile sistemin güvenlik politikası arasında açık güven sınırı gereklidir.

İçe alınan belgeler veri olarak ele alınmalı, modelin eylem yetkileri kesin olarak sınırlandırılmalıdır. Bağlantı veya komut çalıştırma yeteneği varsa kullanıcı onayı ve araç politikası ayrı uygulanır. Test setinde kasıtlı kötü içerikli dökümanlar, sahte sistem talimatları ve yetkisiz veri talepleri bulunmalıdır. Güvenlik kabulü yalnızca tipik doğru sorularda başarılı olma oranına dayanamaz.

TEKNİK BÖLÜM / 10

Mühendislik bilgi grafı ve ürün ailesi

Bir teknik soruya cevap verebilmek için belge metniyle birlikte fiziksel varlık grafına ihtiyaç duyulabilir. Octatus BIM/GIS ve fiziksel bağlama, Velocize mühendislik gereksinim ve doğrulama izine, Enlogy enerji ve operasyon verisine, Argamos BT servis ve envanter bilgisine odaklanan birlikte geliştirilmiş ürünlerdir. Bunlar tek bir uygulamanın alt menüleri değil, ayrı uzmanlık sınırları olan tamamlayıcı çözümlerdir.

Ortak senaryolarda yapay zekâ farklı alanların verisini ilişkilendirebilir; ancak kimlik, veri otoritesi ve erişim yetkileri korunmalıdır. Her ürünün fonksiyonları Octatus içinde otomatik olarak yerleşik kabul edilmez. Ürünler arası bağlantı kullanılıyorsa ilgili sürümde gerçekten çalışan arayüz ve hata durumları test edilmelidir. Teknik mimari yalnızca soruya cevap üretmekle değil, cevabın hangi kaynaklar arasında kurulan ilişkiye dayandığını açıklamakla değerlendirilir.

TEKNİK BÖLÜM / 11

Değerlendirme ve kabul ölçütleri

Bir yapay zekâ pilotunun başarısı birkaç etkileyici demo sorusuna doğru cevap vermek değildir. Sorular farklı bilgi türlerini temsil etmelidir: doğrudan doküman bulma, model öğesi keşfi, teknik karşılaştırma, eksik bilgi tespiti ve yetkisiz erişim denemesi gibi. Her soru için beklenen kaynak, doğru cevap kapsamı ve kabul edilebilir belirsizlik önceden tanımlanır. İnsan uzmanların anlaşamadığı sorularda referans cevap da ayrıca incelenmelidir.

Değerlendirmede kaynak doğruluğu, bilgi uydurma, reddedilmesi gereken sorular, yanıt süresi ve kullanıcı yararı ayrı ölçülür. Eğitim verisi ile değerlendirme sorularının aşırı örtüşmesi performansı olduğundan iyi gösterebilir. Kullanıcı geribildirimi değişiklik kaydıyla bağlanır. Kabul sonrasında veri ve model sürümleri değiştiğinde aynı testler tekrar çalıştırılır. Ürün için güvenilirlik tek seferlik doğruluk yüzdesi değil sürdürülebilir bir doğrulama sürecidir.

TEKNİK BÖLÜM / 12

Kullanıcı deneyimi ve açıklanabilirlik

Mühendis bir yapay zekâ cevabını okurken cevabın sonunda verilen genel bir kaynak listesi çoğu zaman yeterli değildir. Belirli teknik iddianın hangi belge satırından, varlık özelliğinden veya zaman aralığından geldiğini görebilmelidir. Bir sonuç tahminse açık etiketlenmeli, ölçülen veriyle aynı biçimde sunulmamalıdır. Gerektiğinde model öğesi, teknik çizim veya ilgili bakım kaydı aynı bağlamda açılabilmelidir.

Kullanıcı arayüzü yalnızca sohbet penceresinden oluşmak zorunda değildir; varlık seçimi, belge karşılaştırması ve doğrulama kontrol listesiyle bütünleşebilir. Fakat her etkileşimde hangi veri yetkisi kullanıldığı anlaşılır olmalıdır. Sorunun belirsiz olduğu durumlarda sistem varsayımını açıklamalı ve farklı cihazlar arasında otomatik karar vermemelidir. Erişilebilirlik, klavye kullanımı ve uzun raporların okunabilirliği teknik kabulün parçası olabilir.

TEKNİK BÖLÜM / 13

Maliyet, işletim ve model yönetişimi

Yapay zekâ projesinin maliyeti yalnızca model kullanım ücretinden oluşmaz. Kaynak veri hazırlama, arama indeksleri, vektör depolama, yetki entegrasyonu, değerlendirme testleri, gözlemlenebilirlik ve sürekli doküman güncellemesi büyük işletim kalemleridir. Yerel model dağıtımı seçilirse donanım, enerji ve bakım ihtiyaçları değişebilir. Gizli maliyetlerden biri, doğrulanmamış cevapların uzman ekip tarafından tekrar incelenmesidir.

Pilot iş hedefini ölçmeli; hangi işin hızlandığı ve hangi yeni doğrulama yükünün oluştuğu anlaşılmalıdır. Model ve indeks sürümleri, geri dönüş imkânı ve veri saklama politikası işletim planına dahil edilir. Üretken yapay zekânın bütün mühendislik kararlarına uygulanması gerekmeyebilir; deterministik kural ve aramanın yeterli olduğu alanlar ayrı değerlendirilir. Bu yaklaşım daha düşük riskli ve maliyeti öngörülebilir bir uygulama programı oluşturur.

TEKNİK BÖLÜM / 14

Örnek vaka: klima santrali için teknik soru cevaplama

Bir işletme mühendisi belirli bir klima santralinin filtre bakım periyodunu sorabilir. Aynı marka ve modele ait birden fazla cihaz farklı ortamda çalışıyor olabilir; üretici önerisi ve kurum bakım planı farklı süreler tanımlayabilir. Yapay zekânın doğru cevabı, rastgele bulunan bir katalog sayfasını özetlemek değil, ilgili fiziksel varlığı ve yetkili bakım dokümanını eşleştirmektir. Sorguda tesis, kat, cihaz etiketi ve belge revizyonu gerektiğinde bir araya getirilmelidir.

Kabul testinde aynı isimli iki cihaz seçilerek sistemin doğru belgeyi getirip getirmediği incelenir. Kaynak doküman yoksa model bir bakım süresi uydurmamalıdır. Yanıtın kaynak ve revizyon bilgisi kullanıcıya görünür olmalıdır. Teknik hesap, resmî onay ve iş emri yaratma yetkileri sohbet yanıtından ayrı tasarlanır. Bu senaryo yapay zekânın bağlama dayalı desteğini açıklar, ürünün tüm uygulama aşamalarını hazır sunduğu anlamına gelmez.

TEKNİK BÖLÜM / 15

Örnek vaka: şartnameden varlık bilgi gereksinimi çıkarma

Büyük projelerde teknik şartnameler yüzlerce sayfa olabilir. Bir ekip IFC tesliminde hangi ekipman alanlarının zorunlu olduğunu belirlemek için bu belgeleri inceler. Yapay zekâ aday gereksinim maddelerini bulabilir, varlık sınıflarına göre gruplayabilir ve eksik başlıkları önerebilir. Ancak sözleşmedeki yükümlülük ve proje aşaması yanlış yorumlanırsa otomatik oluşturulan kontrol listesi eksik veya aşırı kapsamlı olabilir. Bu nedenle gereksinim çıkarımı uzman doğrulamasına tabi tutulmalıdır.

Doğrulanmış gereksinimler IDS veya başka uygun kontrol araçlarına aktarılabilir. Her koşul kaynak belge, sayfa, yürürlük durumu ve sorumlu kişiyle ilişkilendirilir. Yapay zekânın bulamadığı şartların yok olduğu varsayılmaz; uzman örneklemiyle kapsam kontrolü yapılır. Sonraki şartname revizyonunda hangi gereksinimlerin değiştiği sürümlü biçimde izlenmelidir. Bu yaklaşım yalnızca kelime eşleştirmekten daha güçlü bir mühendislik bilgi yönetimi sağlar.

TEKNİK BÖLÜM / 16

Performans, maliyet ve işlem izlenebilirliği

Bir kurumsal yapay zekâ sisteminde kullanıcıların farklı soru uzunlukları ve doküman hacimleri vardır. Yanıt gecikmesi, model kullanım maliyeti ve arama altyapısının sorgu yükü birlikte değerlendirilmelidir. Tüm belgeleri her soruda işlemek hem pahalı hem de bilgi kaybına açık olabilir. Uygun indeksleme, sorgu yönlendirme ve önbellek kullanımında ise güvenlik ve veri güncelliği sınırları korunmalıdır.

Pilot ölçümlerinde yanıt süresiyle birlikte doğru kaynağa erişim, uydurma bilgi oranı ve insan düzeltme gereksinimi raporlanır. Maliyeti düşürmek için yanıt kalitesini veya yetkilendirme testlerini atlamak kabul edilebilir değildir. Model yükseltildiğinde eski test senaryolarıyla tekrar değerlendirme yapılır. Veri saklama ve günlükleme politikaları hassas mühendislik içeriğinin gereksiz yere çoğaltılmasını önlemelidir.

TEKNİK BÖLÜM / 17

İnsan geri bildirimi ve sürekli doğrulama

Saha mühendisi bir yapay zekâ yanıtını yanlış bulduğunda bunun nedeni belge güncelliği, varlık eşlemesi veya model yorumlaması olabilir. Bu üç hata türünü aynı geri bildirim kategorisinde toplamak kalıcı iyileştirmeyi zorlaştırır. Geri bildirimlerin insan onayından sonra ilgili kaynağa veya test kuralına aktarılması gerekir. Her kullanıcı düzeltmesi otomatik olarak kurumsal gerçeklik ilan edilmemelidir.

Hata sınıfları, ilgili varlık, model sürümü ve kaynak belge kimliğiyle ilişkilendirilir. Düzeltme yayınlandığında daha önce başarısız olan senaryo yeniden test edilir. Zaman içinde yeni soru türleri ortaya çıktığı için değerlendirme kümesi genişletilir. Kullanıcının yalnızca beğeni oyu vermesi teknik doğruluğu ölçmek için yeterli değildir; uzman değerlendirmesi ve kanıt düzeyi korunmalıdır.

Sık sorulan sorular

Yapay zekâ mühendislik onayı yerine geçer mi?

Hayır. Teknik hesaplar ve kritik kararlar ilgili uzman ve disiplinlerce ayrıca doğrulanmalıdır.

RAG kullanmak yanlış cevabı tamamen önler mi?

Hayır. Yanlış kaynak seçimi, eski belge ve eşleme hataları devam edebilir. Kaynak gösterme ve test gerekir.

Yerel model her zaman zorunlu mu?

Hayır. Dağıtım modeli müşterinin veri politikası, maliyet ve güvenlik gereksinimlerine göre değerlendirilir.

AI ile modeldeki cihazlar doğal dille sorgulanabilir mi?

Uygun varlık indeksi, yetki ve semantik eşleme tasarlanırsa mümkün olabilir; her entegrasyonun hazır olduğu varsayılmamalıdır.

Standartlar ve teknik referanslar

Bu kaynaklar alandaki genel teknik çerçeveyi destekler. Proje özelindeki uygunluk, ürün sürümü ve hazır arayüz kapsamı ayrıca doğrulanmalıdır.

BİRLİKTE ÇALIŞIR