Odc. 3: Testowanie rozwiązań AI | #TestArchitectsTalk

Więc we wszystkich tych trzech pozostałych fazach testowanie jest jak najbardziej obecne. Musimy zapewnić w przygotowaniu danych, że te dane, raz, że będzie ich wystarczająca ilość, że one będą spójne, Jeśli dane będą śmieciowe na wejściu, to na wyjściu też dostaniemy śmieci, jak zapytamy później nasz model. Jeśli chodzi o ewaluację, to tutaj mamy W zasadzie tak na dobrą sprawę już przygotowane KPI, po których oceniamy ten model. Możemy też jeszcze dodatkowo ocenić wydajność tego modelu, czyli szeroko rozumiany performance.

Tutaj mamy klasyczne testowanie zbiorów danych. I możemy napisać po prostu jakieś nawet proste czeki, które sprawdzą, że wszystkie dane będą zawierały wszystkie pola. Wtedy odrzucić te, które ich nie zawierają lub jak Tomek wspomniał właśnie, możemy po prostu je dodać w jakiś sposób, czy też te dane się w jakiś sposób anonimizuje, więc to podlega też procesowi automatyzacji. Jeśli chodzi o te pozostałe fazy, no to też moglibyśmy zastosować podział Testowanie funkcjonalne i niefunkcjonalne. O performance'ie już trochę wspomnieliśmy, więc jak tylko mamy jakąkolwiek wersję, to zazwyczaj jest jakieś API do interakcji, więc mamy klasyczne testy performance'u, które są znane.

Możemy mu tylko powiedzieć, że chcemy, żeby to był JSON, ale on sobie wtedy wymyśli. Jak nazwać pola, w jakiej kolejności je pokazać, jak to sobie pozagnieżdżać. Natomiast możemy też mu podać przykład albo kilka przykładów. Powiedzieć, że chcemy, żeby odpowiedzi wyglądały dokładnie tak. No i tutaj znowu testy integracyjne, bo to może być używane do tego, żeby rozmawiać z jakimś zewnętrznym API. Więc możemy się na to jakby albo mockować to API, no jakby techniki tutaj z zakresu automatyzacji musimy dobrać jakby do problemu, który chcemy rozwiązać, no ale też ewidentnie jest i będzie co robić dla automatyków. Dlaczego też mówimy o samym function calling?