Fara 1.5: mały model, który pracuje w przeglądarce

Fara 1.5 jest rodziną modeli Microsoft Research do wykonywania zadań przez interfejs przeglądarki. Warianty mają 4B, 9B i 27B parametrów. Publikacja badaczy opisuje cykl obserwacja → rozumowanie → pojedyncza akcja, oparty między innymi na zrzutach ekranu. Repozytorium Fara zawiera kod do eksperymentów, a od lipca 2026 r. zespół udostępnia także wagi modeli na warunkach wskazanych w publikacji.

Co Fara potrafi?

Model może nawigować między stronami, porównywać dane i wypełniać formularze. W zestawie Online-Mind2Web badacze raportują około 63% skuteczności wariantu 9B na 300 zadaniach; to wynik w określonym benchmarku, nie gwarancja dla firmowego CRM. Model uczono również w środowiskach syntetycznych obejmujących logowanie i działania, których nie można bezpiecznie ćwiczyć na publicznych stronach. W MagenticLite Fara pełni rolę wykonawcy czynności w przeglądarce, podczas gdy MagenticBrain planuje i deleguje.

Gdzie leży ryzyko?

Przeglądarka pokazuje treści nieufne: stronę może zmienić dostawca, a dokument może zawierać polecenie dla agenta. Fara widzi to, co pokazuje UI, więc atak typu prompt injection może udawać element zadania. Przed kliknięciem „wyślij”, „kup” albo „usuń” potrzebna jest zgoda oparta na rzeczywistym skutku, nie tylko na przewidywaniu modelu. Hasła i tokeny nie powinny trafiać do promptu; sesję trzeba izolować, a działania rejestrować. Lista OWASP LLM Top 10 daje użyteczne scenariusze testowe.

Alternatywą jest automatyzacja przez API albo regułowy skrypt Playwright. Fara ma przewagę, gdy nie ma stabilnego API, a zadania różnią się od siebie na tyle, że ręczne skryptowanie staje się drogie. API nadal wygrywa tam, gdzie potrzebujemy przewidywalnej transakcji i jasnego kontraktu. W pilocie mierz odsetek ukończonych zadań, liczbę przejęć przez człowieka, błędne kliknięcia i możliwość cofnięcia skutku.

Jak zbudować test, którego nie da się wygrać jednym pokazem?

Przygotuj kilkanaście odmian tej samej pracy: formularz z brakującym polem, stronę o zmienionym układzie, komunikat o błędzie, wymagane logowanie, dwa podobne przyciski i prośbę o działanie nieodwracalne. Za sukces uznaj dopiero stan zapisany w systemie docelowym, nie samo kliknięcie. Jeśli zadanie wymaga zgody, sukcesem może być również poprawne zatrzymanie i pokazanie operatorowi skutku planowanej akcji.

Ważne jest odróżnienie błędu rozpoznania ekranu od błędu decyzji. Model może wybrać prawidłowy cel, ale kliknąć zły element, bo strona się przesunęła. Może też bezbłędnie nacisnąć przycisk, którego nie powinien naciskać. Pierwszy problem bywa naprawialny przez lepszą obserwację lub bardziej stabilne narzędzie. Drugi wymaga ograniczeń zadania, autoryzacji i kontroli człowieka. Log działań powinien pozwalać odtworzyć oba przypadki.

Otwarte wagi są ważne dla organizacji chcących uruchamiać model we własnej infrastrukturze, ale nie oznaczają darmowej eksploatacji. Model computer-use przetwarza obrazy ekranu wielokrotnie w jednym zadaniu, więc pamięć, przepustowość i czas odpowiedzi mają znaczenie. Sprawdź licencję konkretnego wariantu i koszty hostingu, a następnie przetestuj go na rzeczywistym oprogramowaniu firmy bez powierzania mu od razu produkcyjnych uprawnień.

Na koniec porównaj Fara z API: jeśli jedno wywołanie API zapewnia ten sam efekt, zwykle łatwiej je monitorować i wersjonować. Przeglądarka jest narzędziem tam, gdzie interfejs jest jedynym dostępnym kanałem albo zmienność pracy nie pozwala łatwo napisać skryptu.