Bei der Enterprise Suche wurde es grad spannend

Microsoft hat immer davon gesprochen, jetzt haben sie wirklich was Gutes auf den Tisch gelegt. Hut ab: Microsoft Search Server 2008.

Ein als eigenes Produkt verpacktes Enterprise Search Produkt, welches technisch auf Sharepoint (WSS und .Net) basiert, sich aber standalone installieren lässt. Bevor ich nun 1’000 Sachen erzähle ein paar die ich ziemlich cool finde:

– Das leistungsfähige Basisprodukt ist gratis („hard to compete“)
– Alle drei Varianten des Produktes haben KEIN Dokumentenlimit
– Externe Suchsysteme lassen sich über das OpenSearch API von A9 einbinden
– plus all die netten Konverter von Microsoft
– Später (Anfang Jahr) Kommen dann noch Konnektoren dazu

So auf den ersten Blick sieht bereits die Gratisversion sehr gut aus und MS behautet das Ding sein (auf einer Windows-Kiste) in 30 Minuten „up and running“.

i-ef7d7fadb61f3e1df639b4cd7a060c9f-ms-search-server-2008-thumb.png

Ich auf jeden Fall installiere das Ding ziemlich plötzlich!

Enterprise Search: Microsoft versus Google [Umfrage]

Am Mittwoch, 28. November 2007 zwischen 14 – 17.30 Uhr organisieren wir einen 1:1 Vergleich der Suchtechnologie für Firmen von Microsoft (die heute S2 offiziell angekündigt haben) und Google. Dafür könnten wir von beiden Firmen je einen Techie (No Marketing-Brup) gewinnen, der bereit ist die Lösungen live zu zeigen und so zu vergleichen.

>> Wer kommen will, kann hier hier anmelden: Google und Microsoft: Enterprise Search-Systeme im Vergleich

i-a3d07afe8f1d1c44e9516b8a612b3a59-microsoft-versus-google.gif

Ich schreiben diesen Post um Fragen zu sammeln, die beide Hersteller zeigen (besser als beantworten sollen). Also wichtige Aspekte, welche das eine oder andere Produkt für einen Unternehmenseinsatz differenzieren.

Also bitte los mit den Fragen… ich habe 6 Slots zur Verfügung.

Ist die neue Suchfunktion besser als die alte?

Es gibt verschiedene Search Analytics Kennzahlen, von denen ich schon über einige berichtet habe. Interessant ist das Beispiel von Jan Pedersen von Yahoo, welches er im Rahmen der Vorlesung „Search Engines: Technology, Society, and Business“ organisiert von Marti Hearst an der UC Berkeley gezeigt hat.

Yahoo nimmt die Suchsessions, bei denen mindestens ein Link auf der Trefferliste geklickt wird. IN der Menge rechnen sie den durchschnittlichen Rang (1 zuoberst, 12 der zweite Treffer auf der zweiten Suchtrefferseite) des zuletzt des letzten in der Session geklickte Resultates der Trefferliste. Je kleiner die Zahl, desto besser die Rangierung. Und so sah die Graphik nach einem grossen grossen Update (um 04-07) aus. In der Erklärung spricht Pedersen [Podcast, mp3] jedoch von inversem Rang (1/Rang), doch das würde weder die absolute Zahl noch das negative Vorzeichen erklären…

i-a9c0a3ec3ec8dd21698bc3fc5c470cc6-yahoo-rank-thumb.png

Bei mit im Post zu der Rangliste war das die Kennzahl Nummer 3… nur leider hat mir die schöne, öffentliche Graphik gefehlt. Danke Jan! Da der Titel des Charts Metric 11 heisst, hätte ich die restlichen auch noch gerne ;-)

Die Google Enterprise Suche GSA wird sozial

i-18f5e0ddcf63d9a71e5ba8aef6b9360c-goog-ent-appliance.jpg

Google stellt in den nächsten Tagen ein Update für seine Enterprise Search Lösung zur Verfügung, welche mit spannenden Neuerungen aufwarten wird. Zum ersten Mal wird die GSA dann ‚offen‘ sein, so dass suchende Benutzer selbst in Funktionalitäten eingreifen können.

