Back to top

Google Cloud Search – Bericht aus der Praxis und Analyse

alex olaru
Alex Olaru
Functional & Industry Analytics Sr. Manager

Integration, Funktionen und Anwendungsszenarien

cloud search

2002 trat Google zum ersten Mal in den Bereich der Unternehmenssuche ein und präsentierte die Google Search Appliance (GSA) – ein Rack-Einbaugerät für die Suche und Indexierung von Dokumenten. Dank einer Reihe von leistungsfähigen Funktionen wurde die GSA mit der Zeit immer beliebter:

  • Einfache Einrichtung eines Webcrawlers für die Indexierung von Inhalten aus den unternehmenseigenen Websites 
  • Intuitive, vorinstallierte Benutzeroberfläche zur Bedienung der Suchfunktionen 
  • Konnektoren für die Indexierung von komplexeren Metadatenstrukturen und Zugriffskontrolllisten (ACL, Access Control List) aus verschiedenen Content-Management-Systemen
  • Integration mit den unternehmenseigenen Authentifizierungssystemen und Verwendung von indexierten Zugriffskontrolllisten, um die Ausgabe der Suchergebnisse je nach Berechtigungsstufe zu steuern

Nachdem neuere Technologien und Funktionen auf dem Markt erschienen, gingen einige der GSA-Anhänger zur Konkurrenz. Folgende Trends konnten wir in den letzten Jahren beobachten:

  • Mit der Verbreitung von Cloud-Lösungen im Unternehmensbereich wurde die GSA, die im unternehmenseigenen Rechenzentrum installiert werden musste und nur bedingt skalierbar war, immer weniger flexibel im Vergleich zu den anderen Suchlösungen.
  • Andere Anbieter von kommerziellen und Open-Source-Lösungen entwickelten ihre Indexierung- und Abfrage-APIs in einem Tempo weiter, mit dem die GSA nicht mithalten konnte.
  • Obwohl die Relevanzmodelle der GSA zu den Besten zählten, begrenzte die Unfähigkeit wesentlich mehr Daten zur Verbesserung dieser Modelle einzulesen, die Fähigkeiten der GSA in Bezug auf Suchrelevanz.


Vom Gerät zur Cloud

2016 verkündete Google das Ende der GSA (die letzten GSA-Lizenzen laufen noch bis Frühjahr 2019) und präsentierte der Öffentlichkeit eine neue, cloudbasierte Lösung: Google Cloud Search

Cloud Search war ursprünglich ein Teil der G Suite und ermöglichte eine Suche durch die Inhalte aus den verschiedenen Google-Apps: Gmail, Drive, Kalender, Sites, Kontakte und Gruppen. Das nächste große Release von Cloud Search, angekündigt auf der Google Cloud Next 2018, war eine eigenständige App, ergänzt durch Indexierung und Suche in externen Unternehmensinhalten:

  • Interne Websites und Portale
  • Content-Management-Systeme
  • Dateisysteme
  • Relationale Datenbanken
  • Inhalte aus unternehmenseigenen Anwendungen

Weil Cloud Search die externen Inhalte mit den G Suite-Inhalten nahtlos verknüpft, ist es wichtig zu betonen, dass Unternehmen keine G Suite-Lizenzen benötigen, um Cloud Search nutzen zu können. Sie können in Cloud Search festlegen, nur die externen Inhalte zu indexieren und sie innerhalb eigener Suchanwendungen zur Verfügung zu stellen. Siehe Dokumentation von Cloud Search (Englisch).

Google Cloud Search auf einen Blick – wichtigste Funktionen

google cloud search funktionenIn den letzten acht Monaten erhielten ausgewählte, im Bereich Unternehmenssuche erfahrene Google-Partner sowie interessierte Kunden den Zugang zu den Alpha- und Betaversionen von Cloud Search zur Anbindung externer Inhalte. Accenture arbeitete zusammen mit Google an der Implementierung. Wir konnten exklusiv die Cloud Search-Funktionen testen, die ersten Kundeninstanzen ausprobieren und unser Feedback geben, um somit die Weiterentwicklung von Cloud Search zu beeinflussen. 

Nachfolgend präsentieren wir Ihnen unsere Eindrücke und Analyse der wichtigsten Cloud Search-Funktionen als einen ersten Leitfaden für Unternehmen, die Cloud Search verwenden möchten – ob als Ersatz für GSA, Einführung einer neuen Suchlösung oder als Verbesserung einer bestehenden Suchlösung.


