Kecerdasan Data Generatif

Bangun solusi IDP yang dirancang dengan baik dengan sudut pandang khusus – Bagian 3: Keandalan | Layanan Web Amazon

Tanggal:

Grafik Lensa Kustom IDP yang Dirancang dengan Baik ditujukan untuk semua pelanggan AWS yang menggunakan AWS untuk menjalankan solusi pemrosesan dokumen cerdas (IDP) dan mencari panduan tentang cara membangun solusi IDP yang aman, efisien, dan andal di AWS.

Membangun solusi siap produksi di cloud melibatkan serangkaian trade-off antara sumber daya, waktu, ekspektasi pelanggan, dan hasil bisnis. Itu Kerangka Kerja AWS Well-Architected membantu Anda memahami manfaat dan risiko keputusan yang Anda buat saat membangun beban kerja di AWS. Dengan menggunakan Framework ini, Anda akan mempelajari praktik terbaik operasional dan arsitektur untuk merancang dan mengoperasikan beban kerja yang andal, aman, efisien, hemat biaya, dan berkelanjutan di cloud.

Proyek IDP biasanya menggabungkan pengenalan karakter optik (OCR) dan pemrosesan bahasa alami (NLP) untuk membaca dan memahami dokumen serta mengekstrak istilah atau kata tertentu. Lensa Kustom IDP Well-Architected menguraikan langkah-langkah untuk melakukan tinjauan AWS Well-Architected yang memungkinkan Anda menilai dan mengidentifikasi risiko teknis beban kerja IDP Anda. Panduan ini memberikan panduan untuk mengatasi tantangan umum yang kita lihat di lapangan, mendukung Anda untuk merancang beban kerja IDP Anda sesuai dengan praktik terbaik.

Postingan ini berfokus pada pilar Keandalan solusi IDP. Dimulai dari pengenalan pilar Keandalan dan prinsip desain, kami kemudian mendalami desain dan implementasi solusi dengan tiga area fokus: fondasi, manajemen perubahan, dan manajemen kegagalan. Dengan membaca postingan ini, Anda akan mempelajari pilar Reliability dalam Well-Architected Framework dengan studi kasus IDP.

Prinsip desain

Pilar keandalan mencakup kemampuan solusi IDP untuk melakukan pemrosesan dokumen dengan benar dan konsisten ketika diharapkan dan sesuai dengan aturan bisnis yang ditentukan. Hal ini mencakup kemampuan untuk mengoperasikan dan menguji alur kerja IDP secara penuh dan total siklus hidupnya.

Ada sejumlah prinsip yang dapat membantu Anda meningkatkan keandalan. Ingatlah hal ini saat kita membahas praktik terbaik:

  • Secara otomatis pulih dari kegagalan – Dengan memantau alur kerja IDP Anda untuk indikator kinerja utama (KPI), Anda dapat menjalankan otomatisasi ketika ambang batas dilanggar. Hal ini memungkinkan Anda melacak dan diberi tahu secara otomatis jika terjadi kegagalan dan memicu proses pemulihan otomatis yang mengatasi atau memperbaiki kegagalan tersebut. Berdasarkan ukuran KPI, Anda juga dapat mengantisipasi kegagalan dan menerapkan tindakan perbaikan sebelum terjadi.
  • Uji prosedur pemulihan – Uji bagaimana alur kerja IDP Anda gagal, dan validasi prosedur pemulihan. Gunakan otomatisasi untuk menyimulasikan berbagai skenario atau membuat ulang skenario yang sebelumnya menyebabkan kegagalan.
  • Skalakan dan sesuaikan kapasitas layanan – Memantau permintaan dan penggunaan alur kerja IDP, dan secara otomatis menyesuaikan kapasitas layanan AWS, untuk mempertahankan tingkat optimal guna memenuhi permintaan tanpa penyediaan yang berlebihan atau kurang. Kontrol dan waspadai kuota layanan, batasan, dan batasan layanan komponen IDP Anda, seperti Teks Amazon dan Amazon Comprehend.
  • Otomatiskan perubahan – Gunakan otomatisasi saat menerapkan perubahan pada infrastruktur alur kerja IDP Anda. Kelola perubahan melalui otomatisasi, yang kemudian dapat dilacak dan ditinjau.

Area fokus