Für die heute schon vorhandenen KeyMatch Ergebnisse (bei google.com bekannt als Sponsored Links) steht neu ein Pflege- bzw. Update-Interface zur Verfügung, über welches neu die Benutzer ihre eigenen KeyMatches für sich und die Kollegen pflegen können.

Damit dies im schlimmsten Fall nicht ausufert, kann durch den GSA Administrator diese Funktionalität beschränkt oder sogar ganz abgestellt werden.

i-ad774dcbd7f81640c99ba3372c41e722-goog-ent-keymatch-thumb.jpg

Weiter wird der Release 5 der GSA Software Konnektoren für einige Enterprise Content Management Systeme mitbringen, bereits bekannt sind Konnektoren für Microsoft Sharepoint und Documentum. Mit Hilfe von Konnektoren ist man nicht auf die Crawling-Fähigkeit der Datenquelle angewiesen, vielmehr wird mittels ‚Hook‘ bei Änderungen an CMS Inhalten der Inhalt direkt via XML-API an die Search Appliance geschickt und so eine ad-hoc Indizierung ermöglicht.

i-2a0a8295513f1dd90b180feccbe1c98b-goog-ent-search-as-type.jpg

Rein visuell das attraktivste neue Feature wird eine Google Suggest ähnliche Funktion für die Search-Box der GSA sein. Dabei wird mit type-ahead Technologie schon während der Eingabe ein Preview auf das Suchergebnis geliefert. Eine Best Practice kann man bereits heute schon bei der apple.com Suche sehen.

Je nachdem wieviel Aufwand man in die Implementierung einer solchen Lösung steckt, ist die Google Enterprise Suche nicht nur eine Volltextsuche, sondern kann vielmehr zu einer unternehmensweiten Universal Search ausgebaut werden in welcher nicht nur Text-Links die SERP beherrschen, sondern beispielsweise auch Bilder oder Videos angezeigt werden, wie heute schon bei manchen Suchen auf google.com sichtbar ist.

Und die Diskussion beginnt (Autonomy vs Google)

Auf dem Google Blog schreibt Matthew Glotzbach (Product Management Director, Google Enterprise) über ein Whitepaper von Autonomy, welches von Google handelt. Titel: Don’t believe everything you read.

Darin wiederlegt er Falschaussagen die Autonomy über die Google Search Appliance macht. Und Glotzbach hat recht… Wir haben die Technologie bei Kunden schon sehr oft eingesetzt und im besten Fall bezieht sich das Paper von Autonomy auf die erste Version der Google Mini. Die ist aber schon fast 1,5 Jahre aus dem Dienst.

Interessant ist der Ansatz von Google die Diskussion öffentlich zu machen. Mal sehen wie es weitergeht….

PS: Leider hat der Google Weblog keine Kommentarfunktion

PPS: Noch neckisch als zertifizierter Partner von Google haben wir Zugriff auf Google Dokumente über Autonomy… ob dort wohl alles stimmt… ich muss mal nachlesen.

Look at the Data (not at the Shirt)

Im Rahmen des Google Developer Day sprach Peter Norvig über „Theorizing from Data“.

Dabei geht es im Kern um einen alten Streit zwischen Linguisten und Statistiker, der Norvig sehr elegant zu Gunsten der Statistiker entscheidet: „If you don’t have the data, you don’t do progress“.

Nach einer Einführung, weshalb der bei Google arbeitet („because that’s where the data is“), zitiert er ein Paper von Banko und Brill, in welchem sie empirisch zeigen, dass der beim einem Trainigsset von 1 Mio. Dokumenten der schlechteste Algorithmus zur Disambiguierung von Worten den besten (immer bei 1 Mio.) schlägt, sobald dieser mit 10 Mio. trainiert ist. Der Einfluss der Daten ist also wichtiger als der Unterschied der Berechnung.

Nun beginnt er mit Beispielen, welche auf einem englischen Korpus von Google basieren den sie aus dem Web Crawl für das LDC erstellt haben. Darin finden sich 95 Mio. Sätze mit 13 Mio. unterschiedlichen Worten (inkl. Zahlen, Eigennamen und Tippfehlern). Damit macht Google beispielsweise Query Refinment. Hier beim Term „flicker“ (mit e) und einiges mehr.

