Eine Idee zur Diskussion: Empfangene Textdaten via KI übersetzen

[Paul Bumann]

Hi zusammen,

ich hatte heute mit einem Creator ein Gespräch, aus dem eine Idee entstanden ist, die ich gerne mal teilen würde.

Mich interessiert einerseits die Meinung von anderen Creatoren aus unserem Kundenkreis, aber auch die Einschätzung unseres Produktteams, genauso wie unserer Technical Engineers.

Folgendes Szenario: Ein bspw. russischsprachiger Mitarbeiter eines Unternehmens arbeitet mit einer smap, in der er mit der Russisch eingestellten Tastatur kyrillische Schriftzeichen in ein Textfeld eingibt. Der Datensatz wird abgesendet und landet damit in der smapOne-Plattform.

Nun der Gedanke/die Idee: Die Daten werden via API aus der Plattform geholt, automatisiert an "eine KI" übergeben, dort auf Deutsch (oder eine andere Sprache) übersetzt und dann der Bericht auf der gewünschten Sprache erzeugt.
(alle hier erwähnten Sprachen können natürlich beliebig ausgetauscht werden).

In dem Szenario haben wir bewusst auf eine direkte Übersetzung in der smap verzichtet. Das wäre was für einen anderen Thread.

Wie seht Ihr dieses Szenario?

1. Hättet Ihr auch Anwendungsbereiche, in denen das in dieser Form relevant wäre? @Peter Kopper, @Vincenzo Montalto, @Jeanne Merswolken, @Gerald Unger, @Magnus Möhlenkamp (to just mention a few 😄) 
2. Könnten wir das mit aktuell verfügbaren Mitteln (wie beschrieben, API usw.) umsetzen, @Aaron Seggelke, @Torsten Wolf?
3. Könnte man das auch im Produkt umsetzen, @Annemarie, @Marika Karl?

Klar, die Frage des Datenschutzes im Fall einer Übersetzung via KI (werden die Prompts weiterverarbeitet oder nicht) ist hier erstmal hinten angestellt. Es bleibt ja vorerst theoretisch.

Abschließend: Es ist hier erstmal nur als Diskussionspunkt und Gedankenspiel gedacht, nicht als Feature-Wunsch.

Bearbeitet 14. Mai von Paul Bumann

[Bülent Erbas]

Hallo @Paul Bumann

wir haben bei uns zwar keine sprachliche Anforderung... aber die Idee finde ich großartig.

Es gäbe, alternativ zu KI (wg. Datenschutz), noch DeepL:
DeepL API | Maschinelle Übersetzungstechnologie

Die scheinen da besser vorbereitet zu sein.

Was mich aber in dieser Diskussionsrunde technisch interessieren würde: die übersetzten Daten müssen ja wieder in die smap zurückfließen, damit überhaupt ein Bericht erstellt werden kann.
Entsprechend muss ja auch dann berücksichtigt werden, wie der Benutzer dann den Bericht steuern kann, also in welcher Sprache es ausgegeben werden soll.

Oder denke ich da komplett falsch?

Bearbeitet 14. Mai von Bülent Erbas

[Paul Bumann]

Da bewege ich mich auch ein wenig im Rahmen des Halbwissens.

Aber meines Wissens kann die Berichtsenginge auch via bspw. PowerAutomate angesprochen werden und so ein Bericht generiert werden. <=Disclaimer: Bitte verlassen Sie sich nicht auf dieses Aussage 😅

DeepL ist auch ein guter Gedanke. Ich könnte nicht valide beantworten, welcher Weg die beste Ausgabe erzeugt. Mal schauen, was das Schwarmwissen noch so hervorbringt 🙂

[Gerald Unger]

Ein freundliches Hallo an Alle!

Das ist wirklich ein interessantes Thema. Wir haben in der Tat mehrere russisch sprechende Mitarbeiter. Allerdings haben wir uns noch nicht mit dieser Problematik auseinander gesetzt. Zur Zeit sehe ich auch nicht die Notwendigkeit. Auf weitere Sicht kann eine Übersetzung, bzw. eine Smap in anderen Sprachen durchaus Sinn machen. 

[David Susami]

Die Idee fände ich gut.

Habe tatsächlich auch einen Usecase für ein solches Thema (Schulungsnachweise), da eine KI nicht immer perfekt übersetzt und ich auch gerne durch menschliches Verständnis übersetze, wäre mein Wunsch eine Hybridlösung.

Konkret fände ich es toll wenn man in der Plattform Sprachen, die die smap unterstützen soll, anlegen kann und dort anhand der BrickIDs, gerne im selben Layout, einfach den selben Text z.B. in englisch hinterlegen könnte. Somit wäre Datenschutz auch nicht unbedingt ein Problem, da jeder seinen Text manuell oder via. KI übersetzen lassen könnte.

Als Beispiel nenne ich einfach mal die xCode oder Android Studio wie es im UX-Designer gelöst ist. 

Bearbeitet 15. Mai von David Susami

[Vincenzo Montalto]

Hallo Paul,

sicherlich gibt es rund um das Thema "Translate", sehr viele Anwendungsfälle. Ich bin allerdings eher der Meinung, dass die gesamte smap in der jeweiligen Tastatursprache übersetzt werden sollte, also nicht nur die Eingabe, um die Sprachbarriere so gering wie nur möglich zu halten. Wir haben bspw. unsere Schulungsvideos für die Erst- und jährlichen Unterweisungen in diversen Sprachen übersetzt um die Qualität des Wissenstransfers deutlich zu verbessern. 

 

[Marika Karl]

Hallo an alle, die hier mitlesen.

Übersetzungen, Mehrsprachigkeit sozusagen, ist ein heißes Thema. Ich weiß, dass das immer wieder aufploppt und von Manchen dringender benötigt wird als von anderen. In meinen bisherigen Gesprächen ergibt sich ein recht bunter Strauß, was genau gebraucht wird und wie die perfekte Lösung für den jeweiligen use case ist. 

Ich habe dazu auch schon mit Lucas und @HK alias Holger gesprochen - tatsächlich auch mit der KI im Hinterkopf. Aus der Umsetzungsperspektive ist die KI ein overhead - wie schon u.a. von @Bülent Erbas angeführt wurde, es Tools gibt, die das recht gut machen. KI ist hingegen für komplexere Lösungen zu bedenken. 

Aber ja, @Paul Bumann, du schieltest besonders auf die Reintegration der Übersetzung in den Bericht. Da sind wir schon eher bei KI, schätze ich (bin da aber auch nur beim Bauchgefühl).

Jedenfalls sind wir bei der Betrachtung einer schnellen und Übergangslösung auf die Browserübersetzung im Zuge der Web-App gekommen. Und das kann sie schon. Damit haben wir den sehr wertvollen und wichtigen Aspekt von @Vincenzo Montalto, dass alles an der smap in der jeweiligen (Mutter-)Sprache gehalten ist. 

Im Bericht wäre das ein Mischmasch aus Erstellungs- und Eingabesprache, den man derzeit noch auseinanderklamüsern muss. Ein weiteres Problem, wenn man es als solchen einstufen möchte, sind Eigennamen in den Prozessen und Abkürzungen oder falsche Schreibweisen für die automatisierte Übersetzung. 

Dieser Roman soll die Diskussion nicht stoppen, auch wenn der Beitrag sehr nah an dem aktuell Möglichen orientiert ist und nicht am Inspirativen, so wie Paul das moderiert hat. 

Ich lese aufmerksam weiter mit: was braucht ihr? Wo sind die größten Hindernisse.