1.  INHALTE INDEXIEREN


a)  Datenorganisation

Cloud Search organisiert Inhalte in Form von Datenquellen (Sammlungen von Informationen mit dem gleichen Schema). Das Schema ist eine Vorlage für die Objekttypen, die innerhalb einer Datenquelle indexiert werden. Es erlaubt dem Nutzer, Objekteigenschaften zu definieren, die verschiedene Metadaten und ihre Datentypen beschreiben (z. B. Text, Datum, Zeitstempel, ganze Zahl, Gleitkommazahl, boolesch usw.). Die Objektdefinitionen enthalten weitere Eigenschaften: Ausgabe in den Suchergebnissen, Verwendung für die Sortierung, Verwendung als Facette usw. 

Hier unterscheidet sich Cloud Search entscheidend von den anderen Produkten, indem es eine benutzerfreundliche Benennung der Eigenschaften (als Operator) erlaubt. Dadurch wird es später möglich, die Suchergebnisse nach dieser Eigenschaft zu filtern, nachdem der Operator in der Suchanfrage mit NLU-Algorithmen (Natural Language Understanding – Verständnis natürlicher Sprache) erkannt wurde. Sucht der Nutzer beispielsweise nach „Tickets mit Priorität 1“ so dient Priorität als Operator und löst einen Filter auf das Feld Priorität aus.


b)  REST API zur Indexierung der Inhalte

Auf der untersten Ebene verwendet Cloud Search eine JSON-basierte REST API, um Daten aus deren Quellen zu indexieren. Die wichtigsten Elemente einer Indexierungsanfrage sind:

  • Gemeinsame Metadaten: Felder, die in allen Elementen vorhanden sind, unabhängig von der Datenquelle oder dem verbundenen Schema: die Quell-URL, MIME-Type, Sprache, Erstellungs- bzw. Aktualisierungsdatum usw. Die Sprache im Dokument kann ebenfalls automatisch erkannt werden: Cloud Search unterstützt über 100 Sprachen. Wenn Sie von der Qualität der Google Translate-Dienste überzeugt sind, dann können Sie auch in Cloud Search eine Sprachunterstützung auf einem gleichhohen Niveau erwarten.
  • Strukturierte Daten: Benutzerdefinierte Felder – die Metadaten werden entsprechend dem Schema der Datenquelle abgebildet.
  • Inhalte: Können als Volltext oder Rohdaten vorliegen (Cloud Search unterstützt automatische Textextraktion aus dem binären Inhalt der häufigsten Dokumentformate: Office, PDF usw.).
  • Zugriffskontrolllisten (ACL): Hier werden Zugriffsberechtigungen und Zugriffsverweigerungen unterstützt.
  • Eindeutige Kennung und Version des Dokuments

Für die Nutzung der APIs von Cloud Search benötigt man OAUTH2.0 zur Authentifizierung. Zur Vereinfachung der Arbeit mit den REST APIs bietet Google eine Java Client-Bibliothek an. Zusätzlich gibt es Mechanismen für eine automatische Erstellung der Client-Bibliotheken für andere Sprachen.


c)  Konnektoren und Konnektoren-SDK (Software Development Kit)

In der Grundausstattung enthält Cloud Search folgende Konnektoren: CSV, Webcrawler, Windows-Dateisysteme, relationale Datenbanken, Microsoft SharePoint 2013/2016 und SharePoint Online.

Es stellt sich die Frage: „Was tun, wenn ich andere Datenquellen verwenden möchte, als die von den Standard-Konnektoren in Cloud Search unterstützten?“. Es gibt einige Optionen:

Option 1: Eine große Auswahl an Konnektoren im Partnernetzwerk: Google kooperiert mit über 50 Partnern weltweit, die rasch mehr als 80 Konnektoren für die Anbindung von über 60 Datenquellen ans Cloud Search entwickelten. Als langjähriger Google-Partner passte Accenture sein eigenes Framework Aspire an, um dessen Vielzahl von suchmaschinen-agnostischen Konnektoren anzubieten – inklusive eines Cloud Search Publisher, um die strukturierten und unstrukturierten Unternehmensinhalte aus verschiedenen Quellen in Cloud Search aufzunehmen und zu veröffentlichen. Diese Option kann Risiken senken und die Zeit zwischen Entwicklung und Produktivsetzung beschleunigen. 

