Pelajaran Setelah Memproses 500 Juta Token GPT

• Selama 6 bulan terakhir, Truss mengoperasikan beberapa fitur berpusat pada LLM dan memproses lebih dari 500 juta token dengan model OpenAI, lalu merangkum batasan-batasan yang benar-benar mereka hadapi dalam peringkasan, analisis, dan ekstraksi teks B2B
• Prompt tidak makin stabil hanya karena diberi banyak instruksi terperinci; untuk pengetahuan umum yang sudah diketahui GPT, instruksi yang lebih singkat dan kurang spesifik kadang menghasilkan keluaran yang lebih baik
• Tanpa Langchain, JSON mode, function calling, atau assistants, mereka mengoperasikan berbagai fitur hanya dengan API chat dan satu fungsi ekstraksi JSON; kode intinya hanya berupa fungsi 40 baris ditambah penanganan error dan pemotongan otomatis
• GPT lemah dalam menangani hipotesis nol (null hypothesis) seperti “jika tidak ada, kembalikan nilai kosong” dan dalam output panjang; terlepas dari jendela input 128k GPT-4, output tetap berada di kisaran 4k
• RAG dan vector DB tidak cocok untuk pekerjaan ekstraksi teks Truss yang terbatas; analisis, peringkasan, dan ekstraksi dengan seluruh konteks memang sangat andal, tetapi masalah menjadi besar saat input kosong atau tidak ada informasi yang relevan

---

Cakupan penggunaan dan asumsi

• Selama 6 bulan terakhir, Truss meluncurkan beberapa fitur berpusat pada LLM, dengan penggunaan yang diperkirakan sedikit di atas 500 juta token
• Model yang digunakan adalah keluarga OpenAI, dengan penggunaan token GPT-4 85% dan GPT-3.5 15%
• Data yang ditangani hanya teks; fitur non-teks seperti gpt-4-vision, Sora, dan Whisper tidak termasuk
• Konteks produknya B2B, dan tugas utamanya adalah peringkasan, analisis, dan ekstraksi
• 500 juta token setara dengan sekitar 750 ribu halaman teks

Prompt bisa menjadi lebih baik saat kurang spesifik

• Untuk pengetahuan umum yang sudah diketahui GPT, memasukkan daftar dan instruksi yang terlalu rinci justru dapat memperburuk hasil
• Salah satu pipeline harus mengklasifikasikan apakah sebuah blok teks terkait dengan salah satu dari 50 negara bagian AS atau pemerintah federal
  • Prompt awal memasukkan daftar ID untuk 50 negara bagian dan federal dalam format JSON pada field locality_id, lalu meminta model memilih salah satunya
  • Cara ini berhasil sekitar lebih dari 98%, tetapi jumlah kegagalannya cukup banyak sehingga perlu investigasi tambahan
• Field lain, name, tidak diminta secara eksplisit, tetapi model secara stabil mengembalikan nama lengkap negara bagian yang benar
  • Setelah itu, mereka mengubah pendekatan menjadi mencari negara bagian berdasarkan string yang muncul di name, dan cara ini bekerja dengan baik
• Pendekatan yang lebih baik adalah prompt yang menyerahkan pada pengetahuan umum, seperti “Anda tahu 50 negara bagian, jadi kembalikan nama lengkap negara bagian tersebut atau Federal”
• Ada juga pengamatan tambahan
  • Kegagalan lebih sering muncul pada negara bagian yang dimulai dengan huruf M, seperti Maryland, Maine, Massachusetts, dan Michigan
  • Saat meminta model memilih ID dari daftar, JSON yang mudah dibaca dengan setiap negara bagian di baris tersendiri tidak terlalu membingungkan dibanding daftar yang dipisahkan koma

API dan abstraksi dijaga tetap sederhana

