Poll jawaban baru di chat lama Qwen tanpa dapat yang basi
Pola record-then-poll di tools qwen-article: rekam jawaban lama sebelum kirim instruksi, poll sampai muncul jawaban baru yang bener-bener beda.
Ringkasan
Otomasi chat UI sempat mengambil jawaban lama dari clipboard karena proses generasi model belum selesai. Solusinya pola record-then-poll: rekam jawaban lama sebagai baseline, beri jeda 25 detik, lalu poll tiap 15 detik sampai teks berubah. Pola ini mencegah sukses yang salah dan membuat pipeline artikel otomatis jadi lebih tangguh.
Pertama kali saya coba menerjemahkan artikel bahasa Inggris lewat chat Qwen yang sama, hasil yang tertarik skrip malah artikel bahasa Indonesia yang lama, bukan terjemahan segar yang saya minta. Saat itu saya sedang membangun pipeline artikel otomatis di adityo.web.id, dan ekspektasinya gampang. Alurnya seharusnya berjalan mulus: kirim prompt terjemahan, tunggu sebentar, lalu ambil hasilnya untuk diproses lebih lanjut. Nyatanya, yang kebaca teks lama yang sama sekali nggak nyambung sama permintaan baru. Seluruh rantai otomasi jalan di atas data yang salah.
Awalnya saya langsung curiga prompt terjemahan saya kurang jelas. Saya coba macem-macem variasi kalimat perintah, mulai dari "abaikan konteks sebelumnya" sampe "terjemahkan baris demi baris secara ketat tanpa tambahan penjelasan". Setelah diuji beberapa kali beberapa kali, ternyata masalahnya bukan pada kalimat perintah saya. Masalah utamanya di sumber jawaban yang diambil sistem. Tool yang saya pakai menarik teks jawaban langsung dari clipboard halaman chat. Karena proses generasi teks butuh waktu, clipboard di halaman itu belum berganti. Alhasil, yang kebaca skrip tetap jawaban lama. Kayak permintaan baru diabaikan total.
Dugaan yang Meleset dan Temuan di Lapangan
Kirim instruksi ke chat lama itu beda kasus dengan kirim prompt baru di sesi segar. Konteksnya udah panjang, generasinya lebih lama, dan state clipboard basi sebelum sempat di-update antarmuka. Solusi yang akhirnya konsisten jalan: pola record-then-poll.
Sebelum mengirim instruksi baru ke dalam chat, jawaban lama direkam dulu jadi titik acuan. Dilakukan maksimal 3 percobaan rekam biar state awalnya stabil, nggak kebaca pas halaman masih loading setengah. Setelah instruksi kekirim, sistem jeda 25 detik tanpa baca apa pun dari layar. Jeda ini penting banget biar proses generasi di sisi server benar-benar mulai dan elemen UI mulai berubah lumayan jelas.
Baru setelah itu poll dimulai. Jawaban baru cuma diterima kalau isinya beda dari rekaman lama. Supaya nggak berat di sisi server, sistem poll tiap 15 detik. Timeout defaultnya 480 detik, kasih waktu cukup buat model nyelesain artikel panjang tanpa buru-buru nyatakan gagal. Biar bersih, tab browser juga sengaja ditutup di blok finally supaya nggak bocor tab meski terjadi error di tengah jalan eksekusi, biar tab nggak numpuk.
Mengapa Pola Record-Then-Poll Masuk Akal
Pada dasarnya ini teknik dedup jawaban alias answer anchoring buat otomasi chat UI. Pas interaksi sama antarmuka web bukan API resmi, halamannya harus diperlakukan sebagai lingkungan yang stateful, bukan endpoint yang langsung membalas. Tanpa rekaman awal, tool nggak punya cara andal buat bedain jawaban lama dan baru.
Risiko terbesarnya bukan gagal dapet respons atau timeout. Risiko yang jauh lebih berbahaya adalah sukses yang salah. Maksudnya: sistem sukses ngambil teks, tapi itu jawaban basi, dan sistem ngira itu hasil baru yang valid. Data yang masuk ke pipeline rusak tanpa notifikasi error yang jelas. Ini jauh lebih susah dilacak daripada error yang kelihatan.
Kayak nunggu air mendidih: kalau tutup pancinya dibuka tiap dua detik, yang keliatan ya air yang belum mendidih, terus kita nyimpulin kompornya rusak. Jeda 25 detik itu ibarat kasih waktu airnya benar-benar mendidih dulu sebelum dicek. Poll tiap 15 detik setelahnya cara efisien pantau tanpa ganggu proses. Ini filosofi dasar otomasi yang stabil: hargai waktu proses sistem, jangan maksa dengan pembacaan agresif.
Kasus translate artikel ini cuma pemakaian default-nya. Pola ini generik, bisa dipakai buat instruksi lanjutan apa pun di chat yang sama: minta ringkasan, revisi nada bahasa, atau ekstraksi data. Mekanisme ini jadi tulang punggung pas saya integrasikan lane engine qwen di cron buang jawaban tetap hidup saat LLM mati atau latency-nya tinggi, karena sistem nggak maksa baca state yang belum valid.
Otomasi yang baik bukan soal seberapa cepat maksa mesin kerja, tapi seberapa paham baca tanda kesiapan sistemnya. Dengan ini, pipeline artikel otomatis jadi jauh lebih tahan banting dan minim false positive.