Geekly articles weekly

Proyek MCDM. Bagian 1. Konsep


Kata Pengantar


Tetap saja, saya seorang pemimpi dan pemimpi dalam jiwa saya, pada kenyataannya (di dunia pemrograman) maksimum adalah "pria dari garasi", tetapi setelah "melonggarkan mur" saya tidak bisa menolak ide untuk menunjukkan Proyek-MCDM secara keseluruhan dan proyek mainan. versi uji pada khususnya (Saya agak takut dengan Habraeffect, jika ada masalah - kami mohon maaf). Tautan ke situs web proyek menunggu pembaca di akhir publikasi (bersama dengan survei), disarankan untuk pergi melalui tur yang ditawarkan di situs web untuk sosialisasi, dan idealnya, membiasakan diri dengan ide-ide utama di bawah potongan.

Mengapa nonlinier?


Cerita ini dimulai dengan serangkaian publikasi tentang topik penilaian multi-kriteria objek dengan parameter longgar (tidak jelas terhubung) dan bekerja dengan para ahli yang seharusnya merumuskan aturan untuk mengevaluasi objek yang sedang dipertimbangkan. Cukup cepat menjadi jelas bahwa tidak mungkin untuk menggunakan kriteria evaluasi linear ketika bekerja dengan para ahli. Manusia berpikir secara non-additif. Bayangkan Anda akan memilih laptop (contoh ini harus sangat dekat dengan publik dari Habr) dan mempertimbangkan beberapa opsi spesifik (menyederhanakan banyak fitur): biarlah i5 dengan frekuensi 3 GHz, 8 GB RAM, dan kartu video seri 10 dengan memori 4 GB . Asumsikan bahwa alternatif yang tersedia untuk pembelian (dengan anggaran yang sama) adalah sebagai berikut:

  1. i5 dengan frekuensi 3GHz, 8GB RAM, dan kartu video seri 10 dengan memori 4GB;
  2. i5 dengan frekuensi 3,5 GHz, 4 GB RAM, dan kartu video dari seri 10 dengan 4GB memori;
  3. i5 dengan frekuensi 2,5 GHz, 8 GB RAM, dan kartu video seri 10 dengan 6 GB memori;
  4. i5 dengan frekuensi 3,5 GHz, 8 GB RAM, dan kartu video seri ke-10 dengan memori 2GB.

Harap dicatat bahwa dalam contoh ini, semua nilai parameter berubah secara linear (menurunkan / meningkatkan nilai satu parameter dengan konstanta relatif ke versi referensi mengarah ke peningkatan / penurunan parameter lain oleh konstanta lain). Tetapi apakah ini berarti bahwa preferensi Anda tetap tidak berubah? Tidak semuanya! Dengan diskon, Anda selalu dapat menunjukkan opsi yang paling disukai untuk diri sendiri, yang artinya peringkatnya lebih tinggi daripada yang lain. Melanjutkan pemikiran, mari kita buktikan dengan contoh ini bahwa kriteria linear preferensi untuk mengevaluasi alternatif juga tidak cocok. Misalkan ini bukan masalahnya. Sebagai contoh, kami akan memilih laptop untuk bekerja (mis., Kami tidak berharap untuk bermain, tetapi untuk perhitungan kami tertarik dengan kinerja dan RAM). Kami akan memperkenalkan opsi baru: i5 dengan frekuensi 3,5 GHz, 16 GB RAM, dan kartu video dengan memori 0 GB. Kami membedakan tiga alternatif (penomoran dipertahankan untuk kemudahan persepsi):

2) i5 dengan frekuensi 3,5 GHz, 4 GB RAM, dan kartu video seri 10 dengan 4GB memori;
4) i5 dengan frekuensi 3,5 GHz, 8 GB RAM, dan kartu video seri 10 dengan memori 2GB;
5) i5 dengan frekuensi 3,5 GHz, RAM 16 GB, dan kartu video dengan memori 0 GB.