Option 2: Google bietet ein Java-basiertes Framework an, das eine Entwicklung von Konnektoren für andere Daten- und Identitätsquellen vereinfacht. Das Konnektorframework von Cloud Search besticht durch einige starke Funktionen:

  • Warten auf Änderungen in Datenquellen – nach dem Empfang einer Benachrichtigung folgt eine inkrementelle Indexierung. Für Datenquellen, die diesen Mechanismus unterstützen.
  • Baumabarbeitung – die Indexierung beginnt mit dem Wurzelknoten, danach folgen die untergeordneten Knoten. Diese Strategie eignet sich für hierarchisch aufgebaute Datenquellen.
  • Einsatz der Cloud Search Indexing Queue – eine Indexierungswarteschlange regelt den Status und Prioritäten von Elementen. Besonders hilfreich bei einer inkrementellen Indexierung.


d)  Hierarchische Strukturen: Zugriffskontrolllisten und Dokumente

Cloud Search weist eine beispiellose Auswahl von ausgereiften Suchindexmodellen auf, um Inhalte aus Datenquellen mit äußerst komplexen Strukturen aufzunehmen:

  • Für hierarchische Datenquellen (das einfachste Beispiel: Dateisysteme mit Ordnern und Dateien) kann die Indexierung der Elemente als Container (Ordner) oder Inhalte (Dateien) erfolgen. Dies ermöglicht die Abbildung der gesamten Objekthierarchie in der Suchmaschine. So wirkt sich diese Funktion u.a. aus: Nach dem Löschen eines Ordners im Dateisystem müssen in anderen Suchmaschinen Löschanfragen für den Ordner selbst und jedes Element innerhalb dieses Ordners gesendet werden. In Cloud Search genügt eine Löschanfrage nur für den Ordner und alle Elemente innerhalb dieses Ordners werden automatisch gelöscht. Außerdem ist es möglich, die Elemente zu filtern, die zum gleichen Ordner gehören.
  • Für die Zugriffskontrolllisten werden drei Typen der Berechtigungsvererbung unterstützt: Parent Override (die Berechtigungen des übergeordneten Elements überschreiben die des untergeordneten Elements); Child Override (die Berechtigungen des untergeordneten Elements überschreiben die des übergeordneten Elements) oder beides (der Nutzer erhält Zugriff auf das Element, nur wenn Berechtigungen für das übergeordnete und das untergeordnete Element vorhanden sind). 
  • Es gibt zwei Mechanismen für die Festlegung der leseberechtigten Personen (als Teil einer Identitätsquelle): Benutzernamen (für Einzelpersonen) und Gruppen-IDs (für Gruppen). Zum Beispiel ist Dokument A ein Kind von Dokument B, erbt aber die Berechtigungen von Dokument C.


2.  BENUTZER UND GRUPPEN EINLESEN

Zur Zugriffskontrolle verwendet Cloud Search das sogenannte Early Binding. Beim Early Binding ermittelt die Suchmaschine (nach einer erfolgreichen Authentifizierung) alle Gruppen, zu denen der Benutzer gehört, die sog. Group Expansion. Dadurch können Suchergebnisse richtig gefiltert werden, indem die Elementberechtigungen mit der Nutzer-ID und seinen Gruppen verglichen werden. In der GSA wurden die zugehörigen Gruppen mithilfe externer Systeme ermittelt. Cloud Search ist fortschrittlicher: Es interagiert mit anderen Google-Identitätsdiensten, um den Benutzer zu authentifizieren und dessen Gruppenmitgliedschaften zu ermitteln. Die Benutzeridentitäten und Gruppen (d. h. leseberechtigte Personen) müssen in diesen Identitätsdiensten verfügbar sein (indexiert und synchronisiert). 
Es folgt eine Beschreibung der wichtigsten Komponenten für das Einlesen von leseberechtigten Personen.


a)  Cloud Identity  

Cloud Identity ist ein Verzeichnisdienst von Google. Er speichert alle Kontendaten von Benutzern, die Zugriff auf die Google-Produkte inklusive Cloud Search haben. Als eindeutige Benutzerkennung dient seine E-Mail-Adresse im Format uid@companydomain.com. Um eine eindeutige Kennung zu bekommen, benötigt der Benutzer keine G Suite-Lizenz. Diese Funktion wird bereits in der kostenlosen Version von Google Cloud Identity unterstützt. Ein Benutzer kann mehrere Aliase haben; diese werden in einer Identitätsquelle aufgelöst. Das Google Admin SDK/REST API bietet Tools für die Verwaltung von Benutzern und Benutzernamen.