• Dalam kasus ini, Langchain lebih mendekati abstraksi prematur, dan bahkan setelah jutaan token serta 3–4 fitur produksi yang beragam, file openai_service hanya menyisakan satu fungsi 40 baris
• API yang benar-benar digunakan hanyalah chat
  • Selalu mengekstrak JSON
  • JSON mode, function calling, dan assistants tidak diperlukan
  • System prompt juga tidak digunakan
  • Saat gpt-4-turbo dirilis, mereka hanya mengubah satu string di codebase
• Sebagian besar fungsi menangani error seperti 500 error dari OpenAI API atau socket yang tertutup
  • Error semacam ini sudah membaik, dan menurut mereka tidak mengejutkan mengingat beban OpenAI
• Batas panjang konteks ditangani dengan pemotongan otomatis sendiri
  • Jika panjang string lebih besar dari model_context_size * 3, string dipotong
  • Saat ada sangat banyak tanda titik atau angka, rasio token bisa menjadi kurang dari 1 token per 3 karakter, sehingga dapat gagal
  • Jika muncul context_length_exceeded, string dipotong ulang dengan patokan model_context_size * 3 / 1.3 lalu dicoba lagi

UX streaming sulit diremehkan

• Cara mengurangi latensi dengan streaming API dan menampilkan kepada pengguna karakter yang muncul dengan kecepatan bervariasi awalnya terlihat seperti gimmick
• Dalam penggunaan nyata, pengguna menerima tampilan “mengetik” dengan kecepatan bervariasi dengan sangat positif
• Pengalaman ini terasa seperti momen mouse/kursor UX dalam AI

Hasil kosong dan output panjang adalah kelemahan

• “Jika tidak ditemukan, kembalikan output kosong” hampir menjadi frasa prompt yang paling sering memicu error
  • Maksudnya bukan benar-benar tidak mengeluarkan apa pun, melainkan mengembalikan representasi nilai kosong seperti {value: ""}
  • Masalahnya bukan kegagalan batas output, melainkan lebih dekat pada kesulitan menentukan hipotesis nol itu sendiri
• Saat seharusnya mengembalikan nilai kosong, GPT kadang memilih berhalusinasi; sebaliknya, kadang kepercayaan dirinya turun dan terlalu sering mengembalikan nilai kosong
• Saat ada bug yang memungkinkan blok teks kosong, halusinasi terjadi parah
  • Contohnya muncul nama toko roti palsu seperti Sunshine Bakery, Golden Grain Bakery, dan Bliss Bakery
  • Solusinya adalah tidak mengirim prompt sama sekali jika tidak ada teks
• GPT-4 dapat memiliki jendela 128k token untuk input, tetapi jendela output masih berada di kisaran 4k
  • Istilah “context window” membuat input dan output mudah tercampur
• Saat diminta mengembalikan daftar objek JSON, bahkan untuk objek sederhana pun sulit melewati 10 item
  • Jika diminta 15 item, diperkirakan hanya sekitar 15% yang berhasil
  • Bahkan ketika berhenti di kisaran 10 item, output-nya hanya sekitar 700–800 token
• Batas output bisa diakali dengan meminta satu per satu lalu memasukkan kembali hasil sebelumnya, tetapi bentuknya menjadi seperti bermain telepon rusak dengan GPT dan berurusan dengan alat seperti Langchain

RAG dan vector DB tidak cocok untuk kasus penggunaan ini

• Dalam kasus Truss, vector DB dan RAG/embedding sebagian besar tidak berguna
• Vector DB dan RAG dipandang lebih cocok untuk pencarian, khususnya pencarian sungguhan seperti Google dan Bing
• Masalah intinya adalah kriteria relevansi
  • Tidak ada cutoff relevansi yang jelas
  • Mungkin ada solusi seperti rerank dari Cohere atau heuristik internal, tetapi tidak stabil
  • Ada risiko hasil pencarian tercemar oleh hasil yang tidak relevan, atau terlalu konservatif sehingga melewatkan hasil penting
• Menyimpan vector di basis data khusus/proprietary yang terpisah dari data umum juga menimbulkan kerugian besar
  • Jika bukan pada skala Google atau Bing, kehilangan konteks dianggap tidak membenarkan trade-off tersebut