i-1de1f0f1779f645cc22f3b337e1d7de6-goog_query_refinement-thumb.gif

Norvig beginnt nun in seinem Trainingsset mit „unsupervised machine reading“ Konzepte zu clustern (z.B. company, industry, business). Dann sucht der nach Relationen (z.B. {Konzept} complained to {Konzept} about) und schlussendlich abgeleitete Muster X complained to Y about Z == x filed a complained about Z with/to Y == a complaint to X about Z u.s.w. Wohlgemerkt ohne linguistisches Wissen aber nur über Statistik. Und immer wieder Seitenhiebe gegen die Lingusten mit empirischen Erkenntnissen die halt einfach richtig sind ;-) So beispielsweise führt er Stemming ad absurdum, indem er zeigt, dass eine Konkatenierung nach 4 Zeichen ein bessere Resultat bringt (dabei wollten sie nur Platz sparen ;-)

Und kaum dreht man sich um, zeigt Norvig statistische Übersetzungen die, zumindest in der ausgewählten Beispielen, sehr gute Resultate bringen. Dies Dank der schieren Menge an Trainingsdaten. Für alle, die ein bisschen Spass an Statistik (und oder Liguistik) haben ein brillianter Vortrag. Und hier noch ein Bild wegen der Bemerkung wegen dem Hemd.

i-3d5b9802c03f393259e67af55d2b88c3-dont-look-at-the-shirt.gif

PS: Für Leute die sich schon immer fragten, wie ich YouTube Video runterladen kann. Hier ein Dienst und ein benötigter FLV-Player.

Fremde E-Mails lesen

Natürlich aus rein wissenschaftlichem Interesse. Im Rahmen der Enron Untersuchung in den USA wurden von der Federal Energy Regulatory Commission 619’446 E-Mail Nachrichten von 158 Usern (meist Kadermitarbeiter) öffentlich publiziert. Diesen Korpus gibt es bei der Carnegie Mellon Universität zum Download und ist ein guter Grund, seine privaten E-Mails nicht übers Geschäft zu „pflegen“… oder suchen sie mal nach „marry me“ drin ;-)

Spannend sind die verfügbaren Auswertungen darauf so auch unterschiedliche statistische Klassifizierung oder gleich eine interaktive Navigation.

i-22962d28477b929e6d9e7683513d7dc4-search3_california_ferc-thumb.png

Sehr nett natürlich die Möglichkeit die Daten selbst als Testdatenset (z. B. auch für DBMS-Test) zu nutzen (ohne „wissenschaftliche“ Papers generieren zu müssen).

Danke an Martin für den spannenden Tipp.

Search Analytics – Kennzahlen um den Index (Teil 3)

Letzter Teil einer Serie über Kennzahlen der Suche. Ziel ist es, die Qualität der (Volltext)suche zu messen und somit faktenbasiert zu verbessern. Also keine emotionalen Diskussionen darüber, wie die Trefferliste rangiert (…das ist sowieso subjektiv…), aber eine Messung. Die Serie ist Teil der Der online Erfolgsmessung: Web Analytics und unserer Arbeiten zur Informationssuche allgemein: Information Retrieval. Die zwei Posts bis jetzt:

> Kennzahlen um die Trefferliste
> Kennzahlen um die Query

Und nun der Index. Der Index ist die (technische) Datenstruktur, welche die auffindbaren Elemente enthält. Wichtige Aspekte sind dessen Vollständigkeit (sind alle gewünschten Elemente darin verfügbar?), die Aktualität (ist der Index synchron mit den originären Datenquellen?) und dessen Mächtigkeit (welche Funktionen bietet der Index an wie beispielsweise die Suche nach Phrasen oder die Evaluation von Wortabständen?). Aber bei der Suchanalyse bitte nur das messen, was wirklich auch angepackt d.h. verändert wird. Daher schlage ich nur eine Kennzahlen vor:

1) Anzahl suchbare Elemente.