b)  Identitätsquelle

Eine Identitätsquelle ist eine Sammlung von leseberechtigten Personen und hat eine eindeutige Kennung. Leseberechtigte Personen (als Teil einer Identitätsquelle) können auf zwei Weisen erfasst werden:

  • Benutzernamen (für Einzelpersonen)
  • Gruppen-IDs (für Gruppen)

Die Gruppen müssen nicht mit einer E-Mail-Adresse verbunden werden. Sie gelten als nicht per E-Mail ansprechbare Gruppen bzw. Sicherheitsgruppen (Begriff aus Active Directory). Die Cloud Identity-Lösung beinhaltet einen SDK/REST API, um diese nicht per E-Mail ansprechbaren Gruppen zu verwalten.


c)  G Suite-Gruppen

Für Kunden mit G Suite-Lizenzen kann man Benutzergruppen einrichten, deren Mitglieder E-Mails als Gruppe erhalten. Die eindeutige Kennung dieser Gruppen ist eine E-Mail-Adresse. In Active Directory werden diese Gruppen als Verteilerlisten bezeichnet. Google Admin SDK/REST API bietet Tools für die Verwaltung von solchen per E-Mail ansprechbaren Gruppen.


d)  Abbildung leseberechtigter Personen in Zugriffskontrolllisten

Leseberechtigte Personen innerhalb einer Zugriffskontrollliste können mit folgenden Mitteln abgebildet werden:

  • Eindeutige Benutzerkennung (E-Mail-Adresse)
  • Benutzername (Identitätsquelle + Benutzer-ID)
  • Eine per E-Mail ansprechbare Gruppe (E-Mail-Adresse)
  • Eine nicht per E-Mail ansprechbare Gruppe (Identitätsquelle + Gruppen-ID)

Dies ermöglicht die direkte Erfassung lokaler Benutzer- und Gruppen-IDs einer Datenquelle (d. h. die IDs werden nicht mit einem LDAP-Verzeichnis synchronisiert) in die Cloud Identity. Existiert zum Beispiel eine lokale Gruppe namens „admin“ in SharePoint und eine andere Gruppe namens „admin“ in Confluence, so werden beide Gruppen in Cloud Identity mit ihren ursprünglichen IDs erfasst. Es gibt keinen Konflikt aufgrund des Namensraums, denn jede Gruppe wird mit einer anderen Identitätsquelle verknüpft.


e)  Erfassung von Identitäten

Zusätzlich zu den oben erwähnten SDKs und APIs bietet Cloud Search ein SDK für Identitätskonnektoren. Es hat ein ähnliches Konzept wie das SDK für das Konnektorframework. Beide SDKs erleichtern die Entwicklung von Konnektoren für die Einbindung und Synchronisierung von Benutzern und Gruppen aus verschiedenen Datenquellen in die Identitätsverzeichnisse von Google. Die aktuelle Version von Google Cloud Directory Sync enthält Tools für die Synchronisierung von Benutzern und per E-Mail ansprechbaren Gruppen aus LDAP-Verzeichnissen. Die zukünftige Version wird außerdem die nicht per E-Mail ansprechbaren Gruppen miteinbeziehen.


3.  SUCHANFRAGEN UND BENUTZEROBERFLÄCHEN


a)  Such-API

Eine JSON-basierte REST API bietet für die Suche folgende Funktionen:

  • Facetten und Filter
  • Sortieren und Blättern
  • Suche in mehreren Datenquellen, inklusive Gmail, Google Drive, Sites usw.
  • Verarbeitung der Suchanfragen in natürlicher Sprache – das ist noch ein Alleinstellungsmerkmal von Cloud Search im Vergleich zu anderen Suchmaschinen
  • Hervorhebung von Textfragmenten
  • Mehrsprachigkeit


b)  Benutzeroberflächen (UI)

Auf Grundlage der oben beschriebenen APIs können eigene Benutzeroberflächen mit Suchfunktionen erstellt werden. Ein HTML-basiertes Suchwidget (ESW) ist standardmäßig in Cloud Search enthalten und wird entweder als eine eigenständige Benutzeroberfläche verwendet oder in eine größere Anwendung integriert (z.B. ein bereits vorhandenes Portal). ESW erlaubt eine begrenzte Anpassung der Darstellung mithilfe von CSS.