• Dalam pencarian di aplikasi bisnis, pengguna sering kali adalah pakar domain
  • Mereka dianggap tidak menyukai semantic search yang menebak dan mengembalikan makna yang tidak mereka masukkan sendiri
• Untuk sebagian besar kasus pencarian, menggunakan LLM sebagai completion prompt biasa untuk mengubah kueri pengguna menjadi faceted search, kueri kompleks, atau SQL bisa jadi lebih baik
  • Cara ini bukan RAG

Halusinasi sangat berkurang saat konteks cukup

• Sebagian besar kasus penggunaan Truss berbentuk “berikan blok teks dan ekstrak sesuatu darinya”
• Jika diminta nama perusahaan yang disebutkan dalam teks, GPT biasanya tidak mengembalikan perusahaan sembarang
  • Namun, jika tidak ada perusahaan dalam teks, masalah hipotesis nol kembali muncul
• Pada kode pun, saat menulis ulang blok kode yang diberikan, GPT jarang berhalusinasi dalam arti mengarang variabel atau menyisipkan typo sembarangan di tengah
  • Namun jika diminta membuat sesuatu, ia bisa mengarang keberadaan fungsi standard library
  • Ini juga dianggap lebih dekat pada masalah tidak mampu mengatakan “tidak tahu”
• Untuk tugas yang menyediakan seluruh konteks lalu meminta analisis, peringkasan, dan ekstraksi, hasilnya sangat dapat diandalkan
• Strukturnya mendekati: jika memasukkan data yang baik, respons token GPT yang baik akan keluar

Penilaian terhadap prospek ke depan

• Mereka menilai bahwa transformer saat ini, data internet, dan akses ke infrastruktur bernilai puluhan miliar dolar saja tidak akan mencapai AGI
• GPT-4 bukan sekadar marketing, melainkan teknologi yang 100% berguna, dan mereka melihatnya masih berada pada tahap yang mirip awal internet
  • Ini bukan teknologi yang akan memecat semua orang
  • Efek besarnya adalah menurunkan hambatan masuk ke ML/AI yang sebelumnya hanya dapat diakses Google
• Claude, Gemini, dan lainnya tidak diuji dengan A/B test yang ketat
  • Saat diuji untuk coding sehari-hari, mereka merasa model-model itu tidak sedekat GPT-4 dalam hal nuansa memahami maksud secara intuitif
• Mereka menilai tidak perlu mengikuti semua arus LLM/AI
  • Jika dilihat melalui The Bitter Lesson, bila peningkatan performa model umum lebih penting daripada perbaikan khusus, maka cukup memperhatikan apakah GPT-5 dirilis
  • Kecuali area terpisah seperti Sora, sebagian besar rilis menengah OpenAI dianggap lebih dekat ke noise
• GPT-5 kemungkinan besar berupa perbaikan bertahap, bukan mengubah segalanya
  • Saat berpindah dari GPT-3 ke GPT-3.5, mereka mengharapkan perbaikan superlinear, yaitu menggandakan intensitas pelatihan akan meningkatkan performa 2,2 kali
  • Kenyataannya terlihat seperti perbaikan logaritmik, dengan kecepatan token dan biaya per token yang meningkat secara eksponensial demi perbaikan bertahap
• GPT-4 mungkin merupakan titik optimal untuk rangkaian pekerjaan saat ini
  • Mereka bersedia membayar biaya 20 kali lipat untuk GPT-4 dibanding GPT-3.5, tetapi tampaknya tidak akan membayar 20 kali lipat per token untuk berpindah dari GPT-4 ke GPT-5
  • GPT-5 bisa saja mematahkan perkiraan ini, atau mungkin hanya setara perpindahan dari iPhone 4 ke iPhone 5

[GN⁺]

Komentar Hacker News

