Memisahkan Sinyal dan Noise dalam Evaluasi Coding

 (openai.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Evaluasi kemampuan coding model AI terhubung langsung dengan keputusan deployment dan penilaian keselamatan, tetapi audit OpenAI memperkirakan sekitar 30% tugas di SWE-Bench Pro berada dalam kondisi rusak
  • SWE-Bench Pro ditujukan untuk cakupan tugas yang lebih panjang dan tantangan yang lebih realistis, tetapi hasil pada 731 tugas publik yang menunjukkan tingkat kelulusan naik dari 23,3% menjadi 80,3% dalam 8 bulan menjadi sulit dipercaya apa adanya
  • Cacat dibagi menjadi pengujian yang terlalu ketat, prompt yang kurang terspesifikasi, pengujian dengan cakupan rendah, dan prompt yang menyesatkan, sehingga kiriman yang benar bisa gagal atau perbaikan yang tidak lengkap bisa lolos
  • Audit menandai 286 tugas yang berpotensi bermasalah berdasarkan percobaan model, metadata tugas, dan pelacakan kegagalan, lalu menjalani peninjauan independen oleh agen investigasi dan 5 insinyur berpengalaman
  • OpenAI telah mencabut rekomendasi adopsi SWE-Bench Pro, dan benchmark evaluasi harus memberikan sinyal yang bermakna yang tidak mendistorsi penilaian kemampuan model maupun keselamatan

Masalah yang terungkap dalam audit SWE-Bench Pro

  • OpenAI mengaudit SWE-Bench Pro dan memperkirakan sekitar 30% dari seluruh tugas berada dalam kondisi rusak
  • Mengukur kemampuan model secara akurat juga memengaruhi keputusan deployment dan penilaian keselamatan menurut Preparedness Framework
  • Evaluasi yang cacat dapat membuat kemampuan model dipahami secara keliru dibanding kenyataannya, dan dapat menggoyahkan penilaian keselamatan serta prioritas riset

Tujuan SWE-Bench Pro dan perubahan tingkat kelulusan

  • OpenAI sebelumnya menemukan masalah desain dan kontaminasi pada SWE-bench Verified yang digunakan luas, dan menilai evaluasi tersebut tidak lagi memberi sinyal yang bermakna tentang kemampuan pengembangan perangkat lunak
  • Saat itu OpenAI merekomendasikan komunitas untuk beralih ke SWE-Bench Pro
  • SWE-Bench Pro dirancang untuk memperbaiki SWE-bench Verified agar dapat melacak kemampuan coding agentik melalui cakupan tugas yang lebih panjang dan tantangan coding yang lebih realistis
  • Tugas diekstraksi secara terprogram dari riwayat perubahan fitur di repositori publik dan privat
    • Model harus mengimplementasikan solusi yang meloloskan pengujian fitur baru tanpa merusak fungsi yang sudah ada
    • Pada split publik berisi 731 tugas, tingkat kelulusan model frontier naik dari 23,3% menjadi 80,3% selama 8 bulan

Pipeline jaminan kualitas

  • OpenAI membuat pipeline jaminan kualitas untuk memastikan tiap titik data benar-benar mencerminkan kemampuan model yang sesungguhnya
  • Filter otomatis awal meninjau instruksi yang diberikan ke model, upaya penyelesaian model, dan pengujian penilaian untuk menandai contoh yang rusak atau dicurigai bermasalah
  • Dalam proses ini, 286 tugas yang berpotensi bermasalah ditandai
  • Subset yang ditandai kemudian ditinjau lebih mendalam melalui dua jalur
    • Tinjauan agen dengan pengawasan manusia: agen investigasi melakukan pemeriksaan rinci dan kemudian melalui penilaian akhir oleh manusia
    • Kampanye anotasi manusia: pengembang perangkat lunak berpengalaman meninjau tugas secara langsung

Cara kerja tinjauan agen dan tinjauan manusia

  • Masalah yang ditandai diaudit oleh agen investigasi berbasis Codex
    • Agen memiliki akses ke repositori tugas dan lingkungan eksekusi
    • Agen dapat menjalankan pengujian, memeriksa file repositori, serta menyelidiki percobaan model dan mode kegagalan umum
    • Ini digunakan untuk membedakan ambiguitas yang masih wajar untuk diselesaikan lewat kode di sekitarnya dan konvensi repositori, dari under-specification yang nyata
  • Setelah beberapa audit mendalam yang independen, peneliti meninjau ringkasan lalu menetapkan penilaian akhir dan label masalah
  • Secara paralel, dalam kampanye anotasi manusia, insinyur perangkat lunak berpengalaman meninjau tugas setelah mendapat pelatihan tentang tujuan benchmark, klasifikasi masalah, dan kasus batas
  • Setiap tugas ditinjau oleh 5 insinyur
    • Peninjau terlebih dahulu membuat penilaian independen berdasarkan deskripsi masalah yang terlihat, test case, dan gold patch sebagai solusi referensi yang benar
    • Setelah itu mereka menggunakan analisis pipeline atau catatan sebagai konteks tambahan
    • Berdasarkan bukti konkret, mereka menetapkan label dan tingkat keparahan, lalu menaikkan kasus yang diperselisihkan atau berkeyakinan rendah untuk peninjauan tambahan

Empat jenis kegagalan

  • Masalah yang ditemukan dalam audit terutama terbagi ke dalam empat kategori
    • Pengujian yang terlalu ketat: memaksakan detail implementasi tertentu yang tidak ada di prompt, sehingga kiriman yang secara fungsional benar menjadi tidak valid
    • Prompt yang kurang terspesifikasi: melewatkan persyaratan yang diminta oleh pengujian tersembunyi tetapi sulit disimpulkan secara wajar
    • Pengujian dengan cakupan rendah: tidak cukup memverifikasi fungsi yang diminta, sehingga perbaikan yang tidak lengkap pun bisa lolos
    • Prompt yang menyesatkan: mengarahkan model ke perilaku yang salah atau bertentangan dengan persyaratan pengujian
  • Pada beberapa tugas, prompt meminta implementasi tertentu, tetapi test case tersembunyi justru mengharapkan perilaku yang berbeda

Perbedaan antara tinjauan manusia dan tinjauan agen

  • Peninjau manusia lebih cenderung menandai tugas sebagai rusak dibanding agen investigasi
  • Ada perbedaan dalam penilaian kategori antara dua jalur peninjauan itu, tetapi di antara tugas yang ditandai, tidak ada kasus di mana label manusia yang paling sering muncul adalah “tidak rusak”
  • Kategori yang ditandai oleh pipeline agen dan penilaian peninjau manusia bertumpang tindih pada 74% kasus
  • Peninjau manusia juga lebih sering memilih beberapa label untuk satu tugas
    • Ini menandakan tugas rusak dalam beberapa cara atau tidak pas dimasukkan dengan rapi ke satu kategori saja
    • Pipeline yang menggabungkan agen dan peninjau memang menangkap mode kegagalan luas yang ditemukan manusia, tetapi menghitung masalah tambahan atau tumpang tindih secara konservatif lebih sedikit
  • Perbedaan terbesar muncul pada pengujian dengan cakupan rendah
    • Manusia memilihnya sebagai masalah paling umum pada 9,4% benchmark
    • Pipeline agen menandainya sebesar 4,1%

Mengapa membangun benchmark itu sulit

  • Kasus SWE-Bench Pro dan SWE-bench Verified menunjukkan bahwa benchmark harus divalidasi dengan ketat
  • Issue dan pull request di repositori open source pada dasarnya dibuat untuk kolaborasi manusia, bukan untuk evaluasi model
  • Dalam lingkungan dengan banyak diskusi bolak-balik panjang antara maintainer dan kontributor, deskripsi masalah, kode yang digabungkan, dan unit test tidak selalu membentuk tugas yang bersih dan mandiri untuk evaluasi model
  • Pengujian yang disertakan dalam pull request kadang ditulis untuk memverifikasi perubahan tertentu, sehingga dapat memaksakan implementasi tertentu alih-alih kriteria solusi yang independen dari cara implementasinya

Arah evaluasi ke depan

  • Seiring kemampuan model meningkat, cacat evaluasi kini juga menjadi lebih mudah ditemukan dibanding sebelumnya
  • Model yang lebih baik dapat memeriksa prompt, pengujian, patch, jejak eksekusi, dan kasus batas dengan lebih dalam dan konsisten, sehingga bisa mengungkap masalah benchmark yang sebelumnya sulit ditemukan dalam skala besar atau mahal untuk dicari
  • OpenAI berharap komunitas evaluasi yang lebih luas mengembangkan benchmark baru yang dibuat langsung oleh pengembang perangkat lunak berpengalaman dengan tujuan menguji kemampuan model
  • Pendekatan ini memungkinkan pengawasan manusia yang lebih baik di seluruh proses sambil tetap mempertahankan tingkat kesulitan tinggi dan realisme yang ingin diukur
  • OpenAI mencabut rekomendasi sebelumnya untuk mengadopsi SWE-Bench Pro karena masalah yang terungkap dalam analisis ini
  • Evaluasi harus sulit dimanipulasi, mudah dipercaya, dan memberikan sinyal yang bermakna yang benar-benar mencerminkan kemampuan model atau status alignment-nya

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News
  • Perlu benchmark baru. Akan bagus kalau diukur dengan cara melihat seberapa banyak yang bisa diselesaikan model dari satu paket benchmark dengan biaya API $100
    Efisiensi dan kecerdasan harus diukur bersama. Model kecil bisa memakai strategi seperti menguji hasil lewat penggunaan komputer, atau bertahan lebih lama pada suatu masalah sambil memverifikasi output, sedangkan model besar mungkin kekurangan anggaran untuk pengujian mandiri sehingga bisa muncul perbedaan taktik yang menarik
  • Terminal Bench 2 punya cukup banyak hasil palsu karena berbagai alasan. Tim hebat seperti Ryan/Alex memang baru-baru ini sudah membersihkan banyak kiriman yang mencurigakan, tetapi banyak lab merilis hasil yang mengakali apa yang sebenarnya ingin diukur pada tugas tertentu dengan mengubah batas waktu atau konfigurasi hardware
    Selain itu ada juga kecurangan di level execution harness, reward hacking oleh model, dan sebagainya. Yang masih mengganggu saya bahkan setelah beberapa bulan adalah kiriman resmi gpt-5.5, khususnya tugas ini: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
    Batas waktu tugas menurut https://github.com/harbor-framework/terminal-bench-2/blob/ma... adalah verifier 1200 detik, agent 1200 detik, environment build 600 detik, jadi tidak ada agent yang boleh melewati 3000 detik. Tetapi dari 5 percobaan pada tautan di atas, 2 di antaranya jauh melampaui 3000 detik dan masing-masing memakan waktu 75 menit dan 80 menit. Meski gagal, tetap mencurigakan bahwa proses itu berjalan selama itu. Ini contoh bekerjanya Hukum Goodhart
    • Bahkan kalau pun seseorang tidak melakukan “kecurangan” menurut definisi tertentu, benchmark itu sendiri sudah masuk ke dalam suatu gradient descent struktural yang sangat besar. Model pada tingkat mana pun adalah mesin untuk memaksimalkan skor benchmark, jadi benchmark itu sendiri pada dasarnya tampak agak tidak berguna
      Melakukan benchmarking pada manusia juga tidak terlalu berhasil. Kemampuan coding hanya bisa diukur dengan cukup baik jika berinteraksi langsung. Jika model pada dasarnya adalah simulator manusia, maka justru aneh berharap benchmark akan terus berguna ketika simulasinya makin akurat. Pada akhirnya ini hanya versi lebih panjang dari “Hukum Goodhart” yang disebut di atas, dan itu benar-benar bekerja seperti hukum
  • Pada dasarnya, bukankah kesimpulannya adalah bahwa tugas yang diberikan kepada software developer sering kali tidak lengkap atau saling bertentangan, baik untuk manusia maupun model, atau bahkan lebih buruk dari itu? Alat ini memang harus bekerja di dunia seperti itu, jadi saya tidak terlalu bersimpati
    • Setuju. Mencantumkan prompt yang tidak memadai sebagai kegagalan alat terasa kurang meyakinkan. Bahkan intern pun, dengan sedikit bantuan, bisa memahami permintaan yang ambigu dan tahu kapan harus berhenti untuk bertanya alih-alih terus memaksa jalan. Bahkan sebelum masa magangnya selesai, mereka sering kali sudah bisa menangani tugas ambigu dengan cukup mandiri
      Jadi logikanya, model mutakhir itu bahkan bukan junior engineer, melainkan intern bulan pertama yang tidak punya kemampuan untuk melampaui level itu?
    • Dalam pekerjaan nyata, Anda bisa melihat test case yang gagal lalu memperbaiki kodenya, atau yang lebih mungkin, memperbaiki test yang ditulis berantakan. Kalau LLM terbaru diizinkan melakukan langkah pertama itu saja, benchmark khusus ini akan mereka kuasai dengan sangat mudah
      Yang menarik adalah bagaimana LLM bisa menembus 70%+ pada benchmark semacam ini, atau menjawab benar sebagian pertanyaan yang disusun dengan buruk. Apakah mereka secara implisit mempelajari gaya penulis test? Apakah solusinya bocor ke data pelatihan?
      Meski begitu, cukup melegakan bahwa bahkan Fable pun tampaknya mentok di sekitar 72% pada set tersembunyi yang tidak dipakai OpenAI untuk menjalankan analisis ini. Sepertinya mereka tidak mempelajari benchmark itu sendiri kecuali dengan cara yang sangat tidak langsung
      Model open kecil tidak akan pernah bisa mempelajari kebiasaan aneh seperti ini, jadi cara yang baik untuk menilai model secara adil benar-benar penting. Selain itu OpenAI agak mengaburkan keadaan, karena hanya sekitar 20% masalah yang rusak dengan cara yang tidak adil bagi agent, dan 4–10% rusak dengan arah yang menguntungkan, jadi batas atas benchmark ini mungkin lebih dekat ke 80–85%
    • Inti yang lebih halus adalah kesenjangan antara tugas dan verifikasi. Misalnya, jika prompt bersifat terbuka atau tidak cukup terdefinisi, verifier harus mampu menangani semua solusi yang mungkin
      Karena itu prompt tugas yang sangat sempit mudah diverifikasi, tetapi kemungkinan terlalu sederhana sebagai tantangan. Sebaliknya, prompt tugas yang lebih realistis jauh lebih sulit diverifikasi, dan membuat verifier yang tangguh serta menjalankannya dengan murah juga sulit
    • Saya juga memikirkan hal yang sama, dan menurut saya ini terutama benar untuk persyaratan tak terlihat yang tidak dinyatakan di awal dan hanya muncul di dalam test. Harus mengutak-atik ulang solusi untuk menangani persyaratan yang tak seorang pun beri tahu? Saya juga benar-benar melakukan itu di dunia nyata
      Tentu saja itu berarti menguji sesuatu yang berbeda dari klaim benchmark, tetapi kadang secara kebetulan justru menguji sesuatu yang lebih dekat ke realitas daripada benchmark yang rapi, jadi dalam arti itu tetap bermakna
      Namun, itu hanya berlaku ketika agent bisa melihat test yang gagal dan melakukan iterasi. Jika tidak, itu cuma masalah. Dan lebih buruk lagi bila detail implementasi dari solusi tertentu ditanamkan ke dalam test sehingga menuntut struktur internal yang sepenuhnya arbitrer. Di dunia nyata Anda tidak menghadapi situasi seperti itu
  • Kalau dilihat dari angkanya di sini, seluruh benchmark tampaknya terdiri dari kurang dari 800 tugas. Beberapa engineer bisa meninjaunya dalam seminggu, dan pada akhirnya itulah yang dilakukan OpenAI di sini

Di satu sisi, patut dipuji karena benar-benar melakukan pekerjaan itu. Di sisi lain, ini persis seperti pepatah garbage in, garbage out. Agak memalukan juga bahwa para penulis asli tidak benar-benar memverifikasinya, dan memalukan pula bahwa semua pihak di hilir juga tidak memverifikasinya. Selain itu, dari tulisannya terlihat bahwa LLM memang menemukan masalah, tetapi cenderung meremehkan masalah yang ditemukan oleh insinyur perangkat lunak profesional

  • Jika dilihat ke dalam, benchmark pada umumnya ternyata cukup buruk
    Sebagai latar belakang, saya sedang berulang kali menyempurnakan agen supervisor untuk menggantikan berbagai prosedur merepotkan yang diperlukan saat memakai Codex/Claude Code, dan baru-baru ini saya menjalankan agen ini pada Terminal Bench 2.1
    Awalnya saya senang. Soalnya supervisor berbasis spesifikasi ini lebih baik daripada Codex dasar di beberapa tugas. Tapi setelah ditelusuri lebih jauh, ternyata tugas-tugasnya sendiri penuh masalah
    Intinya, instruksinya sering ambigu, sementara test case-nya terlalu spesifik. Misalnya, configure-git-webserver memakai ungkapan seperti “so that I can run”, sehingga batas antara apa yang harus disediakan agen dan apa yang harus dihapus menjadi kabur. Agen yang terlalu banyak berpikir akan menyiapkan server lalu menyimpulkan bahwa jika pengguna menjalankan perintah yang sama akan terjadi konflik, sehingga ia malah menghapus file-file persis yang diperiksa oleh validator
    make-mips-interpreter menyisakan /tmp/frame.bmp yang dihasilkan karena frasa “I will check that you booted doom correctly” ditafsirkan supervisor sebagai pengguna akan memeriksa hasil boot yang dilakukan agen, bukan memeriksa apakah Doom bisa boot secara mandiri. Validator akan berhenti jika /tmp/frame.bmp sudah ada, jadi ia tidak bisa memulai Doom, dan juga tidak memeriksa apakah file itu dibuat ulang selama proses boot[0]
    Dalam mcmc-sampling-stan, agen supervisor sering mencapai nilai yang benar, tetapi menampilkan output numerik yang spesifik domain dalam notasi ilmiah alih-alih desimal biasa. Validator salah mem-parsing hasilnya sehingga gagal[1]
    Ketidakselarasan seperti ini hanya sebagian saja, dan karena itu saya menganggap Terminal Bench 2.1 sudah jenuh, serta hasil GPT-5.6 dan Mythos, masing-masing 88.8% dan 88%, sudah hampir mencapai batas atas yang masuk akal. Masalah terbesarnya adalah kebanyakan benchmark merupakan eksekusi sekali jalan, dan hampir tidak menguji model+harness dalam pekerjaan iteratif panjang, padahal itulah cara utama pengguna nyata memakai alat
    [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
    [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

  • Bukankah sejak awal semua orang sudah tahu bahwa SWE-Bench secara keseluruhan memang cacat? Bahkan para penulisnya sendiri mengakui keterbatasannya dan sudah lama beralih ke tahap berikutnya

    • SWE-Bench Pro dibuat untuk menggantikan SWE-Bench dan memperbaiki masalah-masalah seperti ini

  • Saya paham kenapa ini bisa menjadi benchmark yang buruk, tetapi kalau masalahnya adalah pengujian yang terlalu ketat memaksakan detail implementasi tertentu yang tidak disebutkan di prompt sehingga kiriman yang secara fungsional benar jadi tidak sah, prompt yang kurang memadai melewatkan persyaratan yang sebenarnya dipaksakan oleh hidden test tetapi tidak bisa disimpulkan secara wajar, test dengan cakupan rendah kurang memeriksa fitur yang diminta sehingga perbaikan yang tidak lengkap bisa lolos, dan prompt yang menyesatkan mendorong model ke perilaku yang salah atau bertentangan dengan tuntutan test, maka jika tujuannya adalah membandingkan insinyur perangkat lunak nyata dengan model, ini justru situasi yang cukup realistis
    Mirip seperti membuat ujian perawat lalu menandai beberapa soal karena ternyata perlu menanyakan informasi tambahan yang tidak ada di chart kepada dokter penanggung jawab, atau karena keluarga pasien tidak menjelaskan riwayat medis nenek lanjut usia itu dengan cukup lengkap. Kita tentu bisa menginginkan benchmark yang lebih ketat, tetapi jika OpenAI menjanjikan model sebagai pengganti pekerja nyata, ini bukan gambaran yang buruk. Justru hal-hal seperti inilah yang seharusnya ingin diuji

  • Ini terbaca seperti, “kami sudah melakukan semua pekerjaan yang diperlukan untuk memperbaiki benchmark, lalu pada akhirnya memutuskan untuk membuang benchmark itu.” Apakah data dasarnya sedemikian berharga sehingga tidak bisa ditambal? Di bagian akhir memang disarankan pendekatan yang sedikit lebih selektif untuk membuat benchmark, tetapi menurut saya cara menambal secara adil test yang berantakan dan tidak sempurna yang diambil dari data dunia nyata juga merupakan jalur yang cukup kokoh

    • Bagi saya ini terdengar seperti ada alasan lain untuk menjauh dari SWE Bench Pro, tetapi tidak ingin mengatakannya. Di awal tulisan disebut “sekitar 30% tugasnya rusak”, tetapi itu juga berarti sekitar 70% tidak rusak, dan angka segitu terlihat cukup lumayan
      Akan lebih baik kalau mereka juga memberi tahu “daftar instance yang rusak ada di sini” atau “subset SWE Bench Pro yang akan kami gunakan ke depan adalah ini”. Mereka membiarkan kesempurnaan menghalangi sesuatu yang sudah baik
    • Menunjukkan masalah, misalnya mengatakan bahwa hidden test mengasumsikan detail implementasi yang sempit, jauh lebih mudah daripada membuat test yang bekerja untuk pilihan implementasi apa pun
    • Kalau itu diperbaiki, bukankah itu bukan lagi SWE-Bench Pro? Itu akan menjadi “SWE-Bench-Pro-Fixed-OpenAI”. Jika memikirkan citra independensi benchmark, tampaknya lebih baik pihak ketiga yang memperbaikinya dan merilis versi yang ditingkatkan, daripada tim OpenAI yang langsung memperbaikinya
      Namun OpenAI memang melakukan hal seperti itu saat merilis SWE-Bench Verified, jadi bisa saja saya hanya ngomong ngawur

  • Saat ini, apa yang seharusnya dianggap sebagai state of the art untuk benchmark SWE?

    • Tergantung tujuan dan kebutuhan masing-masing orang, saya akan menyebut DeepSWE[0] atau FrontierCode[1]. Yang kedua secara pribadi lebih menarik bagi saya karena dirancang untuk sangat menilai mergeability, yaitu apakah output yang diberikan mudah direview dan apakah pengembang serius akan mudah memahaminya serta bersedia menggabungkannya
      Dalam pandangan dan penilaian pribadi saya sejak lama, meskipun batas atas potensial sebuah model lebih tinggi, nilainya tetap terbatas jika saya sendiri tidak yakin bisa benar-benar memberi persetujuan final pada kode itu
      [0] https://deepswe.datacurve.ai/
      [1] https://cognition.com/blog/frontier-code-1.1
    • Secara umum saya melihat DeepSWE[0] cukup selaras dengan kenyataan
      [0]: https://deepswe.datacurve.ai/

  • Ada https://cognition.ai/blog/frontier-code. Sebagai pengungkapan, saya pernah berada di tim tersebut, tetapi di sana kami juga membahas masalah swebench pro/deepswe

    • FrontierBench

  • Mencapai AGI harus berarti lebih dari sekadar lolos semua benchmark, dan juga harus mempertimbangkan masalah yang belum diketahui

    • Jika tidak ada sesuatu di dalam lab penelitian yang saat ini sangat berbeda dari produk yang ada, maka AGI bukanlah topik yang layak dibahas dan lebih mendekati gembar-gembor pemasaran belaka
    • AGI masih sangat jauh. Kecuali kalau ada istilah pemasaran LLM yang tidak saya ketahui dan menyebut omong kosong itu sebagai “AGI”. Kecerdasan umum buatan sangat berbeda dari LLM atau AI gambar, sehingga selain sama-sama artefak buatan, keduanya bahkan tidak layak dibandingkan. AGI harus melakukan jauh lebih banyak daripada sekadar prediksi token
    • Ini terhubung dengan trade-off bias-variance(https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff) yang umum saat membuat model non-LLM
      Solusinya hanya a) membuat LLM lebih kecil dengan kinerja yang serupa agar tidak bisa menghafal atau mengincar benchmark, atau b) membuat benchmark yang mencakup seluruh data dunia nyata, tetapi yang terakhir tidak mungkin diwujudkan