c)  Listing API

Die Ergebnisse einer Abfrage beinhalten keine sensiblen Daten, wie zum Beispiel Berechtigunsinformationen, und ermöglichen keinen Zugriff auf die gesamten Inhalte eines Elements. Für die Fehlersuche und -behebung ist in Cloud Search die Listing API vorgesehen, die den Zugang zu der gesamten Struktur eines Elements in Cloud Search ermöglicht: Zugriffskontrolllisten, kompletter Inhalt, Version, Status usw.


4.  SUCHRELEVANZ

Wie man es schon von Google kennt, gibt es nicht viele Drehknöpfe für die Einstellung der Suchrelevanz. Einige Möglichkeiten sind allerdings vorhanden:

  • Für jedes indexierte Element wird dessen Suchqualität berechnet; auf dieser Basis kann das Element in den Suchergebnissen weiter nach oben oder nach unten verschoben werden.
  • Anpassung der Relevanz je nach Aktualität des Elements
  • Erhöhung der Sichtbarkeit je nach Herkunft der Datenquelle
  • Personalisierung kann ein- und ausgeschaltet werden.

Es gibt keine Funktion, welche die Ausführung der Suche – ähnlich wie in Lucene-basierten Suchmaschinen – darlegt. Das ist z.T. verständlich, denn die Relevanzalgorithmen sind eines der bestgehüteten Geheimnisse, die Google an die Spitze der Suchmaschinen brachten.

Mit Hilfe einiger Parameter, die wir zu Googles Relevanzberechnung hinzuliefern, können wir erwarten, dass Cloud Search eine hervorragende Qualität der Suchrelevanz im Unternehmensbereich bietet, mit besonderem Fokus auf Personalisierung. Hier einige Beispiele:

  • Vielfältige Benutzerinteraktionen sind möglich:

- Alle Suchanfragen, inklusive Facetten, Filter, Sortierung und Blättern werden über die Abfrage-API realisiert.

- URLs für die Suchergebnisse sind mit einem Weiterleitungsmechanismus verbunden; dadurch können die Klicks für jedes einzelne Ergebnis erfasst werden.

- Die Index-API unterstützt Dokumentinteraktionen außerhalb einer Suchanwendung (Zeit und Benutzername werden protokolliert, wenn ein Dokument direkt aus der Suchanwendung geöffnet bzw. bearbeitet wird).

  • Das gesamte Benutzerverzeichnis wird im Rahmen der Google-Dienste abgebildet; somit kann Cloud Search im Laufe der Zeit den Benutzerkontext besser verstehen (z. B. Organigramm, Standort, Benutzergruppen mit ähnlichen Suchanfragen, neue Mitarbeiter usw.).
  • Ein besseres Verständnis der Beziehungen zwischen den Dokumenten in den indexierten Korpora.

Verbesserungspotenzial

Wie bei jedem ersten Release einer größeren Anwendung gibt es einige Kritikpunkte und Verbesserungsvorschläge. Zum Beispiel:

  • Die Listing API bietet wenig Filtermöglichkeiten, um die Suchergebnisse zu verfeinern.
  • Es gibt bis jetzt keinen einfachen Mechanismus, um die Ergebnisse der Suchanfrage mit den Ergebnissen der Listing-Anfrage zu verknüpfen.
  • Es ist schwierig, nach den gemeinsamen Eigenschaften mehrerer Datenquellen zu filtern.
  • Die Benutzeroberflächen für den Administrator und die Statistiken sind momentan weit von dem entfernt, was ein typischer GSA-Administrator zur Verfügung hatte.
  • Es fehlen komplexere Tools zur Facettierung und Aggregation.

Allerdings verfügt die erste allgemein erhältliche Version von Cloud Search über alle wichtigen und kritischen Funktionen zur Implementierung von leistungsstarken Suchlösungen im Unternehmensbereich. Zukünftige Versionen von Cloud Search werden sicherlich die meisten der oben erwähnten Kritikpunkte beheben.

Anwendungsszenarien von Google Cloud Search – was gilt zu beachten?