• Tim yang saya tangani memproses 5 miliar+ token setiap bulan dan terus bertambah; ada beberapa hal yang kami pelajari.
  Pertama, ada banyak abstraksi yang terlalu dini. Alat seperti Langchain mungkin suatu hari berguna, tetapi pada akhirnya prompt hanyalah panggilan API, dan lebih mudah memperlakukan panggilan LLM sebagai panggilan API yang tidak stabil dengan kode standar daripada memperlakukannya sebagai sesuatu yang istimewa.
  Kedua, halusinasi jelas merupakan masalah besar. Ringkasan cukup kuat dalam pengujian, tetapi penalaran benar-benar sulit, dan model tindakan yang menerima input pengguna lalu membiarkan LLM menentukan tindakan berikutnya sangat sulit, terutama dalam memahami konteks dan membuatnya mengatakan “tidak yakin”. Meski begitu, fakta bahwa ini bisa dilakukan saja sudah mengubah permainan.
  Ketiga, saya sedikit lebih condong daripada penulis ke arah “mengubah permainan”, tetapi tidak melihatnya sebagai akhir dunia. Beberapa pekerjaan akan sangat terdampak, dan mungkin akan ada beberapa tahun yang berat ketika bot memanipulasi opini publik di platform. Secara keseluruhan, ini tampak lebih seperti penguat kemampuan daripada terobosan seperti internet.
  Secara pribadi, ini mirip dengan perubahan DevOps pada era 2000-an. Sekarang kita tidak membutuhkan tim khusus besar untuk membantu deployment; kita merekrut segelintir ahli dan sebagian besar membeli solusi siap pakai. Demikian pula, beberapa pekerjaan machine learning kini menjadi mudah diimplementasikan bahkan oleh pengembang web seperti saya.

  • Analogi seperti ini berguna saat menjelaskan bagaimana LLM seharusnya diharapkan dalam alur pengembangan modern. Karena ini menunjukkan bahwa ia bukan solusi serba bisa, melainkan kompromi.
    Evolusi DevOps juga punya kompromi. Misalnya, sebagai akibat langsung dari “pakai saja AWS RDS”, kompetensi inti seperti manajemen database menghilang, dan biaya tagihan cloud juga melonjak. Biaya operasional startup, terutama yang skala datanya atau kompleksitas regionalnya tidak besar, ikut membesar; menurut saya tren ini juga berujung pada insiden-insiden yang mirip dengan gangguan besar GitLab.
  • Membuatnya mengatakan “tidak yakin” lebih dekat ke fungsi dari model bahasa itu sendiri. Pada saat mencapai output, ketidakpastian yang melekat dalam komputasi menghilang di dalam prediksi.
    Mirip seperti ketika diminta menebak sisi koin lalu menjawab “kepala”: sebelum menjawab, kita bisa menyatakan ketidakpastian seperti Pr[kepala] = .5, tetapi dalam prediksi aktual dan hasil lemparan koin, ketidakpastian itu menghilang. Pada LLM juga, ketidakpastian selama komputasi menghilang pada prediksi akhir token, sehingga kecuali prediksi itu sendiri merupakan ekspresi ketidakpastian, output “saya tidak memahami” hampir tidak akan muncul. Namun alasannya adalah karena sejak awal ia memprediksi tanpa memahami.
  • Saya belum pernah memikirkan analogi DevOps sebelumnya, tetapi rasanya cocok, jadi barusan saya menulis artikel berdasarkan ide ini: https://kenkantzer.com/gpt-is-the-heroku-of-ai
    Pada dasarnya, menurut saya kita menggunakan GPT sebagai padanan PaaS/Heroku/Render dalam operasi AI.
  • Saya setuju dengan “lebih seperti penguat kemampuan daripada terobosan seperti internet”. Para pelanggan juga merasakan kejutan harga pada output dibanding biaya model besar. Seiring waktu, biayanya akan turun.
  • Saya setuju dengan pernyataan bahwa ringkasan kuat tetapi penalaran sulit. Cara meminta analogi itu menarik dan ternyata berguna.

