Wir entwickeln Macroscop seit fast einem Jahrzehnt. In dieser Zeit hat sich bei der Entwicklung intelligenter Module ein sehr gründlicher und seriöser Ansatz zur Schaffung neuer Funktionen entwickelt. Einerseits ist das sehr gut. Ernsthafte Absichten gehen mit einem hochwertigen Produkt einher. Gleichzeitig kann Gründlichkeit an die Langsamkeit und Inoperabilität des Prozesses grenzen.
Noch vor ein paar Jahren, als wir Anfragen von Benutzern erhielten, etwas Neues zu entwickeln (nicht im Masterplan für die Produktentwicklung enthalten), hatten wir eine lange Prognosezeit und bewerteten die Vielseitigkeit und Relevanz der Funktion für eine breite Palette von Benutzern. Und oft lehnten sie die Implementierungszeit ab oder bewerteten sie als sehr lang. Aber sobald wir eine Anfrage für ein Großprojekt erhalten haben. Bei der erfolgreichen und schnellen Implementierung der fehlenden Benutzerfunktionen waren die Aussichten und der Umfang der Macroscop-Implementierung sehr gut. Und wir fingen an zu versuchen! Wir hatten einen engen Zeitrahmen, einen reaktionsschnellen und hilfsbereiten Benutzer und völlige Handlungsfreiheit.
Und ... alles hat geklappt!
Wir haben in kurzer Zeit ein neues Feature erstellt. Außerdem war sie genau und schnell. Alle waren zufrieden: Der Benutzer erhielt das begehrte intellektuelle Modul, die Entwickler erhielten coole Erfahrungen, das Unternehmen - Verkauf.
Diese Praxis markiert den Beginn eines
neuen Ansatzes zur Entwicklung intelligenter Funktionen in Macroscop: Wir sind immer einfacher geworden, unsere Benutzer zu treffen. Und es gibt seine Ergebnisse.
Das Wichtigste ist, die tatsächlichen Bedürfnisse des Benutzers zu identifizieren und die Aufgabe mit ihm klar zu formulieren. Wenn es um die schnelle Entwicklung von maßgeschneiderten Funktionen geht (wir werden sie im Folgenden als schnelle Funktionen bezeichnen), müssen unbedingt die Anforderungen festgelegt werden: Was der Benutzer am Ende sehen möchte, worauf er sich konzentrieren soll. Denn bedingt muss man zuerst sicher arbeiten, der andere, damit es cool aussieht. Wenn wir eine schnelle Funktion übernehmen, sprechen wir nicht über die Tatsache, dass sie am Ende unter allen Bedingungen mit 100% iger Genauigkeit funktioniert. Wir
verpflichten uns
, die Idee selbst zu testen und zunächst etwas zu schaffen, das angemessen funktioniert und für die Verwendung an einem bestimmten Objekt akzeptabel ist. Und nur dann, wenn wir erfolgreich sind, verfeinern wir und bringen ein universelles Produkt mit guter Leistung.
Wenn die Ziele und Prioritäten klar sind, nehmen wir die Entwicklung auf. Innerhalb kurzer Zeit entwickeln wir einen Prototyp, den der Benutzer bereits bewerten kann. Und wir geben es auf die Probe. Wenn das, was wir getan haben, mit den Bedürfnissen des Benutzers korreliert und allgemein gefällt, und die Methode, die wir in der Entwicklung verwendet haben, sich noch nicht erschöpft hat und Aussichten auf eine Verbesserung der Funktion hat, gehen wir weiter. Wenn sich herausstellte, dass es völlig falsch und völlig falsch war, schließen wir das Projekt. Und da dies in einem frühen Stadium geschieht, verlieren wir fast nichts.
Bei diesem Ansatz sollten Entwickler und Benutzer
so weit wie möglich aufeinander zugehen. Der Benutzer muss auch in den Prozess einbezogen werden: Es ist notwendig, den Prototyp sorgfältig an verschiedenen Kameras und unter verschiedenen Bedingungen zu testen, verschiedene Einstellungen auszuprobieren und verschiedene Tasten zu drücken, ein umfassendes Feedback zu geben: Was ist bequem, was ist nicht bequem, was funktioniert nicht so, wie es die Genauigkeit bewertet? wie viel der Server lädt usw.
Zunächst befriedigen wir die Bedürfnisse eines bestimmten Kunden, aber noch vor Arbeitsbeginn schätzen
wir ,
wie universell diese Funktion in Zukunft werden kann und wie viele Menschen sie bei der Lösung ihrer Probleme unterstützen kann. Und in Zukunft passen wir die schnelle Funktion so an, dass sie in möglichst vielen Videosystemen nützlich und anwendbar ist.
Erinnerst du dich, wie alles begann? (C)
Die erste schnelle Funktion für uns war das
Warteschlangenzählmodul . Im Allgemeinen hatten wir es schon einmal, aber die Bedingungen für die Anwendbarkeit waren begrenzt: Das Modul arbeitete nur in einer Projektion, wenn die Kamera streng von oben nach unten blickte. Einmal wurden wir von einem Benutzer angesprochen, der Personen in einer Warteschlange unter grundlegend anderen Bedingungen zählen musste - wenn die Kamera die Warteschlange diagonal (direkt und leicht darüber) betrachtet.
Aus dieser Perspektive könnte das Makroskop-Modul zählen
und dabei - gelerntEr alle mochte Macroscop, aber es fehlte ihm die geschätzte Funktion. Das Projekt war sehr vielversprechend und der Benutzer war bereit, in jeder Hinsicht mit uns zusammenzuarbeiten, wenn nur ein solches Modul auftauchte und die Software auf dem Objekt installiert werden konnte. Wir beschlossen, die Gelegenheit nicht zu verpassen und begannen uns zu entwickeln.
In der letzten Variante des Moduls wurde die Aufgabe des Zählens von Personen durch klassische Computer-Vision-Methoden gelöst, die die Nutzungsbedingungen stark einschränkten. Im Rahmen der neuen Aufgabe musste das Modul jedoch lernen, Menschen unter grundlegend anderen, viel schwierigeren Bedingungen zu zählen.
Die Gruppe der Entwicklung intellektueller Funktionen wurde in drei Untergruppen unterteilt, und jede begann, ihre eigene Methode auszuprobieren. Alle von ihnen basierten auf der Verwendung neuronaler Netze.
Der erste, den ich versuchte, auf das Modul zum Zählen von Personen in Warteschlangen in die Infrastruktur des
Detektors zu übertragen, den wir für das
Fehlen von Helmen entwickelt haben (siehe den
Artikel darüber, wie wir versucht haben, mithilfe moderner neuronaler Netzwerktechnologien Helme auf den Köpfen von Personen zu finden ). Dieser Ansatz schien sehr logisch: Der Helmdetektor in einem bestimmten Arbeitsstadium löst ein ähnliches Problem.
Die zweite Gruppe versuchte, ein
neuronales Regressionsnetzwerk anzuwenden. Sie zählt die Anzahl der Personen im Bild, wählt jedoch keine bestimmten Objekte aus, was die Kontrolle erschwert. Beim Training in einem neuronalen Regressionsnetzwerk wird ein Bild übermittelt und die Anzahl der anwesenden Personen angegeben. Das neuronale Netzwerk gibt eine Zahl an - wie viele Personen es gefunden hat. Wir füllten das Beispiel mit neuen Bildern und versuchten, es so zu trainieren, dass es richtig zählt.
Leider haben wir beide Methoden abgelehnt, da die Genauigkeit des auf ihrer Basis erstellten Zählers gering war.
Die dritte Gruppe testete einen ziemlich bekannten
Allzweckdetektor , der eine Vielzahl von Objekten in Echtzeit erfassen kann. Er weiß, wie man nach tausend verschiedenen Objekten sucht, löst aber nicht unser Problem mit all seinen Merkmalen. Wir haben diesen Detektor fertiggestellt, ihn an unserer eigenen umfangreichen Probe trainiert und ein recht gutes Ergebnis erzielt - einen Personenzähler mit akzeptabler Genauigkeit. Sie verbesserten es mit einer neuen Auswahl und bekamen schließlich einen Prototyp, was schon keine Schande war, dem Benutzer einen Test zu geben. Und seine Einschätzung war ... positiv! Er sagte, dass die
Lösung im Allgemeinen
bereits wettbewerbsfähig ist , aber die Genauigkeit noch nicht hoch war - nur 60-70%.
Die erste Version des Warteschlangenzählers wurde hauptsächlich mit Clips dieses Benutzers erstellt. Wir haben das Problem gelöst -
um speziell mit ihm zusammenzuarbeiten -, aber wir haben verstanden, dass es keine weitere Skalierung geben kann, wenn wir das neuronale Netzwerk trainieren und ein Modul für ein bestimmtes Projekt erstellen. Daher wurden weitere Schulungen an einer universelleren Stichprobe durchgeführt, was zu einer Erhöhung der Genauigkeit auch ohne globale interne Verbesserungen führte. Dann begannen wir mit der Arbeit an der Modulverpackung - verbesserten die Schnittstelle, vermasselten verschiedene Einstellungen und machten auf Benutzerfreundlichkeit und Logik aufmerksam. Parallel dazu haben wir eine Reihe von Fehlern in unserem Prototyp behoben (einer von ihnen hat das Modul übrigens unerwartet um das Siebenfache beschleunigt), herausgefunden, wie der CPU-Verbrauch gesenkt werden kann, und die Arbeit an der Grafikkarte angeschlossen. Als Ergebnis haben wir ein objektiv gut funktionierendes und einfach zu verwaltendes Modul erhalten, das schnell analysiert, genaue Ergebnisse liefert und weiß, wie man mit einer Grafikkarte arbeitet, ohne den Prozessor zu laden.
Unser Benutzer war einfach glücklich! Er ging, um die neue Version in seine Läden zu bringen, und bestätigte, dass in der Praxis alles gut funktioniert. Es ist uns gelungen, eine Genauigkeit von 85-90% zu erreichen (in Situationen, in denen sich die Personen in der Warteschlange nicht vollständig überlappen und unterschieden werden können).
Natürlich verlief während des Entwicklungsprozesses nicht alles reibungslos, und beispielsweise gab es zwischen dem ersten Prototyp und der Lösung, die jetzt auf der Site installiert ist, eine fehlerhafte Version, die schlechter funktionierte als die vorherige. Aufgrund ihrer Erfahrung haben wir jedoch erkannt, worauf beim Testen zu achten ist, und eine Reihe von Funktionen der verwendeten Frameworks kennengelernt. Vor diesem Hintergrund haben wir ein cooles Abschlussmodul erstellt und darauf basierend - eine weitere schnelle Funktion.
Happy End
Jetzt wird die Anwendung des Moduls zum Zählen von Personen in der Warteschlange der neuen Version auf andere Geschäfte dieses Benutzers erweitert. Und die endgültige Version - ging in Produktion und gab die Version von Macroscop ein, die für die Veröffentlichung vorbereitet wird. Übrigens war der Benutzer mit dem Ergebnis und der Arbeitsweise so zufrieden, dass eine weitere Anfrage einging -
einen leeren Regaldetektor herzustellen. Und wir haben es wieder genommen und wieder gemacht (aber das ist eine ganz andere Geschichte).
Zusammenfassend lässt sich sagen: Zum Vergleich: Die Entwicklung und Verfeinerung der alten Version des Moduls zur Zählung der Personen in der Warteschlange (vor 4 Jahren) dauerte etwa
8 Monate . Wir haben das neue Modul in
2 Monaten hergestellt (der erste funktionierende Prototyp wurde dem Benutzer in 2-3 Wochen übergeben).
Bisher ist dies nur ein Test des Stiftes und nur im Rahmen einer Richtung - der Entwicklung intellektueller Funktionen. Im Allgemeinen halten wir uns bei der Produktentwicklung an einen strengeren und gründlicheren Ansatz - mit Planung, zahlreichen Validierungen von Ideen, Nachfrageanalysen und eingehenden Tests. Was unverändert bleibt, ist die Praxis, Macroscop (ob es sich um die Entwicklung eines Kernels oder von Videoanalysemodulen handelt) in enger Zusammenarbeit mit Benutzern zu erstellen.
Es gibt keine Gewissheit, dass der Ansatz schneller Funktionen fortlaufend und innerhalb der gesamten Abteilung angewendet werden sollte, aber jetzt sammeln wir echte Erfahrungen mit schneller Entwicklung, und die Benutzer, für die dies durchgeführt wird, sind echte Vorteile des Produkts.
Auf jeden Fall haben wir für uns mehrere Regeln aufgestellt, deren Einhaltung der halbe Erfolg bei der Entwicklung schneller Funktionen ist:
- Versuchen Sie, den Benutzer zu treffen, aber vergessen Sie nicht Ihre eigenen Ziele: Nehmen Sie Projekte an, die skaliert werden können, und investieren Sie in etwas, das langfristig nützlich ist.
- Gehen Sie den wahren Aufgaben und Bedürfnissen des Benutzers auf den Grund und identifizieren Sie Prioritäten.
- Benutzerunterstützung eintragen. Wenn er bereit ist, aktiv zu kommunizieren, zu testen, Feedback zu geben und die erforderlichen Daten bereitzustellen (z. B. Video von einem realen Objekt), besteht jede Chance, sich gut und schnell zu entwickeln.
- Haben Sie keine Angst vor dem Scheitern und behandeln Sie es als eines der möglichen Ergebnisse.
- Versuchen Sie nicht, etwas Einzigartiges von Grund auf neu zu entwickeln, sondern nutzen Sie nach Möglichkeit die vorhandene Erfahrung: Versuchen Sie in unserem Fall, Teile der Algorithmen aus bereits implementierten Modulen zu verwenden. Und selbst wenn sich die resultierende Lösung als realisierbar herausstellt, nehmen Sie sich Zeit für Forschung und Anpassung.