doc rag harness

Pengambilan Dokumen Pengambilan Generasi augmented (RAG) harness

Area pengambilan generasi augmented berkembang pesat. Ada banyak cara berbeda untuk menerapkan pengambilan. Beberapa orang menggunakan database embeddings dan vektor, beberapa menggunakan grafik semantik lainnya. Jadi, ada desain yang berbeda dan juga ada tugas yang berbeda dan penting untuk mencocokkan desain dengan tugas ¹ .

Tujuan harness ini untuk memberikan definisi koleksi, abstraksi, dan blok bangunan untuk membantu dalam memahami, membandingkan, membandingkan, dan memilih desain pengambilan khusus yang paling cocok dengan tugas yang ada.

Harness dimaksudkan untuk agak mirip dengan Technology + Technology Compatibility Kit (TCK) - untuk menyediakan:

• Java/EMF Ecore Model/API untuk penyimpanan dan pengambilan dokumen termasuk "Antarmuka Penyedia Desain" yang akan diimplementasikan oleh Calon Desain
• Kerangka kerja pengujian untuk mengevaluasi bagaimana desain yang berbeda melakukan tugas tertentu.

Java terpilih sebagai teknologi dominan di dunia perusahaan dengan kekuatan ekspresif yang kaya dari bahasa dan ekosistem dewasa yang besar. EMF Ecore dipilih karena ada kemampuan:

• Muat model/simpan dari/ke YAML, XMI dan file biner serta database
• Hasilkan dokumentasi HTML dari model dan metamodel
• Dukungan perkakas untuk membangun pemirsa dan editor - pohon, diagram, teks; Eclipse IDE dan Browser Web

Halaman ini memberikan pengantar konsep inti dan menguraikan beberapa kasus penggunaan (tugas) dan desain (alternatif).

Konsep

Diagram di bawah ini menguraikan struktur dan konteks harness:

Bagian berikut memberikan definisi dan garis besar dimensi tugas/desain untuk setiap definisi. Metamodel menangkap beberapa definisi sebagai elemen model dan menguraikannya menjadi fitur, operasi, dan subclass.

Dokumen

Dokumen adalah representasi pemikiran atau informasi yang diabaikan. Untuk keperluan dokumen harness ini:

• Disimpan dalam sumber dokumen/repositori (seperti buku di perpustakaan)
• Dapat dikategorikan dan kategori dapat bersarang (misalnya genre buku - fiksi / sci -fi)
• Dapat memiliki struktur internal (misalnya volume, bab, bagian, paragraf, kata)
• Dapat berisi berbagai jenis konten - teks, gambar, video, audio, struktur seperti daftar dan tabel
• Dapat merujuk dokumen lain atau entitas eksternal

Implementasi "fisik":

• File teks
• Pdf. Di java dapat dimuat menggunakan apache pdfbox
• OCR menghasilkan, katakanlah, json
• MS Office Documents - Di Java dapat dimuat dengan Apache PoI. File MS Excel dapat dimuat sebagai model Ecore dengan model Nasdanika Excel
• Dokumen/halaman HTML (subtipe teks)

Implementasi "logis":

• Untuk PDF/OCR - pemindaian dokumen bisnis. Misalnya, faks dari pesan cepat. Dalam hal ini:
  • Header dan footer ditambahkan oleh faks mungkin dihapus sebagai tidak relevan
  • Badan halaman mungkin diuraikan ke dalam struktur spesifik yang cepat, misalnya Mt 700
  • Embeddings mungkin dibuat untuk tubuh atau paragraf atau klausa untuk beberapa elemen, nomor klausa mungkin dikecualikan dari teks. Agak mirip dengan embedding artikel wikipedia di mana embeddings dihitung untuk bagian -bagian tidak termasuk header.
• Untuk HTML - Halaman Dokumentasi. Katakanlah, Spring Expression Language (SPEL) dalam header kasus ini, navigasi kiri, sidebar kanan, dan footer mungkin dibuang sebagai tidak relevan atau diuraikan ke dalam fitur dokumen logis masing -masing yang mungkin diabaikan. Breadcrumb dapat digunakan untuk kategorisasi.
• Untuk file teks - tergantung pada jenis konten. EG pom.xml dapat dimuat ke dalam model objek proyek, file java dapat dimuat ke pohon sintaks atau grafik dengan referensi tipe/bidang/metode yang diselesaikan.

Loader dokumen

Mengubah satu representasi dokumen ke yang lain. Misalnya PDF atau OCR JSON ke model objek dari pesan Swift Mt 700.

Sumber Dokumen

Penyimpanan dokumen dalam format atau format tertentu. Misalnya sistem file dengan dokumen PDF. Sumber dokumen dapat dikonversi/diadaptasi. Salah satu contoh sumber dokumen adalah komitmen git. Model Nasdanika Gitlab dapat digunakan untuk mengimplementasikan pemuatan dokumen dari GitLab.

Repositori Dokumen

Kumpulan dokumen yang menyediakan fungsionalitas penyimpanan dan pengambilan. Antarmuka utama DPI (lihat di bawah) yang akan diimplementasikan oleh desain.

Saat menyimpan dokumen, repositori dapat melakukan tugas -tugas seperti pengenalan gambar.

Mungkin ada beberapa modalitas pengambilan seperti:

• Pencarian Kata Kunci
• Pencarian semantik
• Ringkasan - Cari dan Ringkas Hasil X Top

Repositori dapat dikumpulkan dari repositori lain dan pemuat data. Misalnya repositori PDF dapat dirakit dari PDF -> Model Object Data Loader dan repositori model objek. Juga dokumen repositori mungkin tidak perlu menyimpan/membuat ulang dokumen sumber - mereka dapat merujuk dan mengambil dari toko dokumen - yang asli dari mana dokumen dimuat, atau toko dokumen khusus repositori.

Dimungkinkan juga untuk menyusun desain repositori yang berbeda. Misalnya, repositori yang mendukung pencarian kata kunci dan repositori yang mendukung pencarian semantik. Dalam hal ini hasil kueri repositori pencarian kata kunci akan diperlukan, tetapi tidak cukup dan mungkin digunakan untuk memvalidasi hasil repositori pencarian semantik.

Pengguna / Web UI

Pengguna menanyakan repositori dokumen melalui Web UI. Mereka dapat melakukannya sebagai bagian dari fungsi pekerjaan mereka atau untuk mengevaluasi fungsi kueri dari desain tertentu dan memberikan umpan balik. Kedua modalitas ini dapat digabungkan - pengguna dapat memilih untuk hanya menggunakan mesin/desain kueri "Champion", misalnya pencarian kata kunci, atau juga memilih mesin/desain "penantang".

UI Web dapat menangkap konteks pengguna seperti peran/posisi dalam organisasi dan meneruskannya ke desain sebagai bagian dari kueri.

Sponsor

Suatu pihak yang tertarik untuk meningkatkan kualitas pekerjaan pengguna seperti produktivitas dengan memanfaatkan pembuatan augmented dokumen.

Sponsor perlu menyeimbangkan beberapa kriteria untuk meminimalkan "fungsi kerugian":

• Kecepatan pengambilan
• Ketepatan
• Kelengkapan
• Biaya seperti biaya operasional, biaya lisensi dll.

Desain

Desain adalah instantiasi/perwujudan teknologi dan parameter konfigurasinya.

Dimensi desain

Poin Variasi Desain - Apa yang dapat diubah dalam perwujudan/instantiasi dan sumber nilai yang berbeda. Misalnya:

• Jumlah dimensi yang menanamkan
• Model ML
• Suhu model
• Database vektor
• Versi Database Vektor

Dimensi desain dapat membentuk pohon atau, lebih tepatnya, grafik terarah. EG versi basis data vektor akan menjadi node di bawah node untuk database vektor tertentu.

Antarmuka penyedia desain

Desain Penyedia Antarmuka (DPI) Abstrak harness dari implementasi desain tertentu. Ini adalah seperangkat antarmuka dan kelas abstrak yang harus diterapkan oleh desain. Misalnya antarmuka DocumentRepository . DPI didefinisikan dalam Java/Ecore dan dapat memberikan adaptor untuk berbagai teknologi. Secara khusus:

• API istirahat
• Binding bahasa dan pelari yang mengimplementasikan API REST dan panggilan komponen yang mengimplementasikan antarmuka pengikat bahasa. Misalnya ikatan python dapat diimplementasikan dengan flask
• Binding/implementasi kerangka kerja di bawah binding bahasa atau langsung di bawah DPI di Java. Misalnya di bawah ikatan python mungkin ada ikatan langchain dan di bawah java mungkin ada ikatan terbuka

Tugas

Tugas adalah penggunaan khusus pengambilan dokumen. Misalnya, pencarian semantik dalam dokumentasi teknis khusus organisasi "bagaimana cara menggunakan layanan mikro musim semi ke AKS?".

Kumpulan data uji

Kumpulan dokumen uji, pertanyaan, dan evaluator tanggapan.

Input pelari

Kumpulan kumpulan data uji / kombinasi desain yang akan dieksekusi oleh pelari uji.

Test Runner

• Membaca input
• Instantiates Set Data dan Desain
• Memuat dokumen dari data uji yang disetel ke dalam desain
• Mengeksekusi kueri dan mengevaluasi tanggapan. Evaluator respons dapat memberikan umpan balik untuk desain
• Menyimpan hasil tes untuk analisis lebih lanjut dan pembuatan laporan

Test Runner hanya dapat menjalankan bagian dari langkah -langkah di atas tergantung pada input. Misalnya:

• Mungkin sudah ada desain dengan dokumen yang sudah dimuat sebelumnya dan pelari uji hanya akan menjalankan bagian kueri
• Atau set data uji hanya berisi dokumen, tetapi bukan evaluator respons karena kueri dan respons harus disediakan oleh pengguna melalui Web UI
• Test Runner dapat memuat dokumen ke desain dan menyimpannya sebagai desain baru. Misalnya membuat wadah dari gambar, memuat dokumen, dan kemudian menghentikan wadah dan membuat gambar dari wadah.
• Demikian pula, pelari uji dapat mengambil kumpulan data uji, menggabungkannya dengan umpan balik yang diberikan pengguna dan membuat dan membuat set data uji baru.

Uji dapat didistribusikan di beberapa agen/mesin.

Hasil Uji & Umpan Balik Pengguna

Penyimpanan hasil tes dan umpan balik pengguna. Hasil tes dan umpan balik pengguna harus merujuk set data dan desain uji. Dengan demikian, ini pada dasarnya adalah harness metadata repositori yang berisi definisi desain pohon/grafik, definisi set data uji, dan hasil uji berjalan.

Generator Laporkan

Menghasilkan laporan. Laporan mungkin dalam format HTML dengan visualisasi. Format laporan yang mungkin:

• Panel kiri dengan pohon desain, pohon tugas, dan set data uji untuk tugas. Ini juga dapat mencakup "Tech Stack Tree" - Blok bangunan desain yang dikategorikan. Misalnya, basis data pohon vektor, versi dan konfigurasi mereka. Jika panel kiri menjadi terlalu bising, beberapa barang dapat dipindahkan ke bilah navigasi.
• Panel Konten - Dokumentasi untuk item yang dipilih. Misalnya
  • Halaman Beranda - Ringkasan tes yang dilakukan: Tabel yang dapat diurutkan yang dapat diurutkan dengan permutasi desain/uji (untuk ruang yang relatif kecil), visualisasi, misalnya Echarts 3D sebar. Ini juga mungkin berisi wizard desain untuk membangun desain dengan menjawab pertanyaan dan memilih desain yang diuji yang paling sesuai dengan jawabannya.
  • Halaman Desain - Konfigurasi, Tes dan Hasil - Tabel, Visualisasi
  • Halaman Tugas - Deskripsi, Tes, Desain, Visualisasi. Ini dapat meng -host UI Web Agregasi yang mengumpulkan jawaban dari semua desain untuk tugas ini dan memungkinkan pengguna untuk membandingkan respons dari desain alternatif. Salah satu opsi untuk membandingkan adalah perbandingan berpasangan mungkin tanpa menikmati reveing ​​mana dari respons yang diberikan berasal.
  • Building Block (misalnya database vektor, versinya, konfigurasi) - deskripsi, desain yang menggunakannya.

Laporan dapat berisi tautan ke UI Web atau bahkan "Host" Web UI jika diimplementasikan sebagai aplikasi satu halaman (SPA) dengan, katakanlah, bereaksi atau vue.js/bootstrapvue

Masyarakat

Para pihak yang berkontribusi pada set data harness, desain, dan uji. Anggota masyarakat dapat memainkan peran yang berbeda pada komponen yang berbeda.

--- bekerja dalam proses ---

Tugas

Bagian ini menguraikan beberapa tugas (kasus penggunaan) untuk pengambilan generasi augmented dan pencarian secara umum.

Ukuran:

• Jumlah dokumen
• Jumlah pengguna
• Frekuensi perubahan
• Pribadi
• Risiko - Biaya Kesalahan

Dokumentasi teknis

Contoh - Fungsi teknologi dalam perusahaan besar:

• Beberapa tingkatan:
  • Corporate, Binds Enterprise-Wide Technology Choices (misalnya Java/Spring, Maven Components), menyediakan blok bangunan bersama di seluruh perusahaan (misalnya perpustakaan komponen bootstrap) dan teknologi lainnya (misalnya pipa pembuatan)
  • Segmen - Pilihan Teknologi Berselah, misalnya versi Java, tambahkan cara -cara khusus segmen dalam melakukan hal -hal di atas pedoman perusahaan (yang pada gilirannya dibangun di atas pedoman dan dokumentasi teknologi industri/vendor). Dapat memperkenalkan blok bangunan tingkat segmen.
  • Kemampuan/Tim - Pilihan teknologi lebih jauh lebih jauh dan memperbaiki bagaimana mereka digunakan. Dapat memperkenalkan blok bangunan tingkat kemampuan/tim seperti pustaka widget.

Untuk masing -masing di atas ada dimensi waktu - pembaruan tumpukan teknologi di bagian atas, rilis di bagian bawah. Lihat lansekap arsitektur TOGAF untuk visualisasi.

Dalam lingkungan seperti itu pengguna membutuhkan solusi pengambilan yang memungkinkan untuk mengambil dokumen khusus untuk posisi dan peran pengguna dalam perusahaan dan upaya yang ditugaskan. Misalnya pengembang Java yang bekerja, katakanlah rilis saat ini mungkin memerlukan informasi tentang Java 17. Jika pengembang yang sama ditugaskan untuk bekerja pada rilis di masa depan mereka mungkin memerlukan informasi tentang, katakanlah, Java 20. Ketika mereka bekerja dengan teknologi seperti Kubernetes dan Azure yang diketahui.

• Jumlah Dokumen: Puluhan ribu
• Jumlah Pengguna: Ratusan hingga Ribuan
• Frekuensi Perubahan: Rendah (misalnya bulanan) hingga sedang (beberapa kali sebulan)
• Privasi: Internal
• Risiko: Rendah

Prosedur

Ukuran:

• Jumlah Dokumen: Ribuan Rendah
• Jumlah Pengguna: Ratusan hingga Ribuan
• Frekuensi Perubahan: Rendah (misalnya bulanan)
• Privasi: internal, terbatas, rahasia
• Risiko: sedang hingga tinggi

Dokumen operasional

Ukuran:

• Jumlah Dokumen: Mungkin jutaan
• Jumlah Pengguna: Ratusan hingga Ribuan
• Frekuensi Perubahan: Tinggi (Harian)
• Privasi: Rahasia, Informasi Pribadi - PII, PHI, PCI
• Risiko: Tinggi

Desain

Embeddings, Vector Database, LLM

Todo. Menurut informasi industri menargetkan sejumlah besar dokumen - cocok dengan kasus penggunaan dokumen operasional

Grafik

Todo. Mungkin lebih baik untuk sejumlah kecil dokumen (prosedur) - semuanya mungkin sesuai dengan memori dan pencarian dapat dilakukan pada grafik semantik. Dalam kasus database vektor, salah satu cara untuk membangun indeks adalah dengan menggunakan grafik - Hierarchical Navigable Small World (HNSW)

Grafik polimorfik

Todo. Mungkin cocok untuk kasus penggunaan dokumentasi teknis:

• Perusahaan ini membangun grafik pengetahuan (model) untuk pilihan teknologi perusahaan. Mungkin ada beberapa model - baseline, rilis di masa depan
• Segmen mengambil grafik/model perusahaan dan menyesuaikan - konsep yang mirip dengan warisan dalam bahasa yang berorientasi objek seperti Java dan juga mirip dengan lapisan di Docker
• Kemampuan/tim dapat mengambilnya lebih jauh

Proses ini akan menghasilkan sejumlah besar (ratusan) grafik/model yang relatif kecil (basis pengetahuan) dengan puluhan ribu dokumen.

Catatan kaki

1. Ruang desain untuk grafik jaringan saraf, kuliah bagian dari Stanford CS224W: ML dengan grafik, slide ↩