AI Anda Tidak Bodoh — Data Anda Yang Bermasalah: Panduan Lapangan untuk Pengendali

Kenali Jordan. Beliau menguruskan operasi untuk firma perkhidmatan profesional 90 orang. Perniagaan mereka berkembang maju: pengekalan pelanggan yang baik, pasukan yang semakin berkembang, tiada drama pembiayaan.

Tetapi tiga minggu lalu, beliau memperjuangkan penggunaan pembantu AI untuk menjawab soalan HR dan polisi dalaman. Pasukannya teruja. Beliau menghabiskan dua minggu mengkonfigurasinya dengan vendor mereka. Mereka beroperasi pada hari Isnin.

Menjelang hari Rabu, salah seorang pengurus kanan beliau datang kepadanya dengan tangkapan skrin. Pembantu itu telah memberitahu pekerja bahawa mereka berhak mendapat 10 hari cuti berbayar. Pekerja lain bertanya soalan yang sama, dengan frasa yang berbeza, dan mendapat 15 hari. Jawapan sebenar adalah 12.

Naluri pertama Jordan: AI itu rosak. Beliau menghubungi vendor. Selepas 45 minit di telefon, wakil sokongan berkata, "Dari segi teknikal, model ini melakukan apa yang sepatutnya dilakukan."

Beliau betul. Dan itulah yang menjadikannya begitu mengecewakan.

Artikel ini untuk Jordan, dan untuk setiap pengendali yang pernah melihat AI menghasilkan output yang salah dengan yakin, terlalu generik, atau agak memalukan dan tertanya-tanya apa yang salah. Jawapan ringkas: ia hampir tidak pernah model tersebut. Ini adalah datanya. Inilah cara mengetahui, dan apa yang perlu dilakukan.

Mengapa pengendali menyalahkan model (dan mengapa itu biasanya salah)

Apabila AI memberikan output yang buruk, model adalah perkara yang boleh anda lihat. Ia adalah produk yang anda bayar. Ia adalah suspek yang jelas.

Tetapi Rangka Kerja ACE menganggap data sebagai lapisan Asas dengan alasan yang kukuh. Sebelum Ingest, Analyze, atau Generate boleh berfungsi, AI memerlukan data yang tepat, semasa, lengkap, dan tidak bermakna ganda. Jika mana-mana syarat tersebut gagal, keupayaan di atasnya tidak berfungsi dengan betul, tidak kira sebaik mana model yang mendasarinya.

Fikirkan begini: jika anda meminta pekerja baru untuk menjawab soalan pelanggan menggunakan folder dokumen polisi yang lapuk dan bercanggah, mereka juga akan memberikan jawapan yang buruk. Pekerja itu tidak bodoh. Maklumat yang diberikan kepada mereka adalah salah.

Enam corak di bawah adalah cara paling biasa kegagalan data muncul sebagai "kegagalan AI." Untuk setiap satu, terdapat gejala yang akan anda perhatikan, punca sebenar di bawahnya, dan pembaikan. Pembaikannya hampir tidak pernah "tukar model."

Gejala 1: "AI memberikan jawapan generik, tidak berkaitan topik"

Apa yang anda lihat: Anda bertanya kepada pembantu AI anda soalan khusus tentang produk, proses, atau polisi anda. Jawapannya terasa seperti sesuatu yang boleh anda temui di halaman bantuan generik. Ia tidak mencerminkan persediaan sebenar syarikat anda.

Punca sebenar: Pangkalan pengetahuan yang digunakan oleh AI adalah sama ada terlalu jarang atau lapuk. Pasukan sokongan di sebuah syarikat SaaS menghadapi masalah ini selepas menggunakan Intercom Fin sebagai penjawab barisan pertama mereka. Pelanggan yang bertanya tentang peringkat harga yang telah dikemas kini enam bulan lalu terus mendapat jawapan lama, yang didokumentasikan dalam eksport SharePoint yang telah digunakan untuk menyemai konteks AI itu. Model itu tidak salah; dokumennya yang salah.

Pembaikan: Audit indeks, bukan model. Cari tahu dokumen mana yang ada dalam kumpulan pengambilan AI. Semak bila ia terakhir dikemas kini. Cari jurang antara apa yang pelanggan atau pekerja sebenarnya tanya dan apa yang didokumentasikan. Ini adalah masalah seni bina maklumat, bukan masalah model.

Gejala 2: "AI mencipta fakta yang tidak benar"

Apa yang anda lihat: AI menghasilkan jawapan yang kedengaran masuk akal tetapi ternyata direka-reka. Petikan palsu. Polisi yang dicipta. Nombor tanpa sumber.

Punca sebenar: Model mengisi jurang. Apabila langkah pengambilan AI tidak mengembalikan dokumen yang relevan, kebanyakan model bahasa masih menghasilkan jawapan yang kedengaran koheren. Mereka direka untuk membantu. Masalahnya adalah "membantu" dan "tepat" bukan perkara yang sama apabila konteks kosong.

Pasukan undang-undang di sebuah firma perkhidmatan pasaran pertengahan menggunakan alat semakan dokumen AI untuk mencari preseden yang relevan bagi pertikaian kontrak. Alat itu memetik kes yang tidak dapat ditemui oleh peguam di mana-mana. Pengambilan itu gagal untuk menampakkan preseden sebenar, jadi model itu membuat ekstrapolasi ke arah sesuatu yang masuk akal. Rakan kongsi yang menyemak output menangkapnya. Tetapi bayangkan jika mereka tidak berbuat demikian.

Pembaikan: Lakukan kerja kesediaan data terlebih dahulu, dan mulakan dengan lapisan pengambilan. Komponen pengambilan dalam sistem RAG (Retrieval-Augmented Generation) adalah di mana ini rosak. Pemecahan yang lemah, pengindeksan yang lemah, dan carian semantik yang lemah semuanya menyebabkan kegagalan pengambilan. Model menjana rekaan apabila pengambilan tidak mengembalikan apa-apa yang berguna. Betulkan lapisan pengambilan. Modelnya tidak mengapa.

Gejala 3: "Penilaian prospek tidak berguna — ia lebih buruk daripada naluri"

Apa yang anda lihat: Pasukan anda menggunakan model penilaian prospek ramalan dalam Salesforce atau HubSpot. Selepas satu suku tahun penggunaan, wakil berkata skor tidak sepadan dengan realiti. Skor tinggi tidak tutup. Skor rendah kadang-kadang ya.

Punca sebenar: Label latihan adalah bising. Dalam data jualan, "ditutup-menang" sering merupakan medan yang paling kotor dalam CRM. Urusan dimasukkan bertarikh ke belakang. Peralihan peringkat ditindih secara manual. Kemasukan data berlaku berminggu-minggu selepas hakikat. Seorang ketua operasinya di sebuah syarikat B2B bersaiz sederhana mendapati bahawa cap masa peringkat peluang mereka sedang disunting secara retroaktif oleh wakil yang membersihkan Pipeline mereka sebelum akhir suku tahun. Model yang dilatih pada label tersebut mempelajari corak yang tidak mencerminkan tingkah laku pembeli sebenar. Ia mempelajari corak kemasukan data wakil yang keletihan di bawah tekanan kuota.

Pembaikan: Bersihkan data label. Khususnya, audit medan yang digunakan oleh model anda sebagai kebenaran asas. Untuk penilaian prospek, itu biasanya bermakna "ditutup-menang," "ditutup-kalah," dan tarikh peralihan peringkat. Jalankan pertanyaan: berapa banyak rekod yang terakhir disunting dalam masa 48 jam dari akhir suku tahun? Berapa kerap urusan bergerak ke belakang dalam peringkat? Anomali tersebut adalah bunyi dalam label anda. Bersihkannya dahulu. Kemudian latih semula.

Gejala 4: "AI menulis salinan yang tidak kedengaran seperti kita"

Apa yang anda lihat: Pasukan pemasaran anda menggunakan alat penulisan AI (Jasper, Writer, atau seumpamanya) untuk menyusun kempen. Output adalah betul dari segi tatabahasa tetapi salah dari segi nada. Ia kedengaran korporat. Ia tidak kedengaran seperti jenama anda.

Punca sebenar: Model tidak mengetahui suara anda kerana tiada siapa yang memberitahunya. Ia lalai kepada purata semua yang dilatihnya, yang merupakan banyak kandungan B2B generik. Jika anda belum memasukkan panduan gaya, dokumen suara jenama, salinan e-mel terbaik anda, dan perbendaharaan kata khusus jenama anda ke dalam sistem, model tidak mempunyai asas untuk memadankan nada anda.

Pembaikan: Kurasikan korpus gaya, bukan arahan yang lebih keras. "Tulis ini dalam suara jenama kami" bukan panduan gaya. Anda memerlukan contoh sebenar: tiga hingga lima e-mel terbaik anda, perenggan yang menerangkan nada dalam bahasa biasa (tidak formal, terus, sesekali jenaka, tiada jargon), dan senarai perkataan atau frasa yang dilarang dalam pemasaran anda. Masukkan maklumat tersebut ke dalam sistem sebagai konteks. Anda akan melihat perbezaannya dalam draf seterusnya. Ini adalah masalah keupayaan Generate, bukan masalah pemilihan model.

Gejala 5: "Pembantu AI memberikan dua jawapan berbeza untuk soalan yang sama"

Apa yang anda lihat: Dua pekerja bertanya soalan polisi yang sama kepada pembantu AI dalaman anda, difrasa sedikit berbeza, dan mendapat jawapan yang bercanggah. Ini adalah persis apa yang berlaku kepada Jordan. AI tidak berbohong; ia membuat triangulasi antara dokumen yang bercanggah.

Punca sebenar: Pelbagai versi polisi yang sama wujud dalam indeks, dan tiada satu pun yang ditandai sebagai autoritatif. Syarikat Jordan mempunyai tiga dokumen polisi HR: satu asal dari 2022, versi yang dikemas kini dari 2024 yang seseorang telah simpan ke folder yang berbeza, dan FAQ peringkat jabatan yang mempunyai kesilapan taip. Ketiga-tiganya berada dalam kumpulan pengambilan AI. Model membuat purata antara mereka berdasarkan yang mana satu yang sepadan secara semantik dengan frasa soalan.

Pembaikan: Cipta satu sumber kebenaran, kemudian kuatkuasakan ia. Arkibkan atau buang dokumen yang lapuk daripada kumpulan pengambilan. Tandakan versi autoritatif secara eksplisit. Beberapa alat HR (Guru, Notion AI, Confluence AI) membolehkan anda menetapkan tahap kepercayaan dokumen atau mengekalkan sumber tertentu. Gunakan ciri itu. Model itu tidak keliru; pangkalan pengetahuan andalah yang keliru.

Gejala 6: "AI menganggap setiap pelanggan sebagai orang asing"

Apa yang anda lihat: Sokongan pelanggan berbantuan AI anda terasa tidak peribadi. Pelanggan berulang ditanya soalan yang telah mereka jawab. Akaun jangka panjang mendapat respons peringkat Onboarding generik. Wakil yang menggunakan balasan draf AI kelihatan terputus daripada hubungan pelanggan.

Punca sebenar: Sejarah akaun tidak dihantar ke dalam konteks AI. Model hanya mengetahui apa yang anda berikan kepadanya pada saat perbualan. Jika alat sokongan anda tidak menggabungkan data tiket dengan rekod akaun CRM (nilai kontrak, tempoh, isu lalu, wakil yang ditugaskan), AI menjawab kepada peristiwa yang terpencil tanpa ingatan tentang hubungan tersebut.

Seorang ketua kejayaan pelanggan di sebuah syarikat SaaS menerangkan situasi melihat sembang sokongan berbantuan AI mereka menyapa pelanggan enterprise tiga tahun dengan menjelaskan cara menyediakan akaun mereka. Model menjawab soalan seperti yang ditulis, tanpa konteks bahawa orang ini telah menjadi pelanggan sejak 2022 dan mempunyai CSM yang berdedikasi. Integrasi antara platform sokongan dan CRM mereka tidak pernah dikonfigurasi.

Pembaikan: Ini adalah masalah integrasi. Khususnya, ia adalah jurang keupayaan Ingest: AI tidak menyerap data hubungan pelanggan yang diperlukannya. Minta pasukan anda mengaudit konteks apa yang dihantar ke AI pada permulaan perbualan. Biasanya, itu bermakna mengkonfigurasi alat sokongan anda (Zendesk, Intercom, Help Scout) untuk menyuntik data akaun daripada CRM anda pada permulaan setiap sesi. AI hanya boleh bekerja dengan apa yang diterimanya.

Cara mendiagnosis "AI yang buruk" seperti jurutera sistem

Sebelum menghubungi vendor anda, jalankan diagnostik empat langkah ini pada mana-mana masalah output AI.

Langkah 1: Kumpul 10 contoh output yang buruk. Jangan bekerja daripada satu insiden; anda memerlukan corak.

Langkah 2: Untuk setiap contoh, tanya: "Adakah AI mempunyai konteks yang cukup betul, semasa, relevan untuk menjawab ini dengan baik?" Lihat dokumen mana yang diambil, data apa yang dihantar masuk, apa yang sebenarnya terkandung dalam pangkalan pengetahuan.

Langkah 3: Gunakan ujian manusia. Jika anda memberikan kepada pekerja baru yang cekap konteks yang sama persis seperti yang dimiliki oleh AI, adakah mereka juga akan salah? Jika ya, ia adalah masalah data. Jika manusia itu jelas akan menjawab dengan betul, anda mungkin mempunyai masalah model.

Langkah 4: Betulkan laluan data sebelum melaraskan model. Kemas kini pangkalan pengetahuan. Bersihkan label. Tingkatkan pengambilan. Wayarkan integrasi. Kemudian uji semula.

Urutan ini berfungsi kerana sistem AI, terutamanya yang dibina atas keupayaan Analyze dan Generate, adalah bergantung konteks pada dasarnya. Mereka memproses apa yang diterima. Jika anda membetulkan apa yang diterima, kualiti output meningkat tanpa menyentuh model sama sekali.

Apabila ia sebenarnya kesalahan model

Artikel ini adalah jujur, jadi inilah: kadang-kadang model adalah masalahnya.

Jika AI anda secara konsisten gagal pada tugas penaakulan mudah yang tidak ada kaitan dengan konteks (matematik asas, penafian logik, arahan berbilang langkah dengan input yang jelas), itu adalah isu keupayaan model.

Jika AI anda tidak dapat mengendalikan jargon khusus domain, akronim, atau terminologi khusus yang muncul secara konsisten dalam industri anda, anda mungkin memerlukan penalaan halus atau varian model khusus domain.

Jika AI anda terlalu perlahan, terlalu mahal setiap pertanyaan, atau menghasilkan output yang betul tetapi terlalu panjang untuk kes guna anda, itu adalah masalah pemilihan model. Peringkat model yang berbeza (GPT-4o vs. GPT-4o mini, Claude Sonnet vs. Claude Haiku) mempunyai pertukaran harga-kelajuan-kualiti yang berbeza dengan ketara.

Dan jika anda telah membetulkan data, meningkatkan pengambilan, membersihkan label, dan masalah berterusan, maka ya, cuba model yang berbeza.

Tetapi urutan itu penting. Kebanyakan pasukan melepasi audit data dan terus kepada eksperimen model. Mereka menghabiskan berminggu-minggu menguji A/B arahan terhadap LLM yang berbeza sementara pangkalan pengetahuan mereka masih mempunyai tiga versi dokumen polisi yang bercanggah. Langkah data itu membosankan. Ia juga hampir selalu menjadi kesesakan.

Sebelum anda menukar vendor, audit data anda

AI perniagaan berjalan pada tujuh jenis data: teks, berstruktur, imej, audio, video, kod, dan siri masa. Setiap jenis tersebut boleh memperkenalkan masalah kualiti dengan cara yang berbeza. Dokumen teks yang lapuk. Label berstruktur yang bising. Transkripsi audio dengan ralat atribusi penutur. Setiap jenis data mempunyai mod kegagalannya sendiri.

Apa yang mereka ada persamaan adalah ini: AI tidak boleh mencipta data yang baik. Ia hanya boleh bekerja dengan apa yang ada. Berikan maklumat yang tepat, semasa, lengkap, dan tidak bermakna ganda, dan ia akan berprestasi pada tahap model. Berikan sampah, dan ia akan menghasilkan sampah dengan yakin.

Jordan membetulkan bot HR-nya. Ia mengambil masa dua jam: beliau mengarkibkan dokumen polisi lama, menandakan versi 2024 sebagai autoritatif, dan menambah nombor cuti berbayar yang sebenar ke dalam FAQ. Jawapan bot menjadi konsisten dan betul. Model yang sama. Vendor yang sama. Data yang berbeza.

Sebelum anda menulis e-mel kepada vendor AI anda meminta untuk menukar model, luangkan 30 minit untuk soalan yang ditanya oleh wakil sokongan kepada Jordan: apa sebenarnya yang terkandung dalam konteks yang sedang digunakan oleh AI? Jawapannya biasanya membuka mata.

---

Artikel ini adalah sebahagian daripada siri Asas Rangka Kerja ACE. Bacaan berkaitan: Kesediaan Data untuk AI merangkumi cara menilai sama ada data anda bersedia untuk AI sebelum anda menggunakan. 7 jenis data memetakan keseluruhan landskap data perniagaan dan di mana setiap jenis gagal. Apa itu Keupayaan Analyze menjelaskan cara AI memahami data — dan di mana proses itu rosak.