Pada tanggal 25 April 2023, Jacob Marks, Ph.D., seorang penulis dan pakar dalam bidang pembelajaran mesin, mempublikasikan sebuah artikel menarik di towardsdatascience.com. Artikel tersebut berjudul “How I Turned My Company’s Docs into a Searchable Database with OpenAI” dan membahas bagaimana ia mengubah dokumen perusahaan menjadi database vektor yang dapat dicari secara semantik dengan menggunakan OpenAI.
Jadi, Dalam artikel tersebut, Marks berbagi langkah-langkah dan bahan yang diperlukan untuk mengimplementasikan pencarian semantik untuk dokumen Anda sendiri. Ini adalah artikel yang menarik dan bermanfaat bagi siapa saja yang tertarik dalam bidang pembelajaran mesin dan teknologi pencarian dokumen.
Selama enam bulan terakhir, Mister Jacob telah bekerja di sebuah startup seri A bernama Voxel51 yang merupakan pencipta dari toolkit visi open source computer FiftyOne. Sebagai seorang insinyur pembelajaran mesin dan pengembang evangelis, tugas saya adalah mendengarkan komunitas sumber terbuka kami dan memberikan apa yang mereka butuhkan – fitur baru, integrasi, tutorial, workshop, dan lain-lain.
Beberapa minggu yang lalu, mereka (Mr. Jacob dan timnya) menambahkan dukungan asli untuk mesin pencari vektor dan kueri kesamaan teks pada FiftyOne, sehingga pengguna dapat menemukan gambar paling relevan dalam dataset mereka (yang seringkali sangat besar – berisi jutaan atau puluhan juta sampel) melalui kueri bahasa alami yang sederhana.
Hal ini menempatkan mereka pada posisi yang menarik: sekarang orang yang menggunakan FiftyOne dapat dengan mudah mencari dataset dengan kueri bahasa alami, tetapi menggunakan dokumentasi kami masih memerlukan pencarian kata kunci tradisional.
jadi, mereka ini memiliki banyak dokumen, yang memiliki kelebihan dan kekurangan. Sebagai pengguna sendiri, terkadang saya merasa bahwa dengan jumlah dokumentasi yang begitu banyak, menemukan apa yang saya cari memerlukan waktu yang lebih lama dari yang saya inginkan.
Mr. Jacob tidak akan membiarkan ini terjadi … jadi ia membangun hal itu pada waktu luang aja:
Beginilah cara seseorang mengubah dokumen perusahaan menjadi database pencarian yang semantik:
1. Mengubah semua dokumen ke dalam format yang seragam
2. Membagi dokumen menjadi blok dan menambahkan pembersihan otomatis
3. Menghitung embedding untuk setiap blok
4. Membuat indeks vektor dari embedding tersebut
5. Mendefinisikan kueri indeks
6. Mengemas semuanya dalam antarmuka baris perintah yang ramah pengguna dan API PythonAnda bisa menemukan semua kode untuk posting ini di repo voxel51/fiftyone-docs-search, dan mudah untuk menginstal paket tersebut secara lokal dengan pip install -e ..
Yang lebih baik lagi, jika Anda ingin menerapkan pencarian semantik untuk situs web Anda sendiri menggunakan metode ini, Anda dapat mengikuti tutorial berikut! Berikut adalah bahan-bahan yang Anda butuhkan:
1. Menginstal paket Python openai dan membuat akun: Anda akan menggunakan akun ini untuk mengirim dokumen dan kueri Anda ke endpoint inferensi, yang akan mengembalikan vektor embedding untuk setiap teks.
2. Menginstal paket Python qdrant-client dan meluncurkan server Qdrant melalui Docker: Anda akan menggunakan Qdrant untuk membuat indeks vektor yang terhosting secara lokal untuk dokumen, yang akan berjalan melawan kueri. Layanan Qdrant akan berjalan di dalam kontainer Docker.
Mengubah Dokumen ke dalam Format yang Seragam.
Dokumen perusahaan dimuat sebagai dokumen HTML di https://docs.voxel51.com. Sebagai titik awal yang wajar, dapat diunduh dokumen ini dengan menggunakan perpustakaan Python “requests” dan mengurai dokumen dengan Beautiful Soup.
Namun, sebagai pengembang (dan penulis banyak dokumen kami), ia berpikir dapat melakukan yang lebih baik. Ia sudah memiliki salinan kerja repositori GitHub di komputernya yang berisi semua file mentah yang digunakan untuk menghasilkan dokumen HTML. Beberapa dokumen kami ditulis dalam Sphinx ReStructured Text (RST), sedangkan yang lain seperti tutorial dikonversi ke HTML dari notebook Jupyter.
Ia mengira (yang keliru) semakin dekat dengan teks mentah file RST dan Jupyter, semakin sederhana hal itu akan menjadi.
RST
Dalam dokumen RST, bagian-bagian dibatasi oleh baris yang terdiri dari hanya tanda sama dengan (=), tanda minus (-) atau garis bawah (_). Sebagai contoh, ini adalah dokumen dari Panduan Pengguna FiftyOne yang mengandung ketiga tanda pemisah tersebut:
Kemudian, ia dapat menghapus semua kata kunci RST, seperti toctree, code-block, dan button_link (ada banyak lagi), serta :, ::, dan .. yang menemani kata kunci, awal blok baru, atau deskriptor blok.
Link-link juga mudah diurus:
no_links_section = re.sub(r"<[^>]+>_?","", section)Namun, masalah mulai muncul ketika ia ingin mengekstrak anchor dari file RST. Banyak bagian yang memiliki anchor yang ditentukan secara eksplisit, sedangkan yang lain dibiarkan diinferensikan saat konversi ke HTML.
Berikut adalah contoh:
.. _brain-embeddings-visualization:
Visualizing embeddings
The FiftyOne Brain provides a powerful
:meth:compute_visualization() <fiftyone.brain.compute_visualization> method
that you can use to generate low-dimensional representations of the samples
and/or individual objects in your datasets.
These representations can be visualized natively in the App's
:ref:Embeddings panel <app-embeddings-panel>, where you can interactively
select points of interest and view the corresponding samples/labels of interest
in the :ref:Samples panel <app-samples-panel>, and vice versa.
.. image:: /images/brain/brain-mnist.png
:alt: mnist
:align: center
Ada dua komponen utama dalam visualisasi embedding: metode yang digunakan untuk menghasilkan embedding, dan metode reduksi dimensionalitas yang digunakan untuk menghitung representasi rendah-dimensional dari embedding.
Metode embedding
Parameter embeddings dan model dari :meth:compute_visualization() <fiftyone.brain.compute_visualization> mendukung berbagai cara untuk menghasilkan embedding untuk data Anda:Dalam file brain.rst di dokumen Panduan Pengguna kami (sebagian dari itu diproduksi di atas), bagian Visualizing embeddings memiliki anchor #brain-embeddings-visualization yang ditentukan oleh .. _brain-embeddings-visualization:. Sedangkan, sub-bagian Embedding methods yang langsung mengikuti, diberikan anchor yang dihasilkan secara otomatis.
Kemudian, masalah lain yang muncul adalah cara menangani tabel di RST. Tabel daftar cukup mudah. Sebagai contoh, ini adalah tabel daftar dari lembar trik View Stages kami:
.. list-table::
* - :meth:`match() <fiftyone.core.collections.SampleCollection.match>`
* - :meth:`match_frames() <fiftyone.core.collections.SampleCollection.match_frames>`
* - :meth:`match_labels() <fiftyone.core.collections.SampleCollection.match_labels>`
* - :meth:`match_tags() <fiftyone.core.collections.SampleCollection.match_tags>`Namun, tabel grid bisa menjadi rumit dengan cepat. Tabel grid memberikan fleksibilitas yang besar bagi penulis dokumen, tetapi fleksibilitas ini membuat analisisnya sulit. Ambil contoh tabel ini dari lembar contekan Filtering kami:
| Operation | Command |
|---|---|
| Filepath starts with “/Users” | .. code-block:: ds.match(F(“filepath”).starts_with(“/Users”)) |
| Filepath ends with “10.jpg” or “10.png” | .. code-block:: ds.match(F(“filepath”).ends_with((“10.jpg”, “10.png”))) |
| Label contains string “be” | .. code-block:: ds.filter_labels(“predictions”, F(“label”).contains_str(“be”)) |
| Filepath contains “088” and is JPEG | .. code-block:: ds.match(F(“filepath”).re_match(“088*.jpg”)) |
Dalam sebuah tabel, baris dapat memakan sejumlah baris yang tidak tentu, dan lebar kolom dapat bervariasi. Blok kode dalam sel tabel grid juga sulit untuk diparsing, karena mereka menempati ruang di beberapa baris, sehingga konten mereka terselip dengan konten dari kolom lain. Hal ini berarti blok kode dalam tabel ini perlu direkonstruksi secara efektif selama proses parsing.
Ini bukan akhir dunia. Tetapi juga tidak ideal.
