rasa Download - rasa Source code download

rasa

Kode Sumber AI

3.6.20

Unduh

Sumber Terbuka Rasa

Kami sedang memigrasikan masalah ke Jira

Mulai Januari 2023, terbitan Rasa Open Source berlokasi di board Jira ini. Anda dapat menelusuri masalah tanpa harus login; jika Anda ingin membuat masalah, Anda harus membuat akun Jira.

Rasa adalah kerangka pembelajaran mesin sumber terbuka untuk mengotomatiskan percakapan berbasis teks dan suara. Dengan Rasa, Anda dapat membuat asisten kontekstual di:

Facebook Messenger
Kendur
Google Hangout
Tim Webex
Kerangka Bot Microsoft
Roket.Obrolan
Yang paling penting
Telegram
Twilio
Saluran percakapan khusus Anda sendiri

atau asisten suara sebagai:

Keterampilan Alexa
Tindakan Beranda Google

Rasa membantu Anda membangun asisten kontekstual yang mampu melakukan percakapan berlapis dengan banyak percakapan bolak-balik. Agar manusia dapat melakukan pertukaran yang bermakna dengan asisten kontekstual, asisten harus dapat menggunakan konteks untuk membangun hal-hal yang telah dibahas sebelumnya – Rasa memungkinkan Anda membangun asisten yang dapat melakukan hal ini dengan cara yang terukur.

Ada lebih banyak informasi latar belakang di postingan blog ini.

? Pelajari selengkapnya tentang Rasa
? Baca Dokumen
? Instal Rasa
Selami lebih dalam pusat pembelajaran
? Menyumbang
❓ Dapatkan dukungan tingkat perusahaan
? Jelajahi fitur platform komersial kami
Pelajari lebih lanjut tentang makalah penelitian yang memanfaatkan Rasa

Di mana mendapatkan bantuan

Ada dokumentasi ekstensif di Rasa Docs. Pastikan untuk memilih versi yang benar sehingga Anda dapat melihat dokumen untuk versi yang Anda instal.

Silakan gunakan Forum Komunitas Rasa untuk jawaban cepat atas pertanyaan.

Isi README:

Bagaimana cara berkontribusi
Pengembangan Internal
Rilis
Lisensi

Bagaimana cara berkontribusi

Kami sangat senang menerima dan menggabungkan kontribusi Anda ke dalam repositori ini!

Untuk berkontribusi melalui permintaan tarik, ikuti langkah-langkah berikut:

Buat masalah yang menjelaskan bug/perbaikan yang ingin Anda atasi atau atasi masalah yang ada di Jira
Ikuti panduan Permintaan Tarik kami: tulis kode, pengujian, dokumentasi, log perubahan, dan ikuti Gaya Kode kami
Buat permintaan tarik yang menjelaskan perubahan Anda

Untuk petunjuk lebih detail tentang cara menyumbangkan kode, lihat pedoman kontributor kode ini.

Anda dapat menemukan informasi lebih lanjut tentang cara berkontribusi pada Rasa (dalam berbagai cara!) di situs web kami..

Permintaan penarikan Anda akan ditinjau oleh pengelola, yang akan menghubungi Anda kembali jika ada perubahan atau pertanyaan yang diperlukan. Anda juga akan diminta untuk menandatangani Perjanjian Lisensi Kontributor.

Pengembangan Internal

Memasang Puisi

Rasa menggunakan Puisi untuk pengemasan dan manajemen ketergantungan. Jika ingin membangunnya dari sumber, Anda harus menginstal Puisi terlebih dahulu. Silakan ikuti panduan resmi untuk melihat semua opsi yang memungkinkan.

Untuk memperbarui versi puisi yang ada ke versi yang saat ini digunakan dalam rasa, jalankan:

    poetry self update < version >

Mengelola lingkungan

Panduan Puisi resmi menyarankan untuk menggunakan pyenv atau alat serupa lainnya untuk beralih antar versi Python dengan mudah. Inilah cara melakukannya:

pyenv install 3.10.10
pyenv local 3.10.10  # Activate Python 3.10.10 for the current project

Catatan : Jika Anda kesulitan menginstal versi python tertentu di sistem Anda, mungkin ada baiknya mencoba versi lain yang didukung.

Secara default, Puisi akan mencoba menggunakan versi Python yang saat ini diaktifkan untuk membuat lingkungan virtual untuk proyek saat ini secara otomatis. Anda juga dapat membuat dan mengaktifkan lingkungan virtual secara manual — dalam hal ini, Puisi harus mengambilnya dan menggunakannya untuk menginstal dependensi. Misalnya:

python -m venv .venv
source .venv/bin/activate

Anda dapat memastikan bahwa lingkungan diambil dengan mengeksekusi

poetry env info

Membangun dari sumber

Untuk menginstal dependensi dan rasa itu sendiri dalam mode yang dapat diedit, jalankan

make install

Catatan untuk pengguna macOS : pada macOS Big Sur kami melihat beberapa masalah kompiler untuk dependensi. Menggunakan export SYSTEM_VERSION_COMPAT=1 sebelum instalasi membantu.

Menginstal dependensi opsional

Untuk menginstal dependensi opsional rasa, Anda perlu menjalankan:

make install-full

Catatan untuk pengguna macOS : Perintah make install-full dapat mengakibatkan kegagalan saat menginstal tokenizers (masalah dijelaskan secara mendalam di sini).

Untuk mengatasinya, Anda harus mengikuti langkah-langkah berikut untuk menginstal kompiler Rust:

brew install rustup
rustup-init

Setelah menginisialisasi kompiler Rust, Anda harus me-restart konsol dan memeriksa instalasinya:

rustc --version

Jika variabel PATH belum diatur secara otomatis, jalankan:

 export PATH= " $HOME /.cargo/bin: $PATH "

Menjalankan dan mengubah dokumentasi

Pertama-tama, instal semua dependensi yang diperlukan:

make install install-docs

Setelah instalasi selesai, Anda dapat menjalankan dan melihat dokumentasi secara lokal menggunakan:

make livedocs

Ini akan membuka tab baru dengan versi lokal dokumen di browser Anda; jika tidak, kunjungi http://localhost:3000 di browser Anda. Anda sekarang dapat mengubah dokumen secara lokal dan halaman web akan secara otomatis memuat ulang dan menerapkan perubahan Anda.

Menjalankan Tes

Untuk menjalankan pengujian, pastikan Anda telah menginstal persyaratan pengembangan:

make prepare-tests-ubuntu # Only on Ubuntu and Debian based systems
make prepare-tests-macos  # Only on macOS

Kemudian, jalankan tes:

make test

Mereka juga dapat dijalankan di beberapa pekerjaan untuk menghemat waktu:

JOBS=[n] make test

Dimana [n] adalah jumlah pekerjaan yang diinginkan. Jika dihilangkan, [n] akan otomatis dipilih oleh pytest.

Menjalankan Tes Integrasi

Untuk menjalankan pengujian integrasi, pastikan Anda telah menginstal persyaratan pengembangan:

make prepare-tests-ubuntu # Only on Ubuntu and Debian based systems
make prepare-tests-macos  # Only on macOS

Kemudian, Anda harus memulai layanan dengan perintah berikut yang menggunakan Docker Compose:

make run-integration-containers

Terakhir, Anda dapat menjalankan pengujian integrasi seperti ini:

make test-integration

Menyelesaikan konflik penggabungan

Puisi tidak menyertakan solusi apa pun yang dapat membantu menyelesaikan konflik penggabungan di file kunci poetry.lock secara default. Namun, ada alat hebat yang disebut kunci penggabungan puisi. Inilah cara Anda menginstalnya:

pip install poetry-merge-lock

Jalankan saja perintah ini untuk menyelesaikan konflik penggabungan di poetry.lock secara otomatis:

poetry-merge-lock

Bangun image Docker secara lokal

Untuk membuat image Docker di mesin lokal Anda, jalankan perintah berikut:

make build-docker

Gambar Docker tersedia di mesin lokal Anda sebagai rasa:localdev .

Gaya Kode

Untuk memastikan gaya kode standar kami menggunakan formatter hitam. Untuk memastikan anotasi tipe kami benar, kami menggunakan pemeriksa tipe pytype. Jika kode Anda tidak diformat dengan benar atau tidak diketik, GitHub akan gagal dibuat.

Pemformatan

Jika Anda ingin memformat kode Anda secara otomatis pada setiap komit, Anda dapat menggunakan pra-komit. Instal saja melalui pip install pre-commit dan jalankan pre-commit install di folder root. Ini akan menambahkan hook ke repositori, yang memformat ulang file pada setiap komit.

Jika ingin mengaturnya secara manual, instal hitam melalui poetry install . Untuk memformat ulang file, jalankan

 make formatter

Pengecekan Tipe

Jika Anda ingin memeriksa tipe pada basis kode, instal mypy menggunakan poetry install . Untuk memeriksa jenis yang dijalankan

 make types

Menyebarkan pembaruan dokumentasi

Kami menggunakan Docusaurus v2 untuk membuat dokumen untuk versi yang diberi tag dan untuk cabang main . Untuk menjalankan Docusaurus, instal Node.js 12.x . Situs statis yang dibangun didorong ke cabang documentation repo ini.

Kami menghosting situs ini di netlify. Pada pembuatan cabang main (lihat .github/workflows/documentation.yml ), kami memasukkan dokumen yang dibuat ke cabang documentation . Netlify secara otomatis menyebarkan ulang halaman dokumen setiap kali ada perubahan pada cabang tersebut.

Rilis

Rasa telah menerapkan kebijakan kuat yang mengatur penamaan versi, serta kecepatan rilis untuk rilis mayor, minor, dan patch.

Nilai untuk nomor versi tertentu (MAJOR.MINOR.PATCH) bertambah sebagai berikut:

Versi UTAMA untuk perubahan API yang tidak kompatibel atau perubahan lain yang dapat menyebabkan gangguan.
Versi MINOR untuk fungsionalitas ditambahkan dengan cara yang kompatibel ke belakang.
Versi PATCH untuk perbaikan bug yang kompatibel dengan versi sebelumnya.

Tabel berikut menjelaskan tipe versi dan irama rilis yang diharapkan:

Jenis Versi	Keterangan	Irama Sasaran
Besar	Untuk perubahan signifikan, atau ketika ada perubahan yang tidak kompatibel dengan API atau model data.	Setiap 1 - 2 tahun
Kecil	Ketika fungsi baru yang kompatibel dengan versi sebelumnya diperkenalkan, fitur kecil diperkenalkan, atau ketika serangkaian fitur yang lebih kecil diluncurkan.	+/- Triwulanan
Tambalan	Untuk perbaikan bug yang kompatibel dengan versi sebelumnya yang memperbaiki perilaku yang salah.	Sesuai kebutuhan

Meskipun tabel ini mewakili target frekuensi rilis kami, kami berhak mengubahnya berdasarkan perubahan kondisi pasar dan persyaratan teknis.

Kebijakan Pemeliharaan

Kebijakan Akhir Masa Pakai kami menentukan berapa lama rilis tertentu dianggap didukung, serta berapa lama rilis dianggap masih dalam pengembangan atau pemeliharaan aktif.

Durasi pemeliharaan dan akhir masa pakai setiap rilis ditampilkan di situs web kami sebagai bagian dari Kebijakan Rilis dan Pemeliharaan Produk.

Memotong rilisan Major / Minor

Seminggu sebelum hari rilis

Pastikan pencapaiannya sudah ada dan dijadwalkan pada tanggal yang benar.
Lihatlah isu-isu & PR yang ada dalam pencapaian ini : apakah ini terlihat tepat untuk sorotan rilis yang kami rencanakan untuk dikirimkan? Apakah sepertinya ada sesuatu yang hilang? Jangan khawatir tentang mengetahui setiap PR yang harus dilakukan, namun ada gunanya meluangkan waktu sejenak untuk mengevaluasi apa yang ditugaskan pada pencapaian tersebut.
Posting pesan di saluran teknik Slack , beri tahu tim bahwa Andalah yang akan menghentikan rilis mendatang, serta:
1. Memberikan tautan ke pencapaian yang sesuai
2. Mengingatkan semua orang untuk membahas masalah dan PR mereka dan tolong tetapkan mereka ke pencapaian tersebut
3. Mengingatkan semua orang tentang tanggal rilis yang dijadwalkan

Sehari sebelum hari rilis

Tinjau pencapaian tersebut dan evaluasi status penggabungan PR yang sedang terjadi. Tindak lanjuti orang-orang tentang bug dan perbaikannya. Jika rilis ini menimbulkan bug atau regresi baru yang tidak dapat diperbaiki pada waktunya, kita harus mendiskusikan hal ini di Slack dan mengambil keputusan tentang cara untuk melanjutkan. Jika masalah belum siap untuk digabungkan pada waktunya, kami menghapus masalah/PR dari pencapaian dan memberi tahu pemilik PR dan manajer produk di Slack tentang hal tersebut. PR/pemilik isu bertanggung jawab untuk mengomunikasikan isu apa pun yang mungkin relevan dengan rilis. Menunda rilis harus dianggap sebagai skenario kasus yang luar biasa.

Hari rilis!

Di awal hari, posting pesan kecil di slack yang mengumumkan hari rilis! Komunikasikan bahwa Anda akan menangani rilis tersebut, dan waktu yang ingin Anda mulai rilis (sekali lagi, paling lambat jam 4 sore, karena masalah mungkin timbul dan menyebabkan penundaan). Pesan ini harus diposting pagi-pagi sekali dan sebelum melanjutkan langkah-langkah rilis apa pun, untuk memberikan cukup waktu kepada orang-orang untuk memeriksa PR dan isu-isu mereka. Dengan begitu mereka dapat merencanakan pekerjaan yang tersisa. Templat pesan slack dapat ditemukan di sini. Waktu pelepasan harus dikomunikasikan secara transparan sehingga pihak lain dapat merencanakan langkah-langkah yang mungkin diperlukan. Jika ada perubahan yang lebih besar, hal ini harus dikomunikasikan.
Pastikan pencapaian tersebut kosong (semuanya telah digabungkan atau dipindahkan ke pencapaian berikutnya)
Setelah semua hal dalam tonggak sejarah diselesaikan, posting pesan kecil di Slack yang memberitahukan bahwa Anda akan memulai proses rilis (jika ada yang hilang).
Anda sekarang dapat melakukan rilis dengan mengikuti instruksi yang diuraikan dalam README Open Source Rasa!

Setelah rilis besar

Setelah rilis Major selesai, ikuti petunjuk berikut untuk menyelesaikan pembaruan dokumentasi.

Langkah-langkah untuk merilis versi baru

Merilis versi baru cukup sederhana, karena paket dibuat dan didistribusikan oleh GitHub Actions.

Langkah-langkah rilis :

Pastikan semua dependensi sudah diperbarui ( terutama Rasa SDK )
- Untuk Rasa SDK, kecuali dalam kasus rilis patch, itu berarti membuat rilis Rasa SDK baru terlebih dahulu (pastikan nomor versi antara rilis Rasa baru dan Rasa SDK cocok)
- Setelah tag dengan rilis Rasa SDK baru didorong dan paket muncul di pypi, ketergantungan pada repositori rasa dapat diselesaikan (lihat di bawah).
Jika ini adalah rilis minor/mayor: Pastikan semua perbaikan dari versi minor yang saat ini didukung telah digabungkan dari cabang rilis masing-masing (misalnya 3.3.x) kembali ke rilis utama.
Jika rilis kecil, buat cabang baru yang sesuai dengan rilis baru, misalnya
```
 git checkout -b 1.2.x
 git push origin 1.2.x
```
Beralih ke cabang tempat Anda ingin menghentikan rilisnya ( main jika mayor, cabang <major>.<minor>.x untuk minor dan patch)
- Perbarui entri rasa-sdk di pyproject.toml dengan versi rilis baru dan jalankan poetry update . Ini membuat file poetry.lock baru dengan semua dependensi teratasi.
- Komit perubahan dengan git commit -am "bump rasa-sdk dependency" tetapi jangan memaksakannya. Mereka akan diambil secara otomatis pada langkah berikut.
Jika ini adalah rilis besar, perbarui daftar versi yang dikelola secara aktif di README dan dokumen.
Jalankan make release
Buat PR terhadap cabang rilis (misalnya 1.2.x )
Setelah PR Anda digabungkan, tandai rilis baru (ini HARUS selalu terjadi di cabang rilis), misalnya menggunakan
```
git checkout 1.2.x
git pull origin 1.2.x
git tag 1.2.0 -m " next release "
git push origin 1.2.0 --tags
```
GitHub akan membuat tag ini dan memublikasikan artefak build.
Setelah semua langkah selesai dan jika semuanya berjalan dengan baik maka kita akan melihat pesan yang secara otomatis diposting di Slack (saluran product ) perusahaan seperti ini
Jika tidak ada pesan yang muncul di saluran maka Anda dapat melakukan pemeriksaan berikut:
- Periksa alur kerja di Github Actions dan pastikan PR gabungan dari rilis saat ini berhasil diselesaikan. Untuk menemukan PR Anda dengan mudah, Anda dapat menggunakan event: push dan branch: <version number> (contoh pada rilis 2.4 dapat Anda lihat di sini)
- Jika alur kerja tidak selesai, coba jalankan kembali alur kerja jika hal tersebut dapat menyelesaikan masalah
- Jika masalah masih berlanjut, periksa juga file log dan coba temukan akar penyebab masalahnya
- Jika Anda masih tidak dapat mengatasi kesalahan tersebut, hubungi tim infrastruktur dengan memberikan informasi bermanfaat dari penyelidikan Anda
Setelah pesan terposting dengan benar di product channel, cek juga di product-engineering-alerts channel apakah ada alert terkait rilis Rasa Open Source seperti ini

Memotong rilis Patch

Rilis patch lebih mudah untuk dihentikan, karena dimaksudkan hanya berisi perbaikan bug.

Satu-satunya hal yang perlu Anda lakukan untuk menghentikan rilis patch adalah:

Beri tahu tim teknik di Slack bahwa Anda berencana untuk menghentikan patch, jika ada orang yang memiliki perbaikan penting untuk ditambahkan.
Pastikan perbaikan bug ada di cabang rilis yang akan Anda gunakan (jika Anda memotong patch 2.0.4 , Anda memerlukan perbaikan di cabang rilis 2.0.x ). Semua rilis patch harus berasal dari cabang .x !
Setelah Anda siap untuk merilis patch Rasa Open Source, periksa cabangnya, jalankan make release dan ikuti langkah-langkahnya + gabungkan PR.
Setelah PR masuk, tarik kembali cabang .x dan tekan tag!

Tugas Rilis Tambahan

Catatan: Ini hanya diperlukan jika versi yang dirilis adalah versi tertinggi yang tersedia. Misalnya, lakukan langkah-langkah berikut ketika version > version di main.

Untuk memeriksa kompatibilitas antara versi Rasa yang baru dirilis dengan Rasa X/Enterprise versi terbaru, kami melakukan langkah-langkah berikut:

Setelah rilis Rasa baru, permintaan penarikan otomatis dibuat di Rasa-X-Demo.
Setelah PR di atas digabungkan, ikuti instruksi di sini, untuk merilis versi.
Perbarui versi baru di file env Rasa X/Enterprise. Proyek Rasa-X-Demo menggunakan versi Rasa baru yang diperbarui untuk melatih dan menguji model yang selanjutnya digunakan oleh CI kami untuk menjalankan pengujian di repositori Rasa X/Enterprise, sehingga memvalidasi kompatibilitas antara Rasa dan Rasa X/Enterprise.