Kebanyakan kotak carian wujud untuk menjawab satu soalan: apa yang sepadan dengan perkataan yang saya taip? Itu soalan yang betul untuk katalog perpustakaan. Ia soalan yang salah untuk aplikasi pemakanan.
Apabila pengguna membuka halaman resipi dalam Appetec, perkataan yang mereka taip adalah bahagian yang paling kurang menarik dalam permintaan. Apa yang sebenarnya penting adalah tidak kelihatan: kalori yang tinggal hari ini, apa yang mereka masak minggu demi minggu tanpa memikirkannya, sama ada mereka vegan, dan sama ada mereka sudah melebihi bajet mereka sebelum makan malam. Enjin carian yang mengabaikan semua itu akan dengan senang hati mengembalikan resipi yang sepadan — dan sama senang hati mensabotaj sebab pengguna membuka aplikasi. Ini adalah seni bina di sebalik corak yang dibina untuk merapatkan jurang itu: perkaitan yang tepat untuk orang ini, sekarang ini.
Mengapa Padanan Teks Sahaja Tidak Cukup
Corak ini terpakai apabila pertanyaan yang sama harus mengembalikan hasil yang berbeza untuk pengguna yang berbeza — apabila "terbaik" bergantung pada konteks yang tidak pernah ditaip oleh pengguna, dan apabila katalog yang anda miliki lebih kecil daripada katalog yang dijangkakan oleh pengguna anda. Carian resipi diperibadikan menganggap perkaitan sebagai gabungan tiga isyarat dan bukannya satu:
| Isyarat | Apa Yang Ditangkap |
|---|---|
| Teks | Apa yang ditaip oleh pengguna — atau, dalam mod imbasan hidangan, apa yang dikesan di atas pinggan mereka |
| Kesesuaian Matlamat | Sejauh mana resipi sesuai dengan kalori yang tinggal untuk pengguna untuk hidangan ini, hari ini |
| Tabiat | Seberapa kerap pengguna khusus ini sebenarnya memakan resipi ini |
Enjin yang naif hanya melihat baris pertama jadual itu. Corak ini menggabungkan ketiga-tiga menjadi satu senarai yang tersusun, kemudian mengisi dari sumber luaran apabila katalog tempatan berkurangan — secara senyap mengembangkan katalog itu setiap kali ia berlaku. Hasilnya terasa kurang seperti menyoal pangkalan data dan lebih seperti seorang rakan yang sudah mengenali dapur dan diet anda.
Bagaimana Saluran Paip Dibina
Sistem ini berjalan sebagai saluran paip pengambilan dengan lapisan peribadi di hadapan dan katalog pemulihan diri di belakangnya.
Dua enjin carian, satu kontrak. Elasticsearch adalah utama: toleransi ralat taip kabur, pengecaman akar perkataan Inggeris ("grill" menemui "grilled"), pemarkahan perkaitan berwajaran. Jika ia tidak tersedia, pertanyaan yang sama akan jatuh kepada carian MongoDB yang mematuhi penapis dan peraturan peribadi yang sama. Carian merosot di bawah kegagalan; ia tidak pernah hilang.
Lapisan yang dirasakan pengguna tetapi tidak pernah dilihat. Sebelum hasil dikembalikan, tiga perkara membentuk semula senarai. Bajet kalori dikira daripada sasaran harian tolak apa yang dicatat, meningkatkan resipi yang sesuai dengan baki yang ada — dan jika pengguna telah melepasi sasaran mereka, senarai itu secara senyap menyusun semula kalori terendah dahulu, mendorong ke arah pemulihan dan bukannya memanjakan diri. Sejarah pemakanan menyaring log hidangan 60 hari terakhir menjadi peta "apa yang anda sebenarnya makan", memastikan kegemaran hanya satu sentuhan sahaja di halaman pertama. Keutamaan diet — veg, vegan, non-veg, serta dua dozen tag yang lebih halus seperti keto, gluten-free, dan high-protein — menapis dan menyusun semula segala-galanya di bawahnya.
Katalog yang berkembang dengan sendirinya. Apabila hasil tempatan berkurangan, saluran paip menelusuri sumber luaran, FatSecret, menyatukan hasil tersebut ke dalam suapan tatal tanpa henti yang sama tanpa kelihatan sambungan. Ia kemudian menulis resipi luaran tersebut kembali ke katalog tempatan, menggunakan LLM untuk mengklasifikasikan setiap satu sebagai veg, non-veg, atau vegan, supaya ia boleh diperibadikan dengan betul pada masa akan datang — naluri yang sama di sebalik seni bina pengambilan hibrid yang telah kami gunakan di tempat lain, di mana hasil tempatan dan luaran perlu terasa seperti satu sistem.
Tiga cache, tiga tugas. Set hasil gabungan, peta tabiat setiap pengguna, dan respons API luaran masing-masing membawa jangka hayat bebas mereka sendiri, jadi pertanyaan berbilang sumber yang diperibadikan masih kembali pada kelajuan yang lebih kurang sama dengan carian mudah tunggal.
Pertukaran Yang Patut Dinamakan
Tiada apa-apa daripada ini datang secara percuma, dan jujur mengenai kos adalah sebahagian daripada apa yang menjadikan corak ini boleh dipercayai dan bukannya hanya pandai.
Perkaitan sengaja dibuat tidak neutral. Kedudukan perkaitan teks semata-mata adalah "adil" dengan cara yang secara aktif tidak membantu di sini. Hasilnya sengaja berat sebelah ke arah kesesuaian matlamat dan tabiat, kerana resipi yang sedikit kurang sempurna dari segi teks tetapi sesuai dengan bajet dan selera seseorang adalah jawapan yang lebih baik. "Mengapa ini menduduki tempat pertama?" menjadi keputusan produk, bukan tetapan lalai enjin carian — sebab itulah pemberat tersebut berada dalam kod aplikasi, bukan fail konfigurasi yang tidak dimiliki.
Memiliki keseluruhan katalog bukanlah matlamat — memiliki bahagian yang betul daripadanya adalah matlamat. Pilihan ekstrem yang dipertimbangkan ialah katalog yang dikurasi sepenuhnya (kualiti tinggi, liputan sempit) atau proksi penuh kepada API luaran (liputan tanpa had, kawalan sifar, personalisasi sifar). Sistem ini membahagikan perbezaannya: mendahului dengan resipi yang dimiliki dan dicipta oleh pengguna, mengisi dari luar apabila diperlukan, dan menyerap apa yang diisi semula — cenderung, dari masa ke masa, ke arah memiliki dengan tepat apa yang sebenarnya dicari oleh pengguna.
Ketahanan dipilih mengatasi kecekapan puncak. Dua enjin carian penuh lebih mahal untuk dikendalikan daripada satu — pemikiran mengutamakan ketahanan yang sama di sebalik kebanyakan keputusan backend kami. Kos itu diterima dengan sengaja: carian resipi adalah fungsi teras, penggunaan harian, di mana carian yang terdegradasi adalah gangguan kecil tetapi carian yang hilang adalah aplikasi yang rosak.
Personalisasi mengorbankan kebolehramalan. Hasil benar-benar berbeza mengikut waktu hari, kalori yang diambil, dan sejarah — walaupun untuk pengguna yang sama pada sarapan berbanding makan malam. Itu disengajakan, tetapi ia meningkatkan taraf untuk pengujian dan sokongan: "ia berfungsi pada telefon saya" tidak lagi bermakna banyak apabila ketepatan ditakrifkan setiap pengguna, setiap saat.
Bila Corak Ini Sesuai — dan Bila Tidak
Adalah penting untuk menjelaskan bila corak ini tidak sepatutnya digunakan. Ia mencapai kerumitannya apabila hasil harus benar-benar berbeza bagi setiap pengguna berdasarkan konteks yang tidak pernah mereka taip, apabila katalog yang dimiliki lebih kecil daripada jangkaan pengguna tetapi boleh diperkaya secara luaran, apabila ciri tersebut cukup kerap sehingga degradasi yang anggun lebih penting daripada infrastruktur minimum, dan apabila "relevan" secara sah termasuk isyarat di luar teks.
Ia adalah alat yang salah apabila hasilnya sama untuk setiap pengguna — carian dokumen awam, carian SKU — di mana personalisasi menambah kos tanpa pulangan. Ia tidak diperlukan apabila katalog cukup kecil dan stabil sehingga satu enjin dengan penapisan biasa mencukupi, dan ia merugikan anda di mana-mana sahaja kedudukan yang ketat, sama, dan boleh dijelaskan sepenuhnya adalah keperluan yang sukar.
Tugas Sebenar
Kualiti pengambilan di sini dianggap sebagai masalah personalisasi, bukan hanya masalah padanan. Carian resipi yang sempurna dari segi teks tetapi mengabaikan bahawa pengguna adalah vegan, sudah melebihi bajet, dan telah memasak lima hidangan makan malam yang sama sepanjang bulan secara teknikalnya berjaya tetapi secara praktikalnya gagal. Tugas itu tidak pernah untuk mencari resipi yang sepadan dengan pertanyaan — ia adalah untuk mengetengahkan resipi yang patut dimasak oleh orang ini seterusnya. Setiap lapisan seni bina ini, daripada enjin carian dwi kepada penyusunan semula secara senyap apabila seseorang melebihi bajet, wujud untuk merapatkan jurang itu.
Jika anda sedang menimbang keputusan bina-vs-gabung yang serupa untuk carian atau pengambilan dalam produk anda sendiri, kami sedia berbincang.
Blog Lain
1. Penskalaan Platform Kesihatan Digital dengan Microservices