• Saya penasaran dengan bagian “Kami selalu mengekstrak JSON. Mode JSON tidak diperlukan”. Dalam kasus saya, itu bekerja cukup baik.
  Saya sangat setuju dengan “Pelajaran 4: GPT benar-benar lemah dalam membuat hipotesis nol”. Kemarin pun, saat menguji prompt aturan penyuntingan teks, saya menulis di bagian akhir: “Jika tidak ada aturan yang berlaku pada teks, kembalikan teks asli tanpa perubahan.”
  Tahu apa jawaban ChatGPT untuk teks yang tidak satu pun aturannya berlaku? Persis string “The original text without any changes”.

  • Ada kisah-kisah tentang jin licik yang menafsirkan kata-kata permohonan secara harfiah lalu mengabulkan permohonan terkutuk; itulah yang kita miliki sekarang. Orang-orang yang sudah lama memasukkan prompt ke model pembuat gambar mungkin sudah agak paham, tetapi bagi orang yang masuk lewat LLM, ini bisa cukup mengejutkan.
    Dulu, ketika saya membuat gambar untuk kartu tarot berupa tiga perempuan yang minum anggur di taman indah, saya menambahkan “lush vegetation” di akhir prompt, lalu karena ambiguitas kata lush, suasananya berubah dari elegan menjadi terasa seperti mahasiswi pesta berhidung merah.
  • Saya membacanya sebagai “cara kami bekerja dengan baik, jadi tidak perlu memakai mode JSON”. Perusahaan kami juga dalam situasi yang sama. Sudah berjalan setahun dan tidak perlu diubah. Prompt kami cukup efektif membuat GPT-3.5 selalu mengeluarkan JSON.
  • Kalau melihat situs-situs kegagalan dekorasi kue, manusia juga selalu melakukan kesalahan semacam ini.

• Dengan prompt yang lebih baik, Anda bisa memakai model yang lebih murah.
  “Jika tidak menemukan apa pun, jangan kembalikan apa pun” adalah cara level 0 yang memberi LLM jalan keluar. Lebih baik memberinya jalur keluar yang lebih halus. Misalnya, tulis seperti “Jika tidak ada cukup informasi untuk membuat pernyataan yang meyakinkan, Anda boleh membuat hipotesis selama Anda menyatakan dengan jelas bahwa itulah yang sedang Anda lakukan serta menuliskan dasar dan landasan logis hipotesis tersebut”, lalu di akhir minta ia menilai jawabannya sendiri.

  • Prompt tidak boleh dikembangkan secara abstrak. Tujuan prompt adalah mengaktifkan representasi internal model agar ia melakukan tugas sebaik mungkin.
    Jika tidak ada metode otomatis, Anda perlu menguji respons model secara berulang terhadap berbagai input, memahami bagaimana ia menafsirkan permintaan, di mana ia gagal, lalu menutup celah tersebut. Bahkan Anda harus memverifikasi apakah model benar-benar tahu arti nothing.

