Baru-baru ini, seorang kenalan mendekati saya - dia memperdagangkan kripto pada tingkat amatir - dan meminta saya untuk “menulis robot perdagangan.” Penting untuk fokus pada terminologi di sini. Dalam percakapan, semua ini disebut robot, namun dalam praktiknya, penasihat perdagangan sering kali dibutuhkan
Penasihat menganalisis pasar dan memberikan rekomendasi: tempat untuk masuk, tempat untuk berhenti, tempat yang lebih baik untuk tidak melakukan apa pun.
Robot mengambil langkah berikutnya untuk Anda - dan membuka/menutup posisi sendiri.
Dan itulah mengapa “ayo kita segera beli robot” biasanya merupakan ide yang buruk. Sampai algoritme di-debug, risiko kehilangan uang adalah maksimum: kesalahan dalam analisis, bug dalam logika, pemrosesan candle/order yang salah - dan robot akan dengan tenang melakukan apa yang tidak akan Anda lakukan dengan tangan.
Oleh karena itu, strategi yang masuk akal hampir selalu sama: pertama penasihat (analisis + sinyal), kemudian otomatisasi eksekusi, dan hanya jika terdapat statistik dan pengendalian risiko.
Tentang artikel ini: arsitektur penasihat perdagangan
Dalam artikel ini - tanpa “sinyal jutaan dolar” dan tanpa janji profitabilitas - yang ada hanyalah sebuah teori: terbuat dari apa penasihat perdagangan, seperti apa arsitekturnya, dan mengapa batasan tanggung jawab penting di dalamnya.
Kami tidak mendalami algoritme analisis - tujuan artikel ini berbeda: untuk menunjukkan komponen apa yang biasanya dimiliki seorang penasihat dan bagaimana komponen tersebut cocok satu sama lain.
Saat ini, layanan LLM siap pakai sering dipilih sebagai “otak” yang menafsirkan data dan merumuskan kesimpulan: ChatGPT, Gemini, Grok. Jika diinginkan, model tersebut dapat dilatih lebih lanjut atau diganti dengan model Anda sendiri, namun untuk arsitektur, hal ini bersifat sekunder.
Nuansanya tetap sama: jaringan saraf tidak membaca pikiran Anda. Dia memerlukan perintah - jelas, formal, dan dapat diulang.
Prompt adalah instruksi teks (dan konteks) yang Anda teruskan ke model: jenis data apa yang ada di depan Anda, apa sebenarnya yang perlu dilakukan, dan dalam format apa untuk mengembalikan respons.
Dan kami juga membutuhkan data yang akan kami gunakan.
Pertanyaan utama di sini adalah: apa sebenarnya yang harus dimasukkan ke dalam prompt (candle, indikator, buku pesanan, transaksi, konteks risiko) dan dalam bentuk apa.
Data dan API
Kita akan membicarakan perintahnya nanti, tapi sekarang tentang datanya.
Tingkat awal terlihat sederhana:
- Dapatkan data tarif (kutipan).
- Kumpulkan dengan konteks permintaan.
- Teruskan ini ke perintah jaringan saraf - melalui API yang sama.
Hampir semua bursa menyediakan akses ke kutipan secara terprogram. Dan ya - juga melalui API..
Mari kita ngelantur sejenak dan memahami apa yang kita sebut API, karena kata tersebut sudah muncul beberapa kali dan akan terus muncul terus-menerus.
API (Application Programming Interface) adalah antarmuka untuk interaksi antar program.
Dalam praktiknya, berikut adalah “aturan mainnya”:
- permintaan apa yang dapat dibuat (misalnya: dapatkan lilin, dapatkan buku pesanan);
- dalam format apa data akan dikirim (seringkali JSON);
- seperti apa responsnya (struktur bidang, kesalahan, batasan, otorisasi).
Sederhananya: API memungkinkan Anda menggunakan kemampuan pertukaran (atau jaringan neural) sebagai serangkaian fungsi, tanpa perlu melakukan implementasi.
Lapisan khusus: cara menampilkan hasilnya
Jadi, pada tahap ini kita sudah memiliki dua komponen dasar:
- data (kami ambil dari bursa);
- analis (jaringan saraf tempat kami memasukkan data dan menerima keluaran/sinyal).
Tetapi aplikasi yang menerima data dan menganalisisnya sendiri tidak ada gunanya sampai seseorang melihat hasilnya.
Jadi kita memerlukan komponen ketiga - sebuah antarmuka.
Opsi paling sederhana dan universal adalah antarmuka web: grafik, sinyal terbaru, penjelasan “mengapa demikian”, pengaturan risiko.
Sebagai opsi - notifikasi di pesan instan (misalnya, Telegram): sinyal pendek + tautan ke detail di web.
Konteks melebihi harga: berita
Untuk versi dasar saja sudah cukup, namun jika ingin lebih mendalami, Anda dapat menambahkan lapisan konteks lain: berita.
Idenya sederhana: kami mengumpulkan artikel berita yang relevan dan menambahkannya ke prompt. Biasanya - bukan “bahan mentah”, tetapi dalam bentuk ringkasan singkat (agar tidak menyumbat konteks dan tidak tersesat).
Ini bukan bagian wajib dari arsitektur, namun dalam beberapa mode, ini meningkatkan kualitas saran secara signifikan: model mulai mempertimbangkan alasan pergerakan, dan bukan hanya bentuk grafik.
Cara menyatukan semuanya
Oke, modulnya jelas. Pertanyaan praktisnya sekarang adalah: bagaimana merakitnya menjadi satu aplikasi.
Dalam praktiknya, Anda hampir selalu mendapatkan dua mode..
Analisis sesuai permintaan
Pengguna menekan tombol (atau menarik titik akhir) → kami menarik tanda kutip terbaru → mengumpulkan perintah → menerima respons model → menunjukkan sinyal.
- Kelebihan: ekonomis dalam hal token/sumber daya, lebih mudah untuk di-debug.
- Kekurangan: Anda dijamin akan melewatkan beberapa acara di antara permintaan - titik masuk juga akan terlewatkan.
Analisis rutin sesuai jadwal
Pengguna mengatur frekuensi (misalnya, setiap 5 menit/jam/hari sekali) → sistem itu sendiri yang menjalankan konveyor dan menampilkan hasilnya.
- Kelebihan: sinyal datang secara teratur, Anda dapat menjaga “denyut pasar”, lebih mudah mengumpulkan statistik.
- Kekurangan: lebih mahal (token/infrastruktur), Anda memerlukan batasan dan perlindungan dari “panah silang” (batas kecepatan, retray, deduplikasi sinyal), ditambah pemantauan dan pencatatan diperlukan - jika tidak, Anda tidak akan mengerti mengapa pada pukul 03:17 semuanya tiba-tiba menjadi sunyi.
Dalam mode mana pun, kumpulan komponen dasarnya sama:
- server web (antarmuka dan API untuk pengguna);
- modul pertukaran data (kutipan, candle, jika perlu - buku pesanan/transaksi);
- Modul LLM (kumpulan perintah → memanggil model → menguraikan respons);
- penyimpanan (setelan pengguna, riwayat sinyal, cache penawaran, hasil analisis).
Dan perlu ada satu “perekat” yang menyatukan semuanya: entitas tingkat aplikasi—sebut saja inti/layanan—yang mengelola dependensi, siklus hidup, dan skrip (sesuai permintaan atau terjadwal).
Untuk masa depan, menggunakan pendekatan plugin hampir selalu bermanfaat:
- plugin untuk sumber penawaran (kami menambahkan bursa baru - kami tidak menulis ulang sisanya);
- plugin untuk penyedia LLM (model baru telah muncul / tarif telah berubah - kami mengubah adaptornya, bukan arsitekturnya).
Catatan: Diagram arsitektur (diagram) direncanakan di sini - sengaja tidak disertakan dalam versi HTML ini.
Kemudian Anda dapat mulai menerapkan: antarmuka apa yang dimiliki modul, struktur data apa, dan di mana batas antara “penasihat” dan “robot perdagangan”?
Berdasarkan materi dari itprolab.dev
Baca juga
Robot perdagangan DIY: lebih detail, lebih banyak nuansa
Pada bagian pertama, kita menguji ide dasarnya: penasihat perdagangan bukanlah “robot yang melakukan perdagangan untuk Anda”, namun sebuah sistem yang menerima data pasar, menghasilkan sinyal (dan penjelasan), dan menunjukkan hasilnya kepada seseorang.
Kami menerima pembayaran dalam bitcoin: Bagian enam. Nuansa, sekali lagi nuansa
Di bagian terakhir, kami menunjukkan bahwa bukanlah ide yang buruk untuk mencari tahu fakta pembayaran dari bitcoind, daripada melalui semua alamat yang dikeluarkan.