Mengingat preferensi kami, No. 5 jelas merupakan alternatif terbaik. Penggunaan kriteria evaluasi linier mengasumsikan bahwa kontribusi suatu unit dari nilai parameter secara linear terkait dengan nilai kriteria (misalnya, meningkatkan parameter dengan satu mengarah pada peningkatan kriteria oleh beberapa unit lain). Dalam hal ini, sementara alternatif No 4 kondisional lebih buruk oleh X, alternatif No 2 harus lebih buruk oleh 2X (kami tidak memperhitungkan kartu video). Tetapi haruskah kita ingin bermain tidak terlalu menuntut permainan setelah bekerja - opsi mana yang harus kita pilih? Di sini saya bisa tidak setuju, tetapi sebagian besar dengan meyakinkan akan memilih alternatif No. 4. Masalahnya adalah bahwa ahli dalam penilaiannya memperhitungkan hubungan implisit dari kontribusi bersama parameter terhadap kualitas alternatif. Jadi, untuk aturan seleksi kami, signifikansi bersama dari frekuensi prosesor dan jumlah RAM lebih penting daripada signifikansi gabungan dari jumlah RAM dan jumlah memori video.

Dalam hal terdapat lebih dari 3 parameter pemilihan, ahli diminta untuk mengevaluasi pengaruh tidak hanya pasangan, tetapi juga tiga kali lipat parameter, dll., Yang mencirikan tidak hanya fleksibilitas pengaturan pencarian untuk alternatif pilihan, tetapi, sayangnya, kompleksitas proses ini untuk seorang ahli (pembentukan ATURAN KOMPLEKS).

Pada saat publikasi artikel, dalam versi pengujian kami hanya ada fungsionalitas dasar, yang juga tidak memungkinkan konfigurasi fleksibel aturan seleksi. Sejauh ini, dibatasi (secara kondisional 1 m) oleh tingkat kerumitan, yang di masa depan akan disebut ATURAN SEDERHANA. Perlu dicatat bahwa aturan sederhana sudah memberikan kenyamanan lebih daripada direktori (yang terkenal) yang ada. Entah kita tidak tahu apa yang ingin kita temukan di katalog, dan kemudian kita dipaksa untuk membalik-balik katalog secara naik turun (sortasi yang digunakan biasanya sederhana - berdasarkan harga, berdasarkan kebaruan, dll.) Mencari sesuatu yang kita sukai, atau kita kami tahu betul apa yang ingin kami temukan, dan kemudian kami menggunakan filter = sangat mempersempit area pencarian, mempertaruhkan pilihan menarik yang hilang yang tidak jauh melampaui area pencarian, tetapi yang mungkin menarik bagi kami, atau dengan membuat banyak klik yang mengganggu, tiba-tiba menyadari bahwa direktori tidak dapat melakukan apa pun tawarkan kami. Yang terakhir ini sedikit lebih sederhana - banyak katalog menunjukkan jumlah opsi ketika menerapkan filter.

Kami menawarkan pendekatan yang menggabungkan penyortiran canggih dan filter jangkauan. Untuk situs katalog, ini berarti melengkapi fungsionalitas yang ada dengan add-on eksternal, yang menangani preferensi pengguna (pembentukan aturan pemilihan, penyimpanan dan penggunaan aturan yang sukses). Di masa depan, direncanakan untuk mengembangkan opsi "all in box", mungkin DBMS berdasarkan prinsip-prinsip baru, tetapi kami tidak akan membahas ini dalam artikel ini.

Dari grading ke grading