zu 1) Sie wissen wie viele Seiten ihr Angebot hat. Stimmt diese Zahl mit dem Suchindex überein? Einfach, aber einige Fragen gilt es zu klären so wie: Gibt es unterschiedliche Ansichten des selben Inhaltes beispielsweise eine Druckansicht jeder Seite? In die Suche gehört nur eine der Repräsentationen (da es sich bei der anderen faktisch um ein Duplikat handelt). Oder: Wie werden Seiten gehandhabt, welche mehrere binäre Dokumente „drauf haben“ (insb. PDF)? Normalerweise gibt es pro PDF einen Indexeintrag (konvertiert nach HTML , mit einer eigenen URL) und zudem noch einen Eintrag für die Verteilerseite selbst, da dort hoffentlich auch ein paar nützliche Informationen untergebracht sind.

Wenn die Kennzahl plötzlich sinkt? Es mag einen echten Grund geben, so beispielsweise wurden Seiten der Präsenz deaktiviert und gehören somit raus aus dem Index. Häufiger sind aber Berechtigungsprobleme weil plötzlich etwas in der Konfiguration geändert wurde oder andere technische Probleme wie die Erreichbarkeit einer der Quellen o.ä. Oder auch sehr beliebt Template-/HTML-Änderungen nach denen der Crawler die Links nicht mehr erkennt (JavaScript und Flash lässt grüssen).

Wenn die Kennzahl plötzlich steigt? Klar: Sie haben neue Inhalte publiziert ;-) Auch beliebt sind sogenannte „Crawler-Traps“ d.h. der Crawler indexiert denselben Inhalt mehrfach oder gar endlos. Grund sind meist technische Änderungen insb. an der ULR (z.B. Session IDs) oder an der Serverkonfiguration.

Somit wünsche ich Ihnen alle Verbesserungen bei Ihrer Suche. Es lohnt sich die Zahlen anzukucken!

PS: Dieser Post ist Teil der dreiteiligen Serie Search Analytics.

Worttrennung und Editierabstand = Unterhaltung

Wissenschaftlich fundiert und auch einfach erklärt, doch deutlich spannender ist der Unterhaltungswert. Rechtschreibeprüfungen nutzen unter anderem die Worttrennung (Decompounding) und der Editierabstand (Levenstein distance) um ähnliche Schreibweisen als Korrekturvorschläge zu machen.

