Ucuz LLM'leri DynamoDB'de nasıl güvenilir kıldık: tool doğrulayıcıları + eval'ler

DynoTable'ın AI asistanı, kendi kimlik bilgilerinizle çalışır, yani modeli siz seçersiniz — ve çoğu insan ucuz olanı seçer. Bu yüzden asistanı bir sınır (frontier) modele göre ayarlamıyoruz. Tabanımız, sorgu başına yuvarlama hatası kadar maliyeti olan ve sınır modellerin başarısız olmadığı biçimlerde başarısız olan bir model olan Amazon Nova Lite.

İşte tüm bu yazının can alıcı noktası: bir senaryosunda — bileşik anahtarlı tabloyu temel olarak gerektiren bir birleştirme — Nova Lite %0 aldı. Model değiştirmedik, few-shot örnekler eklemedik, ince ayar yapmadık. Bunun yerine bir doğrulayıcı hata mesajını, tam olarak ne yapılması gerektiğini söyleyecek şekilde yeniden yazdık. %100'e çıktı ve birleştirmeyi bir sonraki adımda çevirdi.

Model asla darboğaz değildi. Mesaj darboğazdı.

Bu, o dersin arkasındaki mühendislik hikayesi: her tool çağrısının etrafında oturan doğrulayıcılar, kasıtlı olarak doğrulamadığımız şeyler ve her değişikliğe hakemlik eden eval koşum takımı. Bir bütçe modeli üzerinde bir kuruyorsanız — DynamoDB üzerinde ya da başka herhangi bir şey üzerinde — çoğu aktarılabilir.

Ucuz modeller neden özellikle DynamoDB'de başarısız olur

DynamoDB, küçük bir model için düşman bir hedeftir çünkü sorgu yüzeyi SQL gibi görünür ama değildir. PartiQL, SELECT söz dizimini kabul eder ama JOIN, GROUP BY, DISTINCT, LIKE desteklemez — ve SQL'i internetten öğrenmiş bir model bunların hepsini kendinden emin bir şekilde üretir.

Gerçekten gözlemlediğimiz başarısızlıklar, her biri gerçek bir günlüklenmiş koşumdan:

Düşürülen limit argümanları. , bir Query tool'undaki isteğe bağlı satır limitini rutin olarak atlar. Arka uç mutlulukla her şeyi döndürür, 200 KB'lık bir tool sonucu konuşmaya iner ve bir sonraki model turu bağlam tavanında ölür — döngü ortasında bir ValidationException, yanlış bileşene fatura edilir.
Desteklenmeyen yapılar. PartiQL'de JOIN, GROUP BY, toplamalar — DynamoDB'nin asla çalıştırmayacağı ifadeler, Postgres'te doğru olacakları için üretilmiş.
Tanımlayıcı takasları. Nova Lite, SELECT * FROM customers verildiğinde ve "Almanya için bir WHERE ekle" talimatıyla, bazen SELECT * FROM orders WHERE … döndürürdü — kullanıcının hiç bahsetmediği bir tablo. İfade kusursuz ayrıştırılır. Hiçbir söz dizimsel şey bunu yakalamaz.
Tool yanlış yönlendirmesi. Ekli bir dosya hakkında sorulduğunda, Nova Lite, sekmelerde dosya arayarak açık sekmeleri listeleme tool'unu çağırdı — tool arama mekanizmasını neredeyse hiç kullanmadı, bu yüzden doğrudan görünür olmayan hiçbir şey var olmuyordu.

Bunların hiçbiri varsayımsal değil. Her biri aşağıdaki belirli bir koruyucu bariyeri yönlendirdi.

Tool sınırında doğrula ve hatayı bir derse dönüştür

En önemli tekil mimari karar: doğrulama, girdi şemasında değil, tool'un execute adımının içinde yaşar. Bir şema reddi çıkmaz bir sokaktır — döngü bir tür hatası görür ve hiçbir şey öğrenmez. Çalışan, kontrol eden ve yapılandırılmış bir hata döndüren bir tool, modele bir sonraki adımda tepki verebileceği normal bir tool sonucu verir.

