Vorhersage- und Optimierungsdienste auf der Basis von maschinellem Lernen sind heutzutage für viele Unternehmen von Interesse: von großen Banken bis zu kleinen Online-Shops. Bei der Lösung der Probleme verschiedener Kunden stießen wir auf eine Reihe von Problemen, die als Grundlage für unsere Diskussionen über die Merkmale von ML-Tests dienten. Für Interessierte ist dies unser nächster Beitrag von Sergey Agaltsov, Testmanager von Jet Infosystems.
Bisher konnten nur große Unternehmen das maschinelle Lernen nutzen, da es teuer und schwierig war und nur sehr wenige Daten öffentlich zugänglich waren. Heute ist es viel einfacher geworden. Fachwissen ML kann bei einem Integrator, einem spezialisierten Unternehmen oder an einem thematischen Standort angefordert werden. Das ist gut für alle, denn mit dem Anwachsen des Fachwissens werden neue Algorithmen entwickelt und das „Sparschwein der Erfahrung“ im Bereich des maschinellen Lernens wird ständig bereichert.
Der einzige Aspekt, für den wir keine fertige Lösung gefunden haben, ist das Testen von ML-Diensten. Durch Googeln können Sie sicherstellen, dass in den Suchergebnissen die Aktivitäten von Testern bei der Entwicklung solcher Dienste nicht erwähnt werden. Natürlich testen Data-Science-Experten ihre Modelle selbst anhand verschiedener Metriken, und gemäß diesen Metriken kann der Service sogar so genau wie möglich sein. In der Realität kann das Modell jedoch nicht immer verschiedene Produktionsnuancen und -engpässe berücksichtigen. Dann beginnt die Logik des maschinellen Lernens zu einem Hardcode zu werden.
In dieser Hinsicht stehen wir vor einer Reihe von Problemen:
- Berücksichtigt unser Optimierungsmodell immer mögliche Produktionsbeschränkungen?
- Können unsere Modelle mit Engpässen umgehen?
- Kann unser Modell korrekt auf Produktionsänderungen reagieren?
Hier haben wir beschlossen, das Testteam zu fokussieren.
Unsere Aufgabe ist es, die ML-Testpraxis zu vereinheitlichen, um auf alle oben genannten Probleme reagieren zu können. Im Moment sind wir zu einer Reihe von Schlussfolgerungen gekommen, und jetzt werde ich Ihnen sagen, welche.
Testen Sie die Einhaltung von Produktionsbeschränkungen und -anforderungen für deren Berücksichtigung durch den Optimierungsalgorithmus
Bei klassischen Tests haben wir bei jedem Test immer ein „erwartetes Ergebnis“. Wir wissen genau, wie das System auf die eine oder andere Eingabedaten reagieren soll. Wenn es sich jedoch um ML in Produktionsumgebungen handelt, kann dieses am meisten erwartete Ergebnis die Einhaltung von behördlichen Dokumenten wie GOSTs, technologischen Anweisungen und temporären Flussdiagrammen sein, die sowohl die Produktionsprozesse selbst als auch die Qualitätskriterien des Endprodukts einschränken. Während ihrer Tests müssen wir sicher sein, dass alle diese Einschränkungen tatsächlich eingehalten werden, und trotz ihrer Anzahl sind wir sicher, dass jeder von ihnen von Testfällen abgedeckt wird.
Am Beispiel eines realen Projekts zur Optimierung der Produktion von Materialien N (wir haben den Fall noch nicht bekannt gegeben, daher werden wir anonyme Namen verwenden) haben wir dieses Problem wie folgt gelöst:
- Wir haben alle Qualitäten von N-Materialmischungen nach dem Gehalt an chemischen Elementen in ihnen klassifiziert. Als Ergebnis erhielten wir eine Liste, die wir später als Hilfsmittel verwenden wollten, um eine ausreichende Testabdeckung sicherzustellen.
- Wir waren davon überzeugt, dass die Empfehlungen des Modells für alle diese Gemische von Produktionstechnologen bedingungslos akzeptiert wurden, und haben das Ergebnis dieses Problems in einer CSV-Datei festgehalten. So erhielten wir Empfehlungen des Systems eines bestimmten „Goldstandards“.
- Dann wurde ein Skript geschrieben, das die Liste unserer Referenzmischungen von Version zu Version durch das Modell führte und das Ergebnis seiner Lieferung mit dem verglich, was in unserer „Goldstandard“ -CSV gespeichert war.
- Wenn keine Änderungen im Verhalten des Modells festgestellt wurden, können die Regressionstests als erfolgreich angesehen werden. Wenn nicht, wurde eine Nachbesprechung durchgeführt.
Auf diese Weise konnten wir das Problem der Regressionstests lösen und das Vertrauen gewinnen, dass die in das Modell eingeführten Änderungen die früheren Ergebnisse unserer Arbeit nicht beeinflussen.
Die Tests konzentrierten sich auf Engpässe
Optimierungsmodelle können am besten vorhersagen, was in historischen Daten am häufigsten vorkommt, und umgekehrt kann sich ein Modell in einen Kürbis verwandeln, sobald es auf etwas Ungewöhnliches stößt.
In solchen Fällen muss der Optimierungsdienst häufig ein angemessenes Verhaltensmodell „auffordern“, und dies generiert den Hardcode, über den ich zuvor geschrieben habe. Aber wie kann man diese Engpässe identifizieren und den Service debuggen? Ich werde dies am Beispiel der Entwicklung eines Dienstes für Empfehlungen zur Verwaltung der Produktion von Material N erläutern (der Fall ist noch nicht offenlegungspflichtig, daher wird im Folgenden auf verschleierte Namen verwiesen).
Zunächst entwickelte unser Architekt einen Integrationsemulator, der produktive Daten erzeugte und damit den Datumsrahmen ausfüllte, auf dessen Grundlage das Optimierungsmodell Empfehlungen für die Verarbeitung von Material N herausgab. Anschließend analysierte der Tester diese Empfehlungen und identifizierte die verdächtigsten - diejenigen, die ausgeschlagen wurden empfohlene Parameter für den Gesamtmassenstrom. Bereits zu diesem Zeitpunkt konnten wir viele Probleme identifizieren, wenn das Modell auf die eine oder andere Weise den eingehenden Datenstrom nicht angemessen verarbeiten konnte. Dies ermöglichte es uns, den Zustand des Dienstes zu stabilisieren und mit dem nächsten Schritt fortzufahren.
Die zweite Stufe war das Testen der Stille. Der Service wurde in der Produktionsumgebung im Hintergrund angehoben. Er arbeitete, ohne den Materialbearbeiter N von der Maschinensteuerung abzulenken, und wir sammelten wiederum „Bedienerlösungen“ und verglichen sie mit den Empfehlungen des Dienstes. Aus diesem Grund haben wir die toten Winkel des Modells gefunden, die in der vorherigen Phase nicht erfasst werden konnten.
Das Modell muss in der Lage sein, auf Produktionsänderungen zu reagieren.
Wir haben ein Dienstleistungsportfolio in unserem Projektportfolio, um die Produktion von Kraftstoffmaterialien zu optimieren. Das Wesentliche des Service ist, dass der Technologe den Bestand der Produktionskomponenten auf das Modell überträgt, die Grenzindikatoren für die Produktqualität festlegt und den erforderlichen Produktionsplan festlegt und als Antwort eine Empfehlung erhält: In welchen Anteilen muss er bestimmte Komponenten verwenden, um den Kraftstoff der angegebenen Menge zu erhalten Qualität.
Bei der Entwicklung dieses Dienstes sind wir auf ein merkwürdiges Problem gestoßen, das wir nicht im Voraus vorhersehen konnten.
Das Unternehmen in der Kraftstoffherstellung arbeitete mehrere Jahre in einem bestimmten Bereich von Gesamtumdrehungen und verwendete gleichzeitig plus / minus das gleiche Verhältnis von Komponenten.
In letzter Zeit hat die Organisation das Angebot dieser Komponenten geändert, und es ist möglich geworden, diese Tatsache durch eine Erhöhung der Geschwindigkeit der Einheiten zu kompensieren. Der Kunde erwartete, dass das Modell in der Lage sein wird, auf diese Änderungen zu reagieren. Aus Sicht der technologischen Produktion ist dies eine akzeptable Lösung, dies ist jedoch nicht geschehen. Warum? Die Antwort liegt auf der Hand: Das Modell wurde an einer historischen Stichprobe trainiert, wo dies zuvor noch nicht geschehen war. Sie können lange über das Thema sprechen, wer in dieser Situation Recht hat und wer schuld ist, aber in Zukunft haben wir geplant, die Wahrscheinlichkeit solcher Situationen wie folgt zu verringern:
- Arbeiten Sie enger mit dem Kundenvertreter der Produktionseinheit zusammen, um Engpässe und mögliche Produktänderungen zu identifizieren.
- Behandeln Sie Testfälle mit ähnlichen Fällen im Voraus.
- Schreiben Sie Autotests, um die Einhaltung der Produktionsbeschränkungen und die Korrelation der Zeichen zu überprüfen.
Nur ein paar Worte zu den Testwerkzeugen, die wir verwenden mussten:
- Bugtracking - Jira,
- Qualitätsmanagementsystem - Test Rail,
- Versionskontrollsystem - GitLab,
- CI / CD - Jenkins,
- Autotests - Java + Junit / TestNG,
- Skripte für die direkte Interaktion mit dem Modell - Python + Jupyter.
Testen Sie ML?
Für uns ist der Aufbau einer ML-Testpraxis zu einer Herausforderung geworden, die eigentlich von Grund auf neu entwickelt werden musste. Es sind jedoch Tests erforderlich - dies hilft, die Anzahl der Fehler vor Beginn des Testbetriebs zu verringern und die Implementierungszeit zu verkürzen.
Heute müssen wir alle Erfahrungen austauschen. Es ist notwendig, Diskussionen über Tests an spezialisierten Standorten und in professionellen Foren zu beginnen, die im Bereich der ML übrigens immer mehr werden. Und wenn Sie bereits Praktiken zum Testen von ML etabliert haben, werden wahrscheinlich alle daran interessiert sein, darüber zu lesen. Teilen Sie Ihre Erfahrungen in den Kommentaren mit.
Sergey Agaltsov, Testmanager, Jet Infosystems