Czy sztuczna inteligencja rozumie, że ramen to nie pho? Zmierzyliśmy to na 50 polskich nazwach dań

Jak działa FoodMatch · 9 października 2026

FoodMatch musi umieć jedną rzecz: ocenić, czy dwa dania są do siebie podobne. Bez tego nie ma ani uczenia się z przesunięć w prawo, ani sensownej następnej karty, ani wyjaśnienia „pokazujemy to miejsce, bo polubiłeś tonkotsu”.

Oczywistym pomysłem było użycie modeli, które zamieniają tekst w wektor i mierzą podobieństwo — tej samej technologii, która stoi za wyszukiwaniem semantycznym. Zbudowaliśmy więc test i zmierzyliśmy, jak radzą sobie na polskich nazwach dań. Ten tekst to zapis wyniku, który kazał nam wyrzucić pierwotny plan, i opis tego, co weszło na jego miejsce.

Test: trzy dania, jedno pytanie

Przygotowaliśmy 50 trójek. Każda to danie wzorcowe, danie do niego podobne i danie wyraźnie inne. Zadanie dla modelu jest minimalne: wskazać, które z dwóch jest bliższe wzorcowi. Człowiek odpowiada bezbłędnie; rzut monetą daje 25 na 50.

W trójkach celowo umieściliśmy pułapki leksykalne — pary, które dzielą słowo, ale nie smak. Tarta cebulowa i tarta cytrynowa mają wspólny wyraz i nic wspólnego na talerzu. Ramen, pho i laksa to trzy różne zupy z makaronem, które w opisach wyglądają niemal identycznie. Dodatkowo zrobiliśmy zestaw kontrolny: 20 trójek łatwych, gdzie różnica jest ewidentna (danie mięsne kontra deser).

Wyniki

Najlepszy wynik to 31 na 50. Trzy modele wypadły poniżej rzutu monetą. Przy pięćdziesięciu próbach taka różnica mieści się w granicach przypadku — co znaczy, że żaden z tych modeli nie rozstrzyga naszego zadania.

Zestaw kontrolny pokazał, że modele nie są zepsute: na łatwych trójkach trafiały 13–16 na 20. Potrafią odróżnić zupę od ciasta. Nie potrafią odróżnić zupy od innej zupy — a cała wartość rekomendacji jedzenia siedzi dokładnie w tym drugim.

Dlaczego tak wyszło

Model do mierzenia podobieństwa tekstu jest uczony na tym, o czym jest tekst. Dla niego „ramen tonkotsu” i „pho bo” to dwa teksty o azjatyckiej zupie z makaronem: ten sam temat, ten sam rejestr, podobna długość, podobne otoczenie słów w danych uczących. To, że jedna jest na bulionie z kości wieprzowych, a druga na wołowym wywarze z anyżem, nie jest różnicą tematu — jest różnicą dania.

Nasze zadanie wymaga rozróżnień, które w tekście prawie nie zostawiają śladu: rodzaj bulionu, ostrość, konsystencja, technika obróbki. Nazwa dania w menu to trzy słowa i żadne z nich tego nie mówi.

Co weszło na to miejsce: cechy zamiast wektorów tekstu

Zamiast szukać podobieństwa w zdaniach, opisujemy każde danie zamkniętym zestawem cech — takich, które dla jedzenia naprawdę coś znaczą.

Cechy wypełnia model językowy, raz, poza aplikacją — i to jest zupełnie inne zadanie niż poprzednie. Nie pytamy go, czy dwa dania są podobne (tego, jak widać wyżej, modele nie wiedzą). Pytamy, co jest w daniu, i każemy odpowiedzieć wyłącznie słowami z naszego słownika; odpowiedź spoza słownika odrzucamy po swojej stronie. Do modelu idzie tylko treść menu: nazwa, opis, etykiety. Żadnych danych o ludziach.

Dwie rzeczy, które z tego wyszły niespodziewanie:

• Jest to tanie. Katalog ma dziesiątki tysięcy pozycji, ale unikalnych par nazwa plus opis jest 543 — menu powtarzają te same dania. Całość to kilkadziesiąt zapytań.
• Cechy naprawiają błędy etykiet. Danie opisane jako „kofta z jagnięciny”, ale omyłkowo oznaczone etykietą „wołowina”, w przestrzeni samych etykiet było bliźniakiem kebaba wołowego. Po dołożeniu cech przestało nim być.

Jest też cena: zamknięty słownik trzeba utrzymywać, a każda jego zmiana oznacza przeliczenie katalogu od nowa. Zyskujemy w zamian coś, czego wektor tekstu nie daje — cechy da się przeczytać. To z nich powstaje zdanie „bo polubiłeś tonkotsu”, które widzisz przy propozycji.

Jak z przesunięć powstaje profil smaku

Każde przesunięcie karty to jeden dowód, a nie wyrok. Profil smaku trzymamy więc jako wartość plus niepewność dla każdej cechy — i ta druga liczba robi tu całą robotę, bo pozwala odróżnić „nie wiemy” od „jest Ci to obojętne”. Bez niej te dwa stany wyglądają identycznie: zero.

Z tego wynikają trzy zachowania aplikacji:

1. Pierwsza karta jest niemal w całości z profilu, piętnasta — z dzisiejszej sesji. Waga tego, co o Tobie wiemy z historii, maleje z każdym przesunięciem; to, na co masz ochotę teraz, przejmuje stery. Bo apetyt jest stanem, nie cechą charakteru.
2. Następną kartę wybiera telefon, a nie serwer: z puli kandydatów bierze tę, która najwięcej rozstrzyga. Jeśli nie wiemy, czy lubisz ostre, dostaniesz coś ostrego — i to jest dokładnie ten moment, w którym aplikacja uczy się najwięcej.
3. Ankieta na wejściu jest wskazówką, nie wyrokiem. Jej odpowiedzi ustawiają punkt startowy z wysoką niepewnością, więc pierwsze sesje mogą ją swobodnie poprawić.

Uczciwie: w samym przewidywaniu „czy przesunie w prawo” nowy model wypadł tak samo jak stary — 0,597 wobec 0,594 na kartach od ósmej do piętnastej. Remis. Przewaga nowego podejścia leży w wyborze kart, w starcie bez danych i w czytelności wyjaśnień, a nie w samej trafności. Piszemy to, bo pomiar, który wypada po naszej myśli, i tak trzeba podać razem z tym, który nie wypadł.

Dlaczego na końcu widzisz trzy miejsca, a nie trzydzieści

Wynik sesji to nie sama zgodność smaku. Każde miejsce dostaje ocenę złożoną z dopasowania (dominuje), jakości, odległości i świeżości — a lokal zamknięty w godzinie, w której chcesz jeść, wypada od razu. Na koniec druga i trzecia propozycja są karane za podobieństwo do pierwszej, żeby wynikiem nie były trzy ramenownie obok siebie. Chyba że cała sesja jednoznacznie prosi o ramen — wtedy kara znika.

Trzy, bo wybór z trzech opcji jest decyzją, a wybór z trzydziestu — zadaniem. Napisaliśmy o tym osobno, z badaniami w ręku: paraliż wyboru przy obiedzie.