Wie bereits an mehreren Stellen in diesem Beitrag angedeutet, steht der Benutzer im Fokus der Cloud Search-Funktionalität. Es ist von entscheidender Bedeutung, den Benutzer und seinen Kontext zu kennen. Wir können uns folgende Anwendungsszenarien von Google Cloud Search vorstellen:

  • Suche im Intranet
  • Unternehmensweite Suche
  • Frage-Antwort-Systeme

Andererseits kann eine typische Cloud Search-Installation in einigen Fällen nicht die beste Lösung sein:

  • Öffentliche Inhalte: Einige unsere GSA-Kunden implementierten diese Lösung für die Suche auf ihren öffentlich zugänglichen Websites (d. h. die Inhalte sind bereits im Internet verfügbar). Die Abfrage-APIs in Cloud Search benötigen eine Authentifizierung. Es ist zwar möglich, aber nicht unkompliziert, Cloud Search nur für die Suche in den öffentlichen Inhalten zu verwenden. Allerdings sollte man folgendes bedenken: google.com leistet bereits gute Arbeit bei der Indexierung öffentlicher Inhalte.
  • Logdateien: Logdateien sind ebenfalls Inhalte, die nicht unbedingt eine Authentifizierung benötigen. Logdateien haben meist eine sehr einfache Struktur, deswegen kommen einige der leistungsstarken Funktionen von Cloud Search nicht zum Einsatz. Außerdem spielt die Anzahl der Elemente (Dokumente bzw. Ordner) bei der Berechnung der Nutzungskosten eine Rolle. Aus diesem Grund wäre ein Kosten-Nutzen-Vergleich sinnvoll, bevor Cloud Search für die Suche in umfangreichen Logdateien verwendet wird.

Eine Google-ähnliche Suche im Unternehmensbereich mit Google Cloud Search ermöglichen

Unsere Kunden fragen oft: „Warum können wir nicht die Suchfunktionalität von google.com in unserem Unternehmen nutzen?“. Mit der Veröffentlichung von Google Cloud Search für externe Inhalte nähern wir uns diesem Ziel. Personalisierung, Anwendung der cloudbasierten, maschinellen Lernverfahren zum Verständnis der Suchanfragen in natürlicher Sprache und optimierte Algorithmen der Suchrelevanz sind die Schlüsselfaktoren, denen Google seine neue Position im Bereich der Unternehmenssuche zu verdanken hat. Wir bei Accenture verfügen über Strategien, Implementierungserfahrung und technologisches Know-how, um Ihr Unternehmen bei der Einführung der neuen Cloud Search-Suchlösung zu unterstützen, die damit verbundenen Risiken zu minimieren und den ROI zu steigern. 

Technologische Hilfsmittel für die Implementierung von Google Cloud Search

  • Wir entwickelten eine Reihe von suchmaschinenunabhängigen Konnektoren, um die Erfassung strukturierter und unstrukturierter Inhalte aus verschiedenen Quellen zu vereinfachen. 
  • Unser Publisher Framework beinhaltet die meisten gängigen Funktionen für die Übertragung der Inhalte in verschiedene Suchmaschinen. Der Aspire Google Cloud Search Publisher von Accenture erhält Content von den Aspire-Konnektoren und indexiert sie mithilfe einer Java Client-Bibliothek nach Cloud Search. 
  • Aspire Content Processing von Accenture ist ein ETL-Framework, das speziell für unstrukturierte und halb-strukturierte Daten entwickelt wurde. Es bietet eine optimale Funktionalität, eine große Auswahl von vorgefertigten Bearbeitungskomponenten, eine Hadoop-Implementierung und alle Möglichkeiten eines verteilten Systems. 

Das Bild zeigt das Zusammenspiel dieser Komponenten. 

google cloud search konnektor


Dank unserer Erfahrung im Umgang mit Google-Produkten und technologischen Hilfsmittel unterstützen wir Sie gerne bei der Entwicklung einer vollständig auf Ihre Bedürfnisse angepassten Suchlösung auf der Cloud Search-Basis. Unsere Kompetenzen umfassen alle Bereiche von Content-Erfassung, -bearbeitung und Anreicherung bis hin zur Entwicklung von Benutzeroberflächen. Kontaktieren Sie uns, um Ihre Anforderungen an eine Suchanwendung zu besprechen und mehr über unsere Implementierungsmethoden für Google Cloud Search zu erfahren. 

0

Wir freuen uns, bekannt zu geben, dass wir jetzt Teil von Accenture sind! Lesen Sie die Ankündigung hier.