Prinsip desain dan praktik terbaik pilar keandalan didasarkan pada wawasan yang dikumpulkan dari pelanggan kami dan komunitas spesialis teknis IDP kami. Gunakan hal tersebut sebagai panduan dan dukungan untuk keputusan desain Anda dan selaraskan dengan kebutuhan bisnis solusi IDP Anda. Menerapkan Lensa IDP Well-Architected membantu Anda memvalidasi ketahanan dan efisiensi desain solusi IDP Anda, dan memberikan rekomendasi untuk mengatasi kesenjangan yang mungkin Anda identifikasi.

Berikut ini adalah area praktik terbaik untuk keandalan solusi IDP di cloud:

  • Foundations – Layanan AWS AI seperti Amazon Textract dan Amazon Comprehend memberikan serangkaian batasan lunak dan keras untuk berbagai dimensi penggunaan. Penting untuk meninjau batas-batas ini dan memastikan solusi IDP Anda mematuhi batas lunak apa pun, namun tidak melebihi batas keras apa pun.
  • Manajemen perubahan – Perlakukan solusi IDP Anda sebagai infrastruktur sebagai kode (IaC), memungkinkan Anda mengotomatisasi pemantauan dan manajemen perubahan. Gunakan kontrol versi di seluruh komponen seperti infrastruktur dan model kustom Amazon Comprehend, dan lacak perubahan kembali ke rilis point-in-time.
  • Manajemen kegagalan – Karena alur kerja IDP adalah solusi berbasis peristiwa, aplikasi Anda harus tangguh dalam menangani kesalahan yang diketahui dan tidak diketahui. Solusi IDP yang dirancang dengan baik memiliki kemampuan untuk mencegah kegagalan dan menahan kegagalan ketika terjadi dengan menggunakan mekanisme logging dan percobaan ulang. Penting untuk merancang ketahanan ke dalam arsitektur alur kerja IDP Anda dan merencanakan pemulihan bencana.

Foundations

Layanan AWS AI memberikan kecerdasan siap pakai, seperti ekstraksi dan analisis data otomatis, menggunakan Amazon Textract, Amazon Comprehend, dan Amazon Augmented AI (Amazon A2I), untuk alur kerja IDP Anda. Terdapat batasan layanan (atau kuota) untuk layanan ini untuk menghindari penyediaan berlebihan dan membatasi tingkat permintaan pada operasi API, sehingga melindungi layanan dari penyalahgunaan.

Saat merencanakan dan merancang arsitektur solusi IDP Anda, pertimbangkan praktik terbaik berikut:

  • Waspadai kuota, batasan, dan batasan layanan Amazon Textract dan Amazon Comprehend yang tidak dapat diubah – Format file yang diterima, ukuran dan jumlah halaman, bahasa, rotasi dokumen, dan ukuran gambar adalah beberapa contoh batasan keras untuk Amazon Textract yang tidak dapat diubah.
    • Format file yang diterima meliputi file JPEG, PNG, PDF, dan TIFF. (Gambar berkode JPEG 2000 dalam PDF didukung). Pemrosesan awal dokumen diperlukan sebelum menggunakan Amazon Textract jika format file tidak didukung (misalnya, Microsoft Word atau Excel). Dalam hal ini, Anda harus mengonversi format dokumen yang tidak didukung ke format PDF atau gambar.
    • Amazon Comprehend memiliki kuota berbeda untuk model bawaan, model kustom, dan flywheel. Pastikan kasus penggunaan Anda selaras dengan kuota Amazon Comprehend.
  • Sesuaikan kuota layanan Amazon Textract dan Amazon Comprehend untuk memenuhi kebutuhan Anda – Kalkulator Kuota Layanan Amazon Textract dapat membantu Anda memperkirakan nilai kuota yang akan mencakup kasus penggunaan Anda. Anda harus mengelola kuota layanan di seluruh akun atau Wilayah jika Anda merencanakan failover pemulihan bencana antar akun atau Wilayah untuk solusi Anda. Saat meminta peningkatan kuota Amazon Textract, pastikan untuk mengikuti rekomendasi berikut:
    • Gunakan Kalkulator Kuota Layanan Amazon Textract untuk memperkirakan nilai kuota optimal Anda.
    • Perubahan permintaan dapat menyebabkan lalu lintas jaringan tidak stabil, sehingga memengaruhi throughput. Gunakan arsitektur antrian tanpa server atau mekanisme lain untuk memperlancar lalu lintas dan mendapatkan hasil maksimal dari alokasi transaksi per detik (TPS) Anda.
    • Terapkan logika percobaan ulang untuk menangani panggilan yang dibatasi dan koneksi terputus.
    • Konfigurasikan backoff dan jitter eksponensial untuk meningkatkan throughput.