Im folgenden Beispiel (Microsoft Word 2003 mit Schweizer(deutsches) Wörterbuch hält der Algorithmus alles vor und nach dem Bindestrich fest und „spielt“ mit dem Wort Meta, welches das Wörterbuch offensichtlich nicht kennt. Und was kommt das raus?

i-ada81e19d73f775ba281441a84cf42d5-spellcheck-word-meta.png

HTML-Mega-Tags: Muss was grössere sein?
HTML-Beta-Tags: Davon gibt es im Web 2.0 viele!!
HTML-Mett-Tags: Kenn ich nicht, kenne nur Mettwurst
HTML-Eta-Tags: Hmm sind das die aus dem Baskenland oder auch Grenchen?

Danke Reto für Hinweis und den Kommentar.

Search Analytics – Kennzahlen um die Trefferliste (Teil 2)

Nach einem ersten Teil „Search Analytics – Kennzahlen um die Query“, hier der zweite Streich. Ziel ist es weiterhin die Effektivität der Suche („Suchmaschine“) faktenbasiert zu verbessern. Also nicht ein Zaub(d)erer, der mit viel warmer Luft erklärt was zu tun ist, niemand ihm folgen kann und nach der Änderung immer noch alle unglücklich sind aber: Zahlen. Das ganze ist ein Teil von Web Analytics: Der Erfolgsmessung im Internet. Erlauben Sie zuerst die folgende Erklärung.

i-a6dabe3892ee42b3dc7ce3ead3a884a8-zustaende-uebergaenge-suche.png

Die Ellipsen zeigen typische Zustände („Seiten“) einer Suchanwendung. Das Suchfeld (mit sehr wenigen Optionen beispielsweise auf jeder Seite rechts oben), die erweitere Suchmaske (mit allen Optionen), die Trefferliste (gerne auch mit SERP = Search Engine Result Page abgekürzt) und das Zieldokument (das in der Trefferliste verlinkte Ziel).

Alle Übergänge sind im Rahmen der Navigation möglich. So zum Beispiel gebe ich im Suchfeld einen Begriff ein und lande (nach dem Klick auf dem „Suchen“-Button über Pfeil 1 auf der Trefferliste. Dort blättere ich eine Seite, da ich in den Zitaten das Gesuchte nicht zu finden meine (über Pfeil 2) und schlussendlich wähle ich einen Eintrag der zweiten Trefferliste und lande über Pfeil 3 auf dem Zieldokument. Viele andere Wege sind möglich: Von der Trefferliste zurück zum Suchfeld, vom Zieldokument zurück zur Trefferliste etc. Und nun zu den Zahlen:

1. Auswahlhäufigkeit (Selection Ration)
2. Suchabbruch (Search Abandonment)
3. durchschnittliche Ranglistenposition gelickter Treffer
4. in der Trefferliste geklickte URLs
5. aufrufende Seite

Auch hier wieder gehören die Werte wieder zyklisch ausgewertet etc.

zu 1) Die Auswahlhäufigkeit ist die Anzahl der Suchanfragen, bei denen User in der Trefferliste auf mindestens einen Treffer klicken geteilt durch die Anzahl der Suchanfragen. Führt ein User eine Suche aus und klickt auf einen Treffer der Trefferliste, so steht die (statistische) Chance gut, dass er fündig wurde. Das Verhältnis ist 1. Bei einem kleineren Verhältnis führt der User mehrere Suchanfragen aus, klickt aber weniger Treffer. Dies ist ein Hinweis, dass das Gesuchte nicht im Index ist (gar nicht auf der Trefferliste erscheint), die Rangierung schlecht ist oder das Trefferzitat eines relevanten Eintrags nicht zu einem Klick verleitet. Und ist die Auswahlhäufigkeit grösser Eins, so wählt der User zu wenig Suchanfragen sehr viele Kandidaten für einen Treffer, kommt aber immer wieder zur Suche zurück, da das gewählte Zieldokument sein Informationsbedürfnis nicht befriedigt hat.

zu 2) Der Suchabbruch ist der Fall, bei dem User nach einer Suche auf null Treffer klicken. Die Kennzahl das Verhältnis der Abbrüche zur Anzahl Suchanfragen. Um dies festzustellen, muss ein geeignetes Zeitintervall festgelegt werden, wie lange ein einzelner Suchprozess (Session) maximal dauern darf. Bspw. 5 Minuten. Eine gute Kennzahl ist möglichst tief.

zu 3) Die durchschnittliche Ranglistenpposition ist eine Aussage zur Rankingqualität aus Usersicht und erlaubt, je nachdem ob die Trefferliste immer gleich lang ist resp. die Anzahl Einträge pro Rangliste im Tracking bekannt sind, auch die Berechnung wie häufig zwischen Ranglisten geblättert wird. In der oberen Graphik ist dies der Übergang 2 und eine tiefe Kennzahl nahe bei 1 (der gelickte Treffer ist immer auf Rang 1) ist optimal.

zu 4) Die in der Rangliste geklickte URLs ist keine Kennzahl, dennoch eine wertvolle Aussage. Sozusagen eine BottomUp-Sicht darauf, welche Zielseiten regelmässig über die Suche gefunden werden. Diese Seiten sind Kandidaten für eine höher Gewichtung in der Informationsarchitektur („ab auf die Hompage“), aber auch Kandidaten für hervorgehobene Top Treffer in der Rangliste. Achten Sie hier auf die Saisonalität der Suchanfragen.

zu 5) Auch keine Kennzahl. Die Seiten, aber welcher die Trefferliste aufgerufen wurde (der Referrer). Haben Sie beispielsweise auf jeder Seite oben rechts ein Suchfeld, so kann der Ursprung der Suchanfrage ganz unterschiedlich sein. Stellen Sie beispielsweise fest, dass regelmässig im Bereich der Pressemitteilungen gesucht wird (die per Zufall leider alle als PDF angebiten werden). Diese Erkenntnis ist auch Grundlage für Gewichtung von Inhalten und für spezialisierte Suchfunktionen.

Soweit so gut. Für Frage und Bemerkungen bin ich gerne zu haben und es folgt noch ein dritter Teil über Kennzahlen um den Suchindex.

PS: Dieser Post ist Teil der dreiteiligen Serie Search Analytics.