Munculnya penyortiran multifaktor adalah karena fakta bahwa aturan seleksi yang dibentuk oleh pengguna (ahli) dapat "digulung" menjadi fungsi nonlinier matematis. Ini berarti bahwa dengan bantuan fungsi seperti itu setiap elemen katalog dapat dievaluasi (setiap elemen katalog diberi tingkat korespondensi dengan preferensi pengguna). Di satu sisi, ini berarti bahwa pada prinsipnya dimungkinkan untuk mengurutkan seluruh katalog sesuai dengan preferensi pengguna (mis., Sehingga item pertama adalah yang paling disukai). Ini sangat menyederhanakan kehidupan pengguna dan harus memiliki efek positif pada peningkatan minat pada situs direktori tersebut. Di sisi lain - itu menyebabkan overhead tambahan untuk penyortiran itu sendiri, tidak memungkinkan untuk membuat pilihan parsial 10-20-50 dan elemen lebih lanjut per halaman. Dan di sini kita tidak memiliki pertanyaan untuk DBMS yang ada. Hal ini secara historis telah terjadi - diperlukan untuk "mengalahkan" poros permintaan pengguna "secara terpisah" ke DBMS secepat mungkin (sehingga pengguna tidak menunggu terlalu banyak). Tapi mari kita berpikir sejenak: dan bukan karena ada begitu banyak permintaan ini sehingga kita tidak dapat menemukan apa yang kita cari menggunakan antarmuka yang ada? Bukankah keinginan untuk membongkar sisi server membuat kita (pengguna) semakin banyak menusuk? Kami membuat persentase besar dari permintaan yang tidak berguna, tetapi apakah kami yang harus disalahkan untuk ini ... Kami menawarkan untuk memungkinkan pengguna untuk membuat permintaan yang kompleks dan dengan jujur ​​memperingatkan bahwa mereka harus menunggu. Mungkin ini cocok untuk Anda secara khusus: lebih sedikit klik dan lebih banyak akal = menghemat energi pada pencarian dan membelanjakannya untuk analisis opsi, dll

Untuk menunjukkan bagaimana metode yang diusulkan bekerja, perendaman dalam praktik diperlukan. Masalah praktis klasik adalah: masalah membeli rumah, masalah memilih mobil, dan beberapa lainnya. Mereka dibedakan oleh sejumlah besar alternatif (dari urutan beberapa ribu) dan jumlah yang relatif kecil (biasanya lima sampai sepuluh) dasar, dalam bentuk umum parameter seleksi yang saling berhubungan lemah. Pada artikel ini kita akan mengandalkan masalah membeli rumah.

Ada banyak katalog real estat, kami menggunakan katalog real estat yang terkenal (tidak ada kepastian bahwa namanya harus ditunjukkan di sini - tautan yang sesuai diposting di situs web proyek) pada pertengahan 2018 lalu dan atas dasar itu kami membentuk katalog bersyarat apartemen untuk iklan penjualan (pasar sekunder) di St. Petersburg. Di sini adalah mungkin untuk menempatkan materi tentang bagaimana parser ditulis, bagaimana mereka "berjalan" melalui halaman katalog di mesin, mengunduhnya, mengeluarkan data iklan dan kesulitan apa yang mereka temui dalam menyusun katalog bersyarat, namun, menurut pendapat kami, bahan ini cukup khas untuk Habr dan tidak mewakili minat khusus dalam terang artikel. Kami hanya mencatat bahwa perlu mengunduh gambar dari direktori sumber tidak sebulan setelah pembentukan direktori kondisional, karena banyak iklan telah dihapus (dijual / dihapus / ...) pada saat itu, yang berarti bahwa sejumlah deklarasi direktori kondisikan sekarang tanpa thumbnail (yang tidak kritis sama sekali, tetapi agak menjengkelkan).

Dalam residu kering


Hari ini kami siap untuk menunjukkan versi uji alfa dengan kemampuan penyortiran dasar menggunakan contoh masalah membeli rumah. Perlu diperhatikan fitur-fitur utama dari fungsionalitas yang disajikan:

  1. Penyortiran diimplementasikan pada sisi klien (browser).
  2. Pembentukan fungsi sortir secara remote terjadi TANPA mengakses direktori. Hanya informasi umum tentang rentang nilai yang mungkin dari parameter objek yang diurutkan yang diperlukan.
  3. Fungsi penyortiran adalah fungsi JS anonim (kasus pembentukan yang sangat jarang dari string "on the fly").
  4. Pengurutan katalog WHOLE mengasumsikan "dijalankan" melalui fungsi anonim (Bagian 3) dari SETIAP item katalog (diterapkan dengan membebani fungsi pengurutan bawaan).

Tur interaktif di situs web proyek akan memberi tahu Anda cara menggunakan fungsionalitas yang diusulkan.

Rencana dan prospek segera


