Metlivi Blog

Bir Yapay Zekâ Sohbet Dışa Aktarımı Önemli Bağlamı Koruyabilir mi? Kurgusal Sahneler ve Proje Tercihleri İçin Pratik Bir Devir Teslim

Evet, bir yapay zekâ sohbet dışa aktarımı, konuşmayı ve önemli ayrıntıların nereden geldiğini açıklayan okunabilir bir devir teslim belgesini içerdiğinde önemli bağlamı koruyabilir. Kullanışlı bir aktarım için kurgusal sahne bilgilerini kaynak mesajlarıyla ilişkilendirin, proje tercihlerini onaylanıp onaylanmadıklarına ya da yalnızca önerilip önerilmediklerine göre etiketleyin ve olayları kronolojik sırada tutun. İndirilen bir arşiv yalnızca bir veri kaydıdır; başka bir aracın her ayrıntıyı hedeflendiği gibi içe aktaracağını veya yorumlayacağını tek başına garanti etmez.

30 Eylül 20266 min readOkuma, sanat ve kültürYazan: Metlivi Editorial Team
Bölüm 1

Dışa aktarım neleri korur ve bir devir teslim belgesi nelere yer vermelidir

Dışa aktarım, sohbet geçmişinin bir kopyasını saklamak için kullanışlıdır. Örneğin, OpenAI'ın mevcut yardım sayfası, ChatGPT ayarları veya Gizlilik Portalı üzerinden dışa aktarma talebinde bulunulmasını açıklamaktadır; indirilebilir ZIP dosyası sohbet geçmişini ve diğer hesap verilerini içerir. Bu sayfa verilerin bir kopyasını tarif eder; her ayrıntının başka bir asistana aynı anlam veya yapıyla aktarılacağına dair bir taahhüt vermez. OpenAI: Exporting your ChatGPT history and data

Devir teslim belgesinin ise farklı bir görevi vardır: Yeni bir okuyucunun önemli ayrıntıları bulmasına ve yorumlamasına yardımcı olur. Uzun bir döküm ilgili diyaloğu içeriyor olabilir, ancak okuyucunun yine de onu bulması ve kesinleşmiş bir tercihi beyin fırtınası sırasındaki bir öneriden ayırt etmesi gerekir. Kısa ve öz bir özet, kaynağa işaret ettiği ve belirsizlikleri görünür kıldığı sürece bu gezinme sorununu çözebilir.

Bu ayrım, bir veri kopyası ile kaynak bağlantılı, özenle derlenmiş bir özet arasındaki farka dayanan editoryal bir öneridir. Herhangi bir dışa aktarımın bir devir teslim özelliği içerdiği veya bir dosyayı içe aktarmanın orijinal konuşmayı yeniden oluşturacağı anlamına gelmez.

Bölüm 2

Kurgusal sahne ayrıntılarını kaynaklarıyla ilişkilendirin

Kurgu için, kökeni belirsiz bir bilgiye güvenmek zor olabilir. Bir özet, “Mara pirinç anahtarı mavi çalışma masasının çekmecesine koyar,” diyebilir; ancak yeni bir iş ortağı bunun hikâyede mi kesinleştiğini, asistan tarafından mı önerildiğini yoksa daha önceki bir bölümden mi çıkarıldığını anlayamaz. Konuşma başlığını veya kimliğini, mesaj tarihini veya sırasını ve ilgili konuşmanın kısa bir alıntısını ya da aslına sadık bir özetini kaydederek kaynağı muhafaza edin.

Kullanışlı bir sahne bilgisi girdisi şu şekilde görünebilir:

Bilgi: Mara, tren geldikten sonra pirinç anahtarı mavi çalışma masasının çekmecesine koyar.

Kaynak: “İstasyon sahnesi”, kullanıcı mesajı 18; asistanın 19 numaralı yanıtında onaylandı.

Durum: Taslakta kesinleşti; tekrar kullanmadan önce en son elyazmasıyla karşılaştırın.

Kapsam: İstasyon sahnesi için geçerlidir, sonraki bölümler için geçerli olmayabilir.