Manajemen perubahan

Perubahan pada alur kerja IDP Anda atau lingkungannya, seperti lonjakan permintaan atau file dokumen yang rusak, harus diantisipasi dan diakomodasi untuk mencapai keandalan solusi yang lebih tinggi. Beberapa dari perubahan ini tercakup dalam praktik terbaik dasar yang dijelaskan di bagian sebelumnya, namun hal tersebut saja tidak cukup untuk mengakomodasi perubahan. Praktik terbaik berikut juga harus dipertimbangkan:

  • penggunaan amazoncloudwatch untuk memantau komponen alur kerja IDP Anda, seperti Amazon Textract dan Amazon Comprehend. Kumpulkan metrik dari alur kerja IDP, otomatiskan respons terhadap alarm, dan kirim pemberitahuan sesuai kebutuhan alur kerja dan tujuan bisnis Anda.
  • Terapkan solusi alur kerja IDP Anda dan semua perubahan infrastruktur dengan otomatisasi menggunakan IaC, seperti Kit Pengembangan AWS Cloud (AWS CDK) dan konstruksi IDP AWS CDK yang telah dibuat sebelumnya. Hal ini menghilangkan potensi terjadinya kesalahan manusia dan memungkinkan Anda melakukan pengujian sebelum beralih ke lingkungan produksi.
  • Jika kasus penggunaan Anda memerlukan model kustom Amazon Comprehend, pertimbangkan untuk menggunakan flywheel untuk menyederhanakan proses peningkatan model kustom dari waktu ke waktu. Roda gila mengatur tugas yang terkait dengan pelatihan dan evaluasi versi model kustom baru.
  • Jika kasus penggunaan Anda memerlukannya, sesuaikan output fitur Kueri terlatih Amazon Textract dengan melatih dan menggunakan adaptor untuk model dasar Amazon Textract. Pertimbangkan praktik terbaik berikut saat membuat kueri untuk adaptor Anda:
    • Kuota adaptor menentukan batas sebelumnya untuk pelatihan adaptor. Pertimbangkan batasan berikut dan ajukan permintaan peningkatan kuota layanan, jika diperlukan:
      • Jumlah maksimum adaptor – Jumlah adaptor yang diizinkan (Anda dapat memiliki beberapa versi adaptor dalam satu adaptor).
      • Versi adaptor maksimum dibuat per bulan – Jumlah versi adaptor berhasil yang dapat dibuat per akun AWS per bulan.
      • Versi adaptor maksimum yang sedang dalam proses – Jumlah versi adaptor yang sedang berlangsung (pelatihan adaptor) per akun.
    • Pastikan untuk menggunakan sekumpulan dokumen yang mewakili kasus penggunaan Anda (minimal lima dokumen pelatihan dan lima dokumen pengujian).
    • Sediakan dokumen pelatihan sebanyak mungkin (hingga 2,500 halaman dokumen pelatihan dan 1,000 halaman untuk dokumen ujian).
    • Beri anotasi pada kueri menggunakan berbagai jawaban. Misalnya, jika jawaban atas pertanyaan adalah “Ya” atau “Tidak”, sampel yang diberi anotasi harus memiliki kemunculan “Ya” dan “Tidak”.
    • Pertahankan konsistensi dalam gaya anotasi dan saat memberi anotasi pada bidang dengan spasi.
    • Gunakan kueri persis yang digunakan dalam pelatihan untuk inferensi.
    • Setelah setiap putaran pelatihan adaptor, tinjau metrik kinerja untuk menentukan apakah Anda perlu meningkatkan adaptor lebih lanjut untuk mencapai tujuan Anda. Unggah kumpulan dokumen baru untuk pelatihan atau tinjau anotasi dokumen yang memiliki skor akurasi rendah sebelum Anda memulai pelatihan baru untuk membuat versi adaptor yang ditingkatkan.
    • Gunakan AutoUpdate fitur untuk adaptor khusus. Fitur ini mencoba pelatihan ulang otomatis jika AutoUpdate bendera diaktifkan pada adaptor.