Ve o hata bir insan günlüğü için değil, model için yazılır. Dışa aktarım tool'umuzun hataları tam olarak şöyle okunur:

startExport requires exactly one of {tabId} or {sql}.
FIX: call listOpenTabs and pass {tabId}, or pass {sql} with a single SELECT.

startExport {sql} must be a read-only single SELECT.
FIX: remove any INSERT/UPDATE/DELETE/DDL and pass one SELECT statement.

Query doğrulama başarısızlıkları bir validation: öneki taşır — validation: parse-error: …, validation: partiql-unsupported: JOIN is not supported by DynamoDB PartiQL. — sistem istemi bunu, aynı girdiyi yeniden denemek yerine ifadeyi düzeltme sinyali olarak belirler. Bir reddetme mesajı öğretici bir sinyaldir. FIX: kuralını benimsemeden önce, aynı başarısızlıklar modelin özür dileyip kullanıcıya dışa aktarım düğmesine kendisinin tıklamasını söylemesiyle bitiyordu. Sonrasında kendini düzeltiyor ve görevi tamamlıyor.

Sonuç ilkesini öğrenmek daha uzun sürdü: somut örneğin nerede yaşadığı bir tasarım eksenidir. Bir hata çalışma zamanında bir doğrulayıcı tarafından yakalanıyorsa, sistem istemini genel tutun ve dinamik hata mesajının belirli tabloları ve düzeltmeyi taşımasına izin verin — istem küçük kalır ve ders tam ihtiyaç duyulduğunda gelir. Yalnızca hiçbir doğrulayıcının yakalayamayacağı hatalar (bir toplama sorusunu ilk etapta doğru tool'a yönlendirmek gibi) istemin kendisinde somut bir örnek hak eder.

Reddedeceğin şeyleri ayrıştır

JOIN'i genel bir syntax error at offset 27 ile reddetmek hiçbir şey öğretmez. Bu yüzden elle yazılmış PartiQL ayrıştırıcımız biraz sapkın bir şey yapar: DynamoDB'nin desteklemediği yapıları kasıtlı olarak geçerli bir söz dizimi ağacına ayrıştırır — sadece bir gezici (walker) belirli, öğretilebilir bir tanı yayabilsin diye. Hepsi kelimesi kelimesine, hepsi modele yönelik:

JOIN is not supported by DynamoDB PartiQL.
GROUP BY is not supported by DynamoDB PartiQL.
TOP N is not supported. Use the API limit parameter.
IN list has 120 items. DynamoDB PartiQL caps IN at 50 values (PK column) or 100 values (non-key column).
IS NOT NULL is not supported in DynamoDB PartiQL. Use attribute_exists.
lower(path) is not a DynamoDB PartiQL function. Use … instead. — değiştirme, işlev başına çözümlenmiş olarak.

Her mesaj hem yapıyı hem de kaçış kapısını adlandırır. "PartiQL desteklenmeyen bir yapıyı reddederse, hemen SQL workbench'e geç" istem kuralıyla eşleştirildiğinde, ucuz bir model Postgres içgüdülerinden çırpınmak yerine tek bir adımda kurtulur.

NE'yi doğrulamayacağını bil

SQL doğrulayıcımızın şema-farkında katmanı, tablo ve sütun referanslarını uygulamanın zaten elinde tuttuğu gerçek tablo açıklamalarına karşı çözer. Erken dönemde DynamoDB'nin bildirmediği özniteliklere yapılan referansları da işaretliyordu — ki bu doğru gibi görünür ve tam olarak yanlıştır. DynamoDB'nin attributeDefinitions'ı yalnızca anahtar özniteliklerini listeler, bu yüzden kontrol WHERE <non-key> = …'i reddetti — var olan en yaygın meşru sorgu şeklini. O kontrol artık asla engellemeyen bir uyarıdır.

Her doğrulayıcı, reddedilen şeklin doğru olmaktan çok yanlış olma olasılığının daha yüksek olduğuna dair bir bahistir. Veri modeli kontrolü destekleyemediğinde, bahsi oynamayın.

Sonuç üst sınırları yalnızca güvenlik değil, davranış olarak

Düşürülen limit patlamasının çözümü "limiti isteme ekle" değildi (ucuz modeller yine de düşürür). Query tool sonuçları sert şekilde üst sınıra alınır — 10 satır veya 5 KB, hangisi önce gelirse — her zaman en azından ilk satırı koruyarak — ve kesme bildirimi de kendisi yönlendiricidir:

Showing 10 of 4,200. To filter: re-run with WHERE.
To view in UI: emit proposeOpenTable.
To aggregate: use runWorkbenchSql GROUP BY.

Üst sınırlar, bağlamın tutabileceğinin kasıtlı olarak çok altındadır. Amaç davranışsaldır: modeli, satırları sohbete sıralamak yerine kullanıcıya gerçek bir tablo görünümü veya kesin bir toplama vermeye zorlamak. Kurtarma ipucu tam tool'ları adlandırır, böylece üst sınır, modelin ihtiyaç duyduğu anda yönlendirmeyi öğretir. Aynı zarf, eval koşum takımında baytı baytına yansıtılır ve bir regresyon senaryosu, 10.000 öğelik bir tabloya karşı truncated: true'yu sabitler, böylece üst sınır asla sessizce kaybolamaz.

Satırları sohbete sıralamak yerine asistan, sonucu gerçek bir DynoTable sekmesi olarak açmak için tıkladığınız bir çip yayar.

Eval'ler hakemdir

Yukarıdakilerin hiçbiri sezgiye göre tasarlanmadı ve inançla korunmadı. Her istem maddesi, doğrulayıcı mesajı ve üst sınır, tohumlanmış bir DynamoDB Local'a karşı gerçek ajan döngüleri çalıştıran bir eval takımı tarafından denetlenir — gerçek tool'lar, gerçek sorgu yürütme, yeniden uygulanmak yerine doğrudan içe aktarılan üretim istem oluşturucuları ve doğrulayıcıları — tool izindeki, veritabanının son durumundaki ve metindeki ikili kontrollerle puanlanır.

Eval'lerin sezginin kaçırdığı şekilde yakaladıkları:

Bir "daha temiz" istem genelleştirmesi, bir senaryoyu %100'den %0'a geriletti. Bize daha iyi okundu. Taban model katılmadı. Yalnızca eval fark etti.
Sınır model istem tavsiyesi, ucuz modeller için etkin biçimde yanlıştır. Yayınlanmış kılavuz, CRITICAL/MUST dilini yumuşatmayı söyler çünkü büyük modeller buna aşırı tepki verir. Ucuz modeller ise yetersiz uyum sağlar ve sağlam sürüme ihtiyaç duyar. Artık ödünç alınan herhangi bir tavsiyeyi inançla uygulamak yerine eval ile denetliyoruz.
Katı tool iddiaları doğru davranışı cezalandırdı. Modelin açıklama için ask tool'unu çağırmasını gerektiren bir puanlayıcı, model merdiveni boyunca %19 geçti — neredeyse her "başarısızlık", açıklamayı metinde doğru şekilde istemiş bir modeldi. Puanlayıcı artık her ikisini de kabul ediyor. Mekanizmayı değil, kullanıcıya yönelik niyeti puanlayın.
Model merdiveni daralmasını hak etti. Geniş başladık — Mistral, AI21, GLM, Qwen, Nova Pro, daha fazlası — ve yalnızca gerçek koşumların ortaya çıkardığı nedenlerle iki basamağa (Nova Lite, Claude Haiku) indirdik: bir aile çağrı başına ~10× maliyetliydi çünkü Bedrock ona istem önbelleklemesi sunmadı; Nova Pro, açık uçlu birleştirmelerde customers.customerName gibi birleştirilmiş öznitelik adlarını halüsine etti. Ve bir aile tamamen kara listeye alınmak zorunda kaldı — Bedrock'un birleşik API'si, adaptörü ardından işlev çağrılarını düz metin olarak yayan modeller için tool tanımlarını mutlulukla kabul ediyor, ki bunu API meta verisi size söylemez. Bunu bir spec ile değil, ücretli bir smoke probu ile bulduk.

İki disiplin takımı dürüst tutuyor. Örnek tablolar asla test tablolarına eşit değildir: istem örnekleri, tohum verisinde var olmayan tarafsız adlar kullanır ve eval'ler farklı tablolarda çalışır — böylece bir geçiş, modelin örneğimizi ezberlediğini değil, deseni genelleştirdiğini kanıtlar. Ve $0 izleme modu kayıtlı fikstürleri reddeder: yeniden oynatılan model çıktıları, gerçek tool etkinliğine bağlı iddiaları yeşil-geçirir, bu yüzden ücretsiz katman yalnızca bağlantıyı doğrular ve bir puan iddia eden herhangi bir şey, gerçek bir modelde gerçek token'lar harcamak zorundaydı.

Kontrol listesi, eğer bunlardan birini kuruyorsanız

Önce taban modelinizi seçin ve her zaman ona karşı eval yapın; sınır modeller hatalarınızı gizler.
Doğrulamayı tool'un execute adımına koyun; döngünün üzerinde eylemde bulunabileceği hatalar döndürün, asla şema çıkmaz sokakları değil.
Her reddi neyin yanlış olduğu + FIX: tam olarak bir sonraki eylem olarak yazın ve kullanıcının gerçek tablolarını içine yerleştirin.
Reddetmeyi niyet ettiğiniz şeyi ayrıştırın, böylece tanı belirli olabilir.
Her doğrulayıcıyı veri modelinize karşı denetleyin — meşru şekilleri reddedenleri silin.
Tool sonuçlarını sığandan aşağı üst sınıra alın ve kesme bildiriminin modeli doğru bir sonraki tool'a yönlendirmesini sağlayın.
Eval'leri, üretim kod yollarını yeniden kullanarak gerçek bir (yerel) arka uca karşı gerçek döngüler olarak çalıştırın; örnek veriyi test verisinden ayrık tutun; her istem ve mesaj değişikliğinin hakemi olarak zevki değil, eval'i yapın.

Bir sınır model kullanıyorsanız bunların herhangi biri önemli mi?

Daha az sıklıkla, ama evet. Doğrulayıcılar her katmanda yük taşıyıcıdır — bir sınır model hâlâ DynamoDB'de JOIN çalıştıramaz ve yönlendirici hatalar yalnızca daha hızlı tüketilir. Kendi koşumlarımızda, bir sınır sınıfı modelin çip yayma davranışı, daha küçük modellerin başa çıktığı bir istem ifadesi altında bir kez %0'a düştü — eval koşum takımı bunu da yakaladı. Güvenilirlik mühendisliği küçük bir model vergisi değildir; küçük modeller yalnızca faturanın daha erken gelmesini sağlar.

Bu nerede çalışır

Bütün bunlar, DynoTable'ın asistanının ve kısıtlı tool kataloğunun içinde yayınlanır: kendi Bedrock kimlik bilgilerinizde şema-farkında doğal dil sorgulaması, kesin tüm tablo toplamaları ve yalnızca incelenebilir bir hazırlama alanına inen yazmalar. Harici ajanlar, aynı doğrulanmış araç takımını MCP sunucusu aracılığıyla alır — onu nasıl güvenli kurduğumuz ise OAuth'tan kimlik bilgisi yalıtımına kadar kendi başına bir hikaye.

Ve üretim yerine belirlilik istediğinizde — koda işleyeceğiniz sorgu — modeli tamamen atlayın: Expression Builder, tam isteği elle oluşturur.