Bu son niteleme önemlidir. Bir sahne ayrıntısı belirli bir taslak sürümünde doğru olabilir ancak daha sonra geçerliliğini yitirebilir. W3C’nin PROV modeli, materyalin nasıl kullanıldığını veya üretildiğini ve kiminle ilişkili olduğunu gösterebilen ilişkilerle birlikte varlıklar, etkinlikler ve aracılar üzerinden kaynak geçmişini tanımlar. Pratik bir sohbet devir tesliminin W3C standardını uygulaması gerekmez, ancak aynı temel mantık faydalıdır: Bilgiyi, kaynağını ve devir teslim belgesinin bir parçası hâline nasıl geldiğini tanımlayın. W3C: PROV-O: The PROV Ontology

Bölüm 3

Onaylanmış tercihleri önerilerden ayırın

Bir konuşma fikir arayışları içerdiğinde, proje tercihlerini abartmak veya yanlış yorumlamak kolaydır. “Kısa bölümler kullanın” açık bir talimat olabilir; “belki daha kısa bölümler denenebilir” ise değerlendirme aşamasındaki bir seçenektir. Her ikisini de kesin kurallar olarak ele almak gelecekteki çalışmaları yanlış yöne sevk edebilir.

Her tercihe onaylandı, geçici, reddedildi veya belirsiz gibi net bir durum atayın. Bu durumu destekleyen ifadeyi veya kaynak mesajı kaydedin ve varsa sınırlamaları not edin. Örneğin:

Onaylandı: Mevcut taslak için sınırlı üçüncü şahıs bakış açısını kullanın. Kaynak: proje sohbeti, mesaj 42. Kapsam: yalnızca mevcut taslak.

Geçici: Daha sakin bir açılış düşünün. Kaynak: taslak tartışması, mesaj 57. Karar verilmesi gerekiyor.

Reddedildi: Beyin fırtınası konuşmasında önerilen alternatif sonu kullanmayın. Kaynak: revizyon tartışması, mesaj 11.

Bu bir karar destek yöntemidir; durum etiketlerinin bir dışa aktarma formatından geldiği iddiası değildir. Açık karar kaydı kılavuzu, önemli bir seçimin bağlamı ve sonuçlarıyla birlikte kaydedilmesini anlatır; bu ilkeyi bir yapay zekâ sohbet devir teslimine uygulamak, bir tercihin neden var olduğunu ve kesin olup olmadığını korumaya yardımcı olur. Decision Records: Decision record

Bölüm 4

Sohbet kronolojisini incelenebilir tutun

Kronoloji, değişiklikleri anlamlandırmaya yardımcı olur. Bir karakterin adı, sahne konumu veya projenin yönü revizyon sırasında değişirse, bir okuyucunun hangi ifadenin önce geldiğini ve daha sonraki bir mesajın açıkça onun yerini alıp almadığını bilmesi gerekir. Mümkün olan her yerde orijinal sırayı koruyun ve özetlenen kararların yanına zaman damgalarını veya mesaj numaralarını ekleyin. Bir mesajın güvenilir bir zaman damgası yoksa, uydurmak yerine bunu açıkça belirtin.

Makineler tarafından okunabilir zaman damgaları için RFC 3339, yaygın olarak kullanılan bir İnternet tarih ve saat formatını tanımlar ve tutarlı saat dilimi gösteriminin sıralamayı nasıl desteklediğini tartışır. Bir devir teslim belgesi, tam zaman bilindiğinde 2026-09-30T14:20:00Z gibi bir zaman damgası veya bilinmediğinde bir mesaj numarası kullanabilir. Yalnızca tarih içeren bir referansı kesin bir saate dönüştürmeyin. IETF: RFC 3339—Date and Time on the Internet: Timestamps

Kısa bir değişiklik günlüğü revizyonları son derece anlaşılır kılabilir: “Mesaj 12: karakterin adı Nia; mesaj 31: kullanıcı adın artık Leena olduğunu onaylıyor; bu noktadan itibaren Leena adını kullanın.” Bu, kaynak konuşmayı incelemeye hazır hâlde tutarken sırayı ve açık durum değişikliğini kaydeder.

Bölüm 5

Kontrol edilebilir bir devir teslim belgesi oluşturun

Pratik bir devir teslim belgesi, orijinal dışa aktarımın yanında saklanan küçük bir belge olabilir. Yalnızca çalışmayı devam ettirmeye yardımcı olan ayrıntıları dahil edin, ardından her birini doğrulamak için yeterli kaynak bilgisini sağlayın. Aşağıdaki yapı önerilen bir iş akışıdır, zorunlu bir dışa aktarım şeması değildir:

Projeyi ve kaynak kümesini tanımlayın. Devir teslim belgesinin hangi konuşma dosyalarını veya taslakları kapsadığını belirtin. Dışa aktarımın kısmi olup olmadığını veya bazı ilgili konuşmaların dahil edilip edilmediğini not edin.

Sahne ayrıntılarını çıkarın. Her girdi için bir bilgi yazın ve bunu bir mesaja, pasaj veya kararlı bir dosya konumuna bağlayın. Bir karakterin söylediği, anlatımın kesinleştirdiği ve bir iş ortağının çıkardığı anlamlar arasındaki ayrımları koruyun.

Tercihleri durum ve kapsamla kaydedin. Her bir tercihi kimin onayladığını, nerede yer aldığını, güncel olup olmadığını ve hangi projeye ya da taslağa uygulandığını belirtin.

Değişiklikler için kronoloji ekleyin. Tarihleri, mesaj sırasını veya her ikisini birden koruyun. Sonraki hangi ifadelerin önceki ifadelerin açıkça yerini aldığını işaretleyin; önceki bağlamı sessizce silmeyin.

Çözümlenmemiş noktaları işaretleyin. Kaynağın kesinleştirmediği ayrıntılar için “belirsiz” veya “onay gerekiyor” gibi görünür bir etiket kullanın.

Bağlantıları arşive karşı kontrol edin. Alıntılanan mesajlardan örnekler açın ve devir teslim belgesindeki ifadelerin ve durumun konuşmada gerçekte söylenenlerle eşleştiğinden emin olun.

GitHub’ın dokümantasyonu, yapılandırılmış sorun formlarının (issue forms) katkıda bulunanlardan belirli bağlamları talep edebileceğini açıklamaktadır. Bu, bir devir teslim belgesi için kullanışlı ve genel bir şablon sunar: Tutarlı bir alan kümesi, eksiklikleri fark etmeyi kolaylaştırır. Sohbet dışa aktarımlarının GitHub formlarını kullandığını veya bunların davranışlarını paylaştığını göstermez. GitHub Docs: About issue and pull request templates

Bölüm 6

Eksik kapsamı ve içe aktarma sınırlılıklarını açıkça belirtin

Doğrulanmadığı sürece hiçbir özet, projenin tüm geçmişini içerdiğini ima etmemelidir. Bir konuşma dışa aktarımı, kaynak materyalin yalnızca bir parçası olabilir: taslaklar, ekler, ayrı sohbetler, sonraki düzenlemeler veya sohbet dışında alınan kararlar da önem taşıyabilir. Nelerin incelendiğini ve nelerin incelenmediğini belirtin ve kontrol edilemeyen her şey için “doğrulanmadı” notunu kullanın.

İçe aktarma doğruluğu ayrı bir konudur. Alıcı bir araç metni görüntüleyebilir ancak mesaj rollerini, zaman damgalarını, ekleri, dallanmaları veya diğer yapıları koruyamayabilir; bu davranış ilgili araca ve desteklediği formata bağlıdır. İçe aktarma işlemi test edilip kontrol edilmedikçe, devir teslim belgesini orijinal sohbetin veya proje durumunun eksiksiz bir şekilde geri yüklenmesi olarak değil, seçilen bağlama dair okunabilir bir rehber olarak tanımlayın.

Kullanışlı test somuttur: Başka bir okuyucu bir sahne bilgisini veya tercihi kaynağına kadar takip edebilir, kesinleşip kesinleşmediğini anlayabilir ve kronolojide nereye oturduğunu görebilir mi? Yanıt evet ise, dışa aktarım ve devir teslim belgesi birlikte çalışmanın devamı için önemli bağlamı koruyabilir ve aynı zamanda boşlukları ve aktarım sınırlarını görünür kılabilir.

İlgili okumalar

Bu konuyu keşfetmeye devam et