Manajemen kegagalan

Saat merancang solusi IDP, salah satu aspek penting yang perlu dipertimbangkan adalah ketahanannya, cara menangani kesalahan yang diketahui dan tidak diketahui yang dapat terjadi. Solusi IDP harus memiliki kemampuan mencatat kesalahan dan mencoba kembali operasi yang gagal, selama berbagai tahapan alur kerja IDP. Di bagian ini, kami membahas detail tentang cara merancang alur kerja IDP Anda untuk menangani kegagalan.

Persiapkan alur kerja IDP Anda untuk mengelola dan menahan kegagalan

“Semuanya gagal, sepanjang waktu,” adalah kutipan terkenal dari AWS CTO Werner Vogels. Solusi IDP Anda, seperti solusi lainnya, pada akhirnya akan gagal. Pertanyaannya adalah bagaimana solusi ini dapat bertahan dari kegagalan tanpa berdampak pada pengguna solusi IDP Anda. Desain arsitektur IDP Anda harus menyadari kegagalan yang terjadi dan mengambil tindakan untuk menghindari dampak pada ketersediaan. Ini harus dilakukan secara otomatis, dan tanpa dampak pengguna. Pertimbangkan praktik terbaik berikut:

  • penggunaan Layanan Penyimpanan Sederhana Amazon (Amazon S3) sebagai penyimpanan data terukur untuk memproses dokumen alur kerja IDP. Amazon S3 menyediakan infrastruktur penyimpanan yang sangat tahan lama yang dirancang untuk penyimpanan data penting dan primer.
  • Cadangkan semua data alur kerja IDP Anda sesuai dengan kebutuhan bisnis Anda. Menerapkan strategi untuk memulihkan atau mereproduksi data jika terjadi kehilangan data. Selaraskan strategi ini dengan Sasaran Titik Pemulihan (RPO) dan Sasaran Waktu Pemulihan (RTO) yang ditetapkan dan memenuhi kebutuhan bisnis Anda.
  • Jika diperlukan, rencanakan dan terapkan strategi failover pemulihan bencana dari solusi IDP Anda di seluruh Akun dan Wilayah AWS.
  • Gunakan Amazon Textract OutputConfig fitur dan Amazon Comprehend OutputDataConfig fitur untuk menyimpan hasil pemrosesan asinkron dari Amazon Textract atau Amazon Comprehend ke bucket S3 yang ditunjuk. Hal ini memungkinkan alur kerja untuk melanjutkan dari titik tersebut daripada mengulangi pemanggilan Amazon Textract atau Amazon Comprehend. Kode berikut menunjukkan cara memulai pekerjaan API asinkron Amazon Textract untuk menganalisis dokumen dan menyimpan output inferensi terenkripsi dalam bucket S3 yang ditentukan. Untuk informasi tambahan, lihat Dokumentasi klien Amazon Textract.
import boto3
client = boto3.client('textract') response = client.start_document_analysis( DocumentLocation={ 'S3Object': { 'Bucket': 'string', 'Name': 'string', 'Version': 'string' } }, FeatureTypes=[ 'TABLES'|'FORMS'|'QUERIES'|'SIGNATURES'|'LAYOUT', ], … OutputConfig={ 'S3Bucket': 'string', 'S3Prefix': 'string' }, KMSKeyId='string' …
)

Rancang alur kerja IDP Anda untuk mencegah kegagalan

Keandalan beban kerja dimulai dengan keputusan desain awal. Pilihan arsitektur akan memengaruhi perilaku beban kerja Anda dan ketahanannya. Untuk meningkatkan keandalan solusi IDP Anda, ikuti praktik terbaik berikut.

Pertama, rancang arsitektur Anda mengikuti alur kerja IDP. Meskipun tahapan dalam alur kerja IDP dapat bervariasi dan dipengaruhi oleh kasus penggunaan dan persyaratan bisnis, tahapan pengambilan data, klasifikasi dokumen, ekstraksi teks, pengayaan konten, peninjauan dan validasi, serta konsumsi biasanya merupakan bagian dari alur kerja IDP. Tahapan yang terdefinisi dengan baik ini dapat digunakan untuk memisahkan fungsi dan mengisolasinya jika terjadi kegagalan.

Anda dapat menggunakan Layanan Antrian Sederhana Amazon (Amazon SQS) untuk memisahkan tahapan alur kerja IDP. Pola pemisahan membantu mengisolasi perilaku komponen arsitektur dari komponen lain yang bergantung padanya, sehingga meningkatkan ketahanan dan ketangkasan.

Kedua, kendalikan dan batasi panggilan coba lagi. Layanan AWS seperti Amazon Textract dapat gagal jika jumlah maksimum TPS yang dialokasikan terlampaui, sehingga menyebabkan layanan membatasi aplikasi Anda atau memutuskan koneksi Anda.

Anda harus mengelola pembatasan dan koneksi terputus dengan mencoba ulang operasi secara otomatis (operasi sinkron dan asinkron). Namun, Anda juga harus menentukan jumlah percobaan ulang yang terbatas, setelah itu operasi gagal dan memunculkan pengecualian. Jika Anda melakukan terlalu banyak panggilan ke Amazon Textract dalam waktu singkat, panggilan Anda akan dibatasi dan dikirimkan a ProvisionedThroughputExceededExceptionerror dalam respon operasi.

Selain itu, gunakan backoff dan jitter eksponensial untuk percobaan ulang guna meningkatkan throughput. Misalnya, menggunakan Amazon Textract, tentukan jumlah percobaan ulang dengan menyertakan config parameter saat Anda membuat klien Amazon Textract. Kami merekomendasikan percobaan ulang dalam hitungan lima. Dalam contoh kode berikut, kami menggunakan config parameter untuk mencoba ulang operasi secara otomatis menggunakan mode adaptif dan maksimal lima kali percobaan ulang:

import boto3
from botocore.client import Config documents = ['doc-img-1.png','doc-img-2.png', 'doc-img-3.png', 'doc-img-4.png', 'doc-img-5.png'] config = Config( retries = { 'max_attempts': 5, 'mode': 'adaptive' }
) client = boto3.client('textract', config=config) for documentName in documents: response = client.detect_document_text( DocumentLocation = { 'S3Object': { 'Bucket': 'string', 'Name': documentName } }) ...

Manfaatkan AWS SDK, seperti AWS SDK untuk Python (Boto3), untuk membantu mencoba kembali panggilan klien ke layanan AWS seperti Amazon Textract dan Amazon Comprehend. Ada tiga mode coba lagi tersedia:

  • Mode warisan – Percobaan ulang memerlukan sejumlah kesalahan dan pengecualian dan menyertakan backoff eksponensial dengan faktor dasar 2.
  • Mode standar – Menstandarkan logika dan perilaku percobaan ulang yang konsisten dengan SDK AWS lainnya dan memperluas fungsionalitas percobaan ulang dibandingkan yang ditemukan dalam mode lama. Setiap upaya percobaan ulang akan mencakup kemunduran eksponensial dengan faktor dasar 2 untuk waktu kemunduran maksimum 20 detik.
  • Mode adaptif – Mencakup semua fitur mode standar dan memperkenalkan pembatasan tarif sisi klien melalui penggunaan keranjang token dan variabel batas tarif yang diperbarui secara dinamis dengan setiap upaya percobaan ulang. Ini menawarkan fleksibilitas dalam percobaan ulang sisi klien yang beradaptasi dengan respons status kesalahan atau pengecualian dari layanan AWS. Dengan setiap upaya percobaan ulang baru, mode adaptif memodifikasi variabel batas laju berdasarkan kesalahan, pengecualian, atau kode status HTTP yang disajikan dalam respons dari layanan AWS. Variabel batas tarif ini kemudian digunakan untuk menghitung tarif panggilan baru untuk klien. Setiap pengecualian, kesalahan, atau respons HTTP yang tidak berhasil dari layanan AWS memperbarui variabel batas laju saat percobaan ulang terjadi hingga keberhasilan tercapai, bucket token habis, atau nilai upaya maksimum yang dikonfigurasi tercapai. Contoh pengecualian, kesalahan, atau respons HTTP yang tidak berhasil:
# Transient errors/exceptions
RequestTimeout
RequestTimeoutException
PriorRequestNotComplete
ConnectionError
HTTPClientError # Service-side throttling/limit errors and exceptions
Throttling
ThrottlingException
ThrottledException
RequestThrottledException
TooManyRequestsException
ProvisionedThroughputExceededException
TransactionInProgressException
RequestLimitExceeded
BandwidthLimitExceeded
LimitExceededException
RequestThrottled
SlowDown
EC2ThrottledException #Retry attempts on nondescriptive, transient error codes. Specifically, these HTTP status codes: 500, 502, 503, 504.

Kesimpulan

Dalam postingan ini, kami berbagi prinsip desain, area fokus, fondasi, dan praktik terbaik untuk keandalan solusi IDP Anda.

AWS berkomitmen terhadap IDP Well-Architected Lens sebagai alat yang hidup. Seiring dengan berkembangnya solusi IDP dan layanan AI AWS terkait serta tersedianya layanan AWS baru, kami akan memperbarui Lensa IDP yang Diarsitektur dengan Baik.

Jika Anda ingin mempelajari lebih lanjut tentang AWS Well-Architected Framework, lihat Arsitek AWS dengan Baik.

Jika Anda memerlukan panduan ahli tambahan, hubungi tim akun AWS Anda untuk melibatkan Arsitek Solusi Spesialis IDP.


Tentang Penulis

Rui Cardoso adalah arsitek solusi mitra di Amazon Web Services (AWS). Dia fokus pada AI/ML dan IoT. Dia bekerja dengan Partner AWS dan mendukung mereka dalam mengembangkan solusi di AWS. Saat tidak bekerja, dia menikmati bersepeda, mendaki gunung, dan mempelajari hal-hal baru.

Brijesh Pati adalah Arsitek Solusi Perusahaan di AWS. Fokus utamanya adalah membantu pelanggan perusahaan mengadopsi teknologi cloud untuk beban kerja mereka. Dia memiliki latar belakang dalam pengembangan aplikasi dan arsitektur perusahaan dan telah bekerja dengan pelanggan dari berbagai industri seperti olahraga, keuangan, energi, dan layanan profesional. Minatnya mencakup arsitektur tanpa server dan AI/ML.

Mia Chang adalah Arsitek Solusi Spesialis ML untuk Amazon Web Services. Dia bekerja dengan pelanggan di EMEA dan berbagi praktik terbaik untuk menjalankan beban kerja AI/ML di cloud dengan latar belakangnya di bidang matematika terapan, ilmu komputer, dan AI/ML. Dia berfokus pada beban kerja khusus NLP, dan berbagi pengalamannya sebagai pembicara konferensi dan penulis buku. Di waktu luangnya, dia menikmati hiking, permainan papan, dan menyeduh kopi.

Tim Condello adalah arsitek solusi spesialis kecerdasan buatan (AI) dan pembelajaran mesin (ML) senior di Amazon Web Services (AWS). Fokusnya adalah pemrosesan bahasa alami dan visi komputer. Tim senang mengambil ide pelanggan dan mengubahnya menjadi solusi terukur.

Sherly Ding adalah arsitek solusi spesialis kecerdasan buatan (AI) dan pembelajaran mesin (ML) senior di Amazon Web Services (AWS). Dia memiliki pengalaman luas dalam pembelajaran mesin dengan gelar PhD di bidang ilmu komputer. Dia terutama bekerja dengan pelanggan sektor publik dalam berbagai tantangan bisnis terkait AI/ML, membantu mereka mempercepat perjalanan pembelajaran mesin mereka di AWS Cloud. Saat tidak membantu pelanggan, dia menikmati aktivitas di luar ruangan.

Suyin Wang adalah Arsitek Solusi Spesialis AI/ML di AWS. Dia memiliki latar belakang pendidikan interdisipliner dalam Pembelajaran Mesin, Layanan Informasi Keuangan, dan Ekonomi, serta pengalaman bertahun-tahun dalam membangun aplikasi Ilmu Data dan Pembelajaran Mesin yang memecahkan masalah bisnis dunia nyata. Dia senang membantu pelanggan mengidentifikasi pertanyaan bisnis yang tepat dan membangun solusi AI/ML yang tepat. Di waktu luangnya, dia suka menyanyi dan memasak.

tempat_img

Intelijen Terbaru

tempat_img