• Saya berlangganan ketiga layanan teratas di bidang LLM dan sering melempar prompt yang sama; hasilnya sangat berat sebelah menguntungkan GPT-4. Mengingat GPT-4 sudah keluar selama 1 tahun dan sempat ada beberapa pembaruan di antaranya, ini tetap mengejutkan
  Setidaknya dalam pola penggunaan saya, halusinasi juga terbilang jarang. Sebaliknya, saat menulis kode, Claude cukup mudah mengarang API yang terdengar masuk akal tetapi sebenarnya tidak ada. GPT-4 lebih keras kepala dan tidak terlalu mudah mengiyakan ketika ia tahu dirinya benar. Perbedaan seperti ini hampir tidak tertangkap dalam metrik, jadi baru terlihat kalau dipakai sendiri

  • Dalam kasus saya, Claude 3 Opus lebih baik daripada GPT-4. Terutama lebih baik dalam menjelaskan, dan yang lebih penting, lebih menyeluruh
    Untuk pekerjaan coding pun saya lebih sering meminta penjelasan tentang topik atau kode daripada menyuruhnya menulis kode, dan Claude cenderung memberikan jawaban yang jauh lebih bernuansa. Saat diberi teks panjang lalu diajak berdialog, Claude Opus terasa memahami isinya lebih dalam; sementara GPT-4 cenderung berhenti pada merangkum teks yang diberikan, Claude lebih baik dalam memperluas dan bernalar darinya
  • Saya penasaran apakah perbandingannya dengan Claude Opus, atau dengan varian yang lebih rendah. Opus benar-benar saya sukai untuk membuat naskah bahasa Inggris
  • GPT-4 lebih mampu menangani prompt yang bentuknya buruk, informasinya kurang, atau strukturnya berantakan. Jika prompt besar tidak disusun secara cerdas, Claude bisa bingung tentang apa yang diminta
    Namun pada prompt yang tersusun baik, Claude Opus cenderung menghasilkan keluaran yang lebih baik daripada GPT-4. Claude lebih fleksibel dan memberikan jawaban yang lebih panjang, sedangkan ChatGPT/GPT-4 hampir selalu terdengar seperti jawaban pendek dan “khas” versinya sendiri
  • Pengalaman saya justru sebaliknya. Saya berlangganan beberapa layanan dan menyalin-tempel pertanyaan yang sama; untuk pertanyaan terkait pengembangan perangkat lunak, Claude Opus jauh lebih unggul sampai saya berpikir mungkin saya tidak perlu lagi memakai GPT-4
    Pada contoh kode yang saya minta, kode buatan GPT-4 sering kali bahkan tidak bisa dikompilasi, sedangkan dengan Claude hampir tidak pernah begitu
  • Saya juga berlangganan ketiganya dan membandingkannya dengan cara yang sama. Terutama setiap kali versi baru keluar
    Tes lakmus yang saya pakai belakangan ini adalah “beri tahu saya 10 bar unik dalam radius 200 mil dari Austin”. Ini sangat sulit bagi semuanya; GPT-4 lumayan mendekati, tetapi Claude hanya mengarang, dan Gemini benar-benar berantakan

• GPT memang sangat keren, tetapi saya sangat tidak setuju dengan interpretasi dua paragraf dalam tulisan itu
  Bisa saja diringkas bahwa pendekatan yang lebih baik adalah semacam “GPT, kamu jelas tahu 50 negara bagian, jadi berikan nama lengkap negara bagian yang sesuai dengan ini, atau jawab Federal jika ini terkait pemerintah AS”
  Namun menurut saya berlebihan jika menafsirkan bahwa kualitas dan generalisasi GPT yang membaik ketika instruksinya dibuat lebih ambigu adalah tanda khas delegasi/pemikiran tingkat tinggi. Bahasa alami adalah keluaran yang paling probabilistik bagi GPT, karena mirip dengan teks yang dipelajarinya. Dalam kasus ini, developer hanya lebih bersandar pada hal yang memang dikuasai GPT, bukan membuatnya bekerja lebih keras
  Ada banyak tugas sederhana yang bisa membuat GPT gagal. Tugas seperti substitusi huruf atau salah ketik yang disengaja sangat sulit bagi GPT. Pemetaan ID juga sama, terutama bila sangat berbeda dari pemetaan yang pernah dilihat saat pelatihan. Misalnya kode tiga huruf yang mirip seperti kode negara non-ISO
  Hal yang menarik adalah fakta bahwa GPT “memahami” pemetaan itu sendiri. Justru itu menurut saya petunjuk nyata dari pencocokan pola tingkat tinggi

  • Atau bisa juga ia hanya menghafal pemetaan. Bukan dalam arti mereproduksinya apa adanya, melainkan memiliki vektor yang mirip dengan pemetaan yang pernah dilihat sebelumnya

• Tips untuk masalah ‘null’: LLM dibuat untuk mengeluarkan token, bukan untuk tidak mengeluarkan token
  Jadi alih-alih mengatakan “jangan kembalikan apa pun”, saat tidak ada hasil katakan “kembalikan nilai default XYZ”, lalu cari nilai default itu, misalnya XYZ, dalam hasilnya seperti mencari nama negara bagian
  Selain itu, system prompt bisa sangat berguna. Pada dasarnya ini kesempatan untuk membuat LLM bermain peran sebagai X. Akan bagus jika system prompt bisa diteruskan langsung, tetapi tetap lebih baik daripada tidak ada

• Kalau GPT tidak bisa mengembalikan daftar lebih dari 10 objek JSON dengan benar, itu masalah prompt. Saya pernah membuatnya secara stabil mengembalikan hingga 200 item dalam urutan yang benar
  Triknya adalah tidak memakai daftar sama sekali, dan menggunakan key JSON seperti "item1": {...} pada output. Jika untuk suatu input ada 0 hingga n output, daftar bisa dipakai sebagai nilainya

  • Pengguna memberi tahu bahwa mereka berasal dari budaya yang menganggap menjawab dengan daftar tidak lengkap itu tidak sopan dan menghina
  • Saya berharap Anda bisa menjelaskan lebih detail. Saya sedang pusing menghadapi masalah ini
    Jika saya memberi GPT-4 daftar item yang sudah ada dengan struktur terdefinisi dan memintanya mengubah ke JSON seperti konversi skema, itu bisa berjalan baik sepanjang hari. Tetapi jika dibutuhkan penalaran apa pun dan pada dasarnya ia harus membuat daftarnya sendiri, ia hanya memberi subset yang sangat terbatas
    Saya mengalami masalah serupa di LLM lain. Saya sangat penasaran bagaimana Anda mendekatinya

• Tugas seperti “ekstrak nama perusahaan dari blok teks” bisa dibagi menjadi dua tahap
  Pertama tanyakan, “apakah ada perusahaan yang disebutkan dalam blok teks ini?” Jika tidak, berarti Anda mendapat hasil null. Jika ya, tanyakan “daftarkan nama perusahaan yang ada dalam blok teks ini”

• Saya memakai model OpenAI di aplikasi menulis pribadi, dan tulisan ini sangat tepat. Ada hal yang saya pelajari terkait Lesson 1, “semakin sedikit prompt, semakin baik”
  Saat membuat fitur pencarian cerdas untuk catatan, saya mencoba membuat ChatGPT mengembalikan data JSON terstruktur. Misalnya saya bertanya “beri saya semua catatan saya dalam 2 tahun terakhir yang menyebut Haskell dan ditandai sebagai draf”, lalu ingin ChatGPT menilai sendiri apa yang harus dikembalikan. Ini hanya kadang-kadang berhasil
  Sebagai gantinya, saya memasukkan data ke database SQLite, mengirimkan skemanya ke ChatGPT, lalu memintanya menulis query yang mengembalikan hasil yang diinginkan; hasilnya jauh lebih baik

  • Ini tampaknya lebih cocok untuk database dan filter pencarian yang baik daripada LLM
  • Saya penasaran apakah Anda sudah mencoba response_format=json_object
    Untuk mendapatkan respons terstruktur, function calling lebih cocok, tetapi batasannya lebih banyak dibanding sekadar menerima body JSON

• Contoh ketika memberi instruksi terlalu tepat justru menurunkan akurasi terasa masuk akal menurut pemahaman saya yang masih kasar tentang cara kerja sistem seperti ini
  Jika memasukkan seluruh daftar negara bagian, itu seolah mengaktifkan vektor untuk semua negara bagian sampai tingkat tertentu. Jika hanya mengatakan “state” dan teks yang diberikan memiliki negara bagian eksplisit, lebih sedikit vektor yang terkait dengan target pencarian yang aktif. Jadi saat melakukan softmax, kemungkinan negara bagian yang benar terpilih menjadi lebih tinggi
  Dalam konteks yang sama, perbandingan /n dan koma kemungkinan besar juga karena perbedaan tokenisasi