Sejalan dengan pekerjaan pada versi uji alfa (masalah membeli rumah), sebuah pangkalan laptop bersyarat dikumpulkan. Jumlah parameter yang mungkin dibandingkan dengan contoh-contoh dasar di luar grafik! Selain itu, masalah (suatu tempat yang diharapkan) terungkap. Yang pertama adalah bahwa kehadiran berbagai komponen di laptop membuatnya sesuai untuk mengatur beberapa penilaian bersarang. Hal ini disebabkan oleh fakta bahwa prosesor, kartu video dan komponen penting lainnya agak sulit untuk dibandingkan satu sama lain (yang merupakan masalah terpisah), serta fakta bahwa jika Anda membiarkan parameter komponen pada tingkat parameter laptop, jumlahnya akan terlalu besar, dan pengguna (ahli) akan sangat sulit untuk membangun aturan seleksi yang memadai. Masalah kedua adalah bahwa sejumlah parameter pada dasarnya numerik (misalnya, produsen komponen individu, teknologi yang diterapkan di dalamnya, dll., Belum lagi negara perakitan dan informasi formal lainnya yang kurang baik).

Dalam publikasi mendatang, direncanakan untuk membahas secara lebih terperinci proses pembuatan aturan pemilihan COMPLEX dengan fungsionalitas tes interaktif, merencanakan versi pengujian baru dengan pembentukan aturan COMPLEX dan / atau memperkenalkan katalog bersyarat laptop sebagai contoh yang rumit, dan juga mempertimbangkan umpan balik Anda dalam pengembangan proyek selanjutnya. Terima kasih atas perhatian anda! PS kritik konstruktif terhadap ide dan versi uji (demo) dari proyek ini disambut baik :)

UPD : tampaknya server ternyata agak lemah, jika seseorang mendapat "Koneksi error", silakan coba beberapa saat lagi (disarankan untuk me-refresh halaman) ...

Referensi


Situs proyek: mcdm-project.org

Publikasi terkait:

  • Pavlov, AN Teknik Pengambilan Keputusan Multi-Kriteria dalam Studi Masalah Semi-Terstruktur / AN Pavlov, DA Pavlov, AA Pavlov, AA Slin'ko // Prosiding Konferensi Ilmu Komputer Online ke-6 2017 (CSOC2017) . April 2017 .-- Springer International Publishing Switzerland 2017, Vol 2: Aplikasi Sibernetika dan Matematika dalam Sistem Cerdas. P.131-140. DOI 10.1007 / 978-3-319-57264-2_13
  • Pavlov, A.N. Metode gabungan pilihan multikriteria keputusan manajerial berdasarkan model representasi pengetahuan dan perencanaan eksperimen / A.N. Pavlov, A.A. Pavlov, D.A. Pavlov, A.A. Slinko // “Prosiding A.F. Mozhaysky. " - SPb.: VKA mereka. A.F. Mozhaysky, 2017 .-- Masalah. 656. - C. 9-17
  • Pavlov AN, Metodologi dan teknologi analisis multikriteria kekritisan kegagalan elemen fungsional sistem kapal umum / A.N. Pavlov, A.Yu. Kulakov, D.A. Pavlov // Konferensi Ilmiah dan Praktik Internasional Kedua "Simulasi dan Pemodelan Terintegrasi Teknik Kelautan dan Sistem Transportasi Laut" (PCM MTMTS 2013), 3 Juli 2013, St. Petersburg: Prosiding konferensi / OJSC "Pusat Pembuatan Kapal dan Teknologi Perbaikan Kapal" - St. Petersburg , 2013, S. 78-85
  • Pavlov A.N., Zelentsov V.A. Analisis multikriteria tentang pengaruh elemen individu terhadap kinerja sistem yang kompleks // Sistem Informasi Manajemen. - 2010, No. 6 (49), S.7-12
  • Pavlov A.N., Metode gabungan analisis multikriteria kekritisan kegagalan elemen objek kompleks / A.N. Pavlov, V.A. Zelentsov, E.A. Kopytov, // Konferensi Internasional ke-10 “Keandalan dan Statistik dalam Transportasi dan Komunikasi” (RelStat'10), 20–23 Oktober 2010, Riga, Latvia, ISBN 978-9984-818-34-4 - Riga: Transportasi dan Telekomunikasi Institute, hal. 353-360

Source: https://habr.com/ru/post/id443780/

More articles:


All Articles