Robot perdagangan DIY: lebih detail, lebih banyak nuansa

Data apa yang harus diambil di awal

Pada awalnya, Anda memiliki tiga kelas utama data pasar yang dapat diterima dari bursa melalui API. Yang paling mudah dipahami dan umum adalah Lilin OHLCV: Buka/Tinggi/Rendah/Tutup ditambah volume per interval. Ini adalah representasi harga yang “terkompresi”, yang mudah disimpan, di-cache, dan ditransfer ke model sebagai konteks yang stabil (misalnya, N candle terakhir dalam jangka waktu yang dipilih¹).

Jika Anda ingin melihat apa yang terjadi di dalam candle, hubungkan trades tape (trades / tape) - aliran eksekusi aktual: harga, kuantitas, waktu (terkadang sisi). Lapisan ini menambahkan detail pada aktivitas dan impuls dan biasanya digunakan sebagai sumber yang lebih berbintik dibandingkan kandil.

Opsi ketiga adalah buku pesanan (buku pesanan): tingkat dan volume tawaran/minta di setiap tingkat. Ini adalah data tentang struktur mikro dan likuiditas: bukan “apa yang terjadi”, namun “apa yang terjadi saat ini.” Hal ini biasanya dianggap sebagai lapisan konteks terpisah jika perlu mempertimbangkan kedalaman pasar, ketidakseimbangan pasokan/permintaan, dan reaksi terhadap level.

Untuk saat ini, mari fokus pada opsi paling sederhana - candle OHLCV. Dalam penerapannya, Anda dapat menambahkan transaksi dan buku pesanan, namun tujuan artikel ini adalah untuk tujuan informasi dan pendidikan: untuk menyusun kerangka kerja yang jelas dan tidak terpaku pada detail.

Format dan riwayat data terpadu

Segera setelah Anda mulai mendapatkan kutipan dari lebih dari satu tempat, kenyataan yang tidak menyenangkan muncul: sumber berbeda menyediakan data yang sama dalam format berbeda. Di suatu tempat lilin adalah serangkaian angka, di suatu tempat objek dengan bidang, di suatu tempat waktu dalam milidetik, di suatu tempat dalam detik, dan nama serta urutan bidang mungkin berbeda bahkan untuk API yang “serupa”...

Jika Anda tidak memperkenalkan format terpadu di pihak Anda, sistem dengan cepat berubah menjadi seperangkat kruk: setiap sumber baru membawa serta parser, pengecualian, dan “kasus khusus” yang terpisah. Oleh karena itu, modul untuk mendapatkan penawaran hampir selalu memerlukan format internal yang umum - minimal cukup untuk analisis lebih lanjut. Untuk level kita saat ini, biasanya berupa: instrumen, jangka waktu¹, stempel waktu², Terbuka/Tinggi/Rendah/Tutup dan Volume.

Kita juga harus membicarakan data historis. “Keadaan pasar saat ini” memang bagus, namun tanpa sejarah Anda tidak akan dapat memperluas analisis, menguji hipotesis, atau bahkan menjelaskan dengan tepat kepada pengguna mengapa sinyal terlihat seperti itu. Oleh karena itu, bahkan dalam implementasi yang sederhana, masuk akal untuk menyimpan riwayat candle (atau dapat memuatnya dengan cepat) dan mencatat data apa yang menjadi dasar sinyal tertentu.

Batas kapasitas: mengapa ini penting

Hampir setiap bursa memiliki batasan pada frekuensi permintaan - batas nilai. Alasannya sederhana: jika Anda membiarkan semua klien “berkedut” kutipan tanpa henti, API akan mogok bahkan tanpa DDoS.

Dalam konteks seorang penasihat, hal ini sangatlah penting. Permintaan tidak dieksekusi terus-menerus, tetapi berdasarkan pengatur waktu - dan jika Anda salah memilih frekuensi atau mengalikannya dengan jumlah instrumen, Anda akan segera mencapai batasnya. Hasilnya biasanya sama: 429/larangan kesalahan per kunci, lubang pada data, dan “keheningan” sistem tepat pada saat pasar sedang bergerak paling pesat.

Pendekatan kerja di sini bersifat pragmatis: hitung anggaran permintaan terlebih dahulu (frekuensi × alat × jenis data), simpan hasilnya dalam cache, jangan meminta hal yang sama dua kali, dan tangani batasan dengan benar (mundur/ulangi setelah jeda, bukan permintaan spam).

Jaringan prompt dan neural: API yang sama, aturan berbeda

Kami telah menyelesaikan akuisisi data - sekarang kami dapat melanjutkan ke tingkat berikutnya: perintah dan bekerja dengan jaringan neural.

Pada pandangan pertama, ini sangat mirip dengan meminta penawaran: lagi-lagi API, lagi-lagi pembatasan frekuensi, sekali lagi Anda perlu memikirkan tentang percobaan ulang, batas waktu, dan cache. Hanya saja, alih-alih “beri saya lilin”, Anda malah mendapat permintaan seperti “ini datanya, ini konteksnya, kembalikan sinyal dan penjelasannya.”

Kemudian perbedaan dimulai.. Sebagai pertukaran, jawabannya adalah struktur data; bagi sebuah model, itu adalah hasil interpretasi. Oleh karena itu, perintah menjadi sebuah kontrak, dan bukan sekadar “teks”, dan harus diperlakukan dengan cara yang sama seperti format data: berversi, diperiksa, dibatasi, dan dicatat.

Momen yang sangat menyederhanakan kehidupan selama integrasi: dalam prompt Anda dapat memperbaiki terlebih dahulu struktur responsnya. Misalnya, minta model untuk mengembalikan hasilnya secara ketat dalam JSON - dengan kolom seperti sinyal, keyakinan, dan alasan. Ini bukan hal yang “ajaib”, namun setidaknya mendisiplinkan format, dan di sisi aplikasi, hal ini memungkinkan penguraian dan validasi respons secara otomatis alih-alih mengurai teks bebas.

MCP (Model Context Protocol) patut mendapat perhatian khusus: ini adalah pendekatan/protokol yang membantu menstandardisasi cara model menerima konteks dan cara sumber data eksternal serta alat terhubung. Meskipun saat ini Anda menggunakan panggilan langsung ke API tertentu, mempertimbangkan lapisan seperti MCP akan berguna - lapisan ini mendisiplinkan arsitektur dan mempermudah ekstensibilitas.

Dan ya, di masa depan, “analis” tidak harus berupa layanan eksternal. Jika sumber daya dan motivasi muncul, modul ini dapat diganti dengan model Anda sendiri (atau model sumber terbuka yang telah dilatih sebelumnya) tanpa harus menulis ulang seluruh sistem - asalkan antarmuka pada awalnya dipisahkan dengan benar.

Penyimpanan: lebih mudah dari kelihatannya

Pada tahap ini, kita sudah memiliki setidaknya dua “array” data: candle pasar dan hasil analisis. Dan jika Anda melihat ke depan, riwayat berita (dan ringkasannya) akan ditambahkan, ditambah menyimpan permintaan/tanggapan model untuk proses debug dan analisis ulang. Dengan kata lain, terdapat cukup banyak data, dan muncul di berbagai tempat dalam pipeline.

Oleh karena itu, masuk akal untuk memikirkan penyimpanan terpadu terlebih dahulu. Kekhususan data tersebut sering kali membuat skema SQL yang lengkap tidak dapat diperpanjang: dalam banyak kasus, database yang tertanam dan pendekatan nilai kunci yang sederhana sudah cukup.

Penyimpanan KV (nilai kunci) adalah model tempat data disimpan sebagai pasangan “kunci → nilai”: dengan menggunakan kunci, Anda dapat dengan cepat mengambil objek yang diinginkan (misalnya, candle untuk instrumen dan jangka waktu¹ untuk suatu periode, atau hasil analisis untuk permintaan tertentu)..

Antarmuka: antarmuka minimum yang tanpanya penasihat tidak akan berguna

Dan yang terakhir - antarmuka. Kami tidak akan membahas UI/UX saat ini, namun izinkan saya mengingatkan Anda tentang ide dasar dari bagian pertama: minimal, Anda memerlukan antarmuka web, dan sebagai tambahan yang bagus, notifikasi di Telegram.

Secara praktis, pengguna hanya memerlukan beberapa hal. Pertama, lihat sinyal dan peringatan terkini (dan pahami dengan cepat apa yang “terjadi saat ini”). Kedua, dapat meminta analisis sesuai permintaan - dapatkan data dan sinyal terbaru dalam satu klik. Dan ketiga, konfigurasikan sistem: pilih alat dan sumber data, kelola kunci API, dan - yang penting - edit perintah dan parameter analisis tanpa perlu memasukkan kode.

Inti: “cincin” yang menghubungkan segalanya

Tolkien memiliki “satu cincin untuk mengatur semuanya... dan mengikat mereka dalam kegelapan.” Arsitektur penasihat juga memiliki lingkaran ini - hanya saja tanpa kesedihan: inti sistem, yang menyatukan semua modul.

Kernel tidak bertanggung jawab atas analisis tersebut, namun bertanggung jawab atas siklus hidup: memulai/menghentikan aplikasi, inisialisasi ketergantungan, penjadwal tugas, perutean permintaan (sesuai permintaan dan jadwal), dan pematian yang benar. Di sinilah diputuskan apa yang diluncurkan dan kapan, di mana data ditulis, dan bagaimana komponen berkomunikasi satu sama lain tanpa menjadi kusut.

Jika Anda ingin menambahkan sumber kutipan baru, mengubah penyedia LLM, menghubungkan berita dan tidak menulis ulang semuanya setiap saat, intinya harus sederhana namun ketat: modul - berdasarkan antarmuka, ketergantungan - secara eksplisit, konfigurasi - terpusat, dan siklus hidup - dapat diprediksi.

Pada titik ini Anda dapat berhenti dan dengan jujur mengatakan: “kerangka” penasihat sudah terlihat. Data tiba, prompt dikumpulkan, model merespons, hasilnya disimpan dan ditampilkan kepada pengguna - dan semua ini bergantung pada kernel, yang mengelola siklus hidup. Pada artikel berikutnya saya akan turun satu tingkat: kita akan melihat detail teknis penerapannya - seperti apa antarmuka sumber kutipan yang terpadu, cara mengatur cache dan baki ulang, tempat menyimpan riwayat, cara memvalidasi respons model (termasuk format JSON), dan apa yang harus dilakukan agar sistem tidak rusak karena batasan, waktu, dan kesalahan "jarang"..

Catatan Kaki

1. Timeframe adalah durasi satu candle (interval agregasi data): misalnya 1m, 5m, 1h, 1d. Ini menentukan dengan tepat bagaimana aliran harga di OHLCV “dikompresi”.
2. Stempel waktu adalah stempel waktu (biasanya dalam UTC) yang dikaitkan dengan candle/perdagangan. Kesalahan klasik: mencampuradukkan detik dan milidetik (atau waktu lokal dan UTC), setelah itu data “bergeser” dan analisisnya terhenti.