Volltextsuche: Diskussion zur Relevanz von Suchergebnissen

[Herzlicher]

Hallo,

ich habe mir eine Volltextsuche auf Basis von PHP und Mysql zusammengebastelt und stehe jetzt vor der Frage, welchem Relevanzkriterium zufolge die Suchergebnisse am besten geordnet ("ranken") werden können.

MySQL bietet hier zwei Möglichkeiten:
1. Wenn man SELECT MATCH(...(Felder)...) Against (...(Suchstring)..) As Relevance ... benutzt, erhält man eine Fließkommazahl Relevance, welche die relative Häufigkeit der Suchbegriffe in den Feldern des Datensatzes wiederspiegelt.
2. Wenn man SELECT MATCH(...(Felder)...) Against (...(Suchstring)... IN BOOLEAN MODE) As Relevance ... verwendet, erhält man eine Zahl x als Relevance, die die wiedergibt, dass die x UND-verknüpften Suchbegriffe des Suchstrings tätsichlich in dem entsprechenden Datensatz enthalten waren. Hat auch noch Suchbegriffe im Suchstring, die nicht enthalten sein müssen (ODER-Verknüpfung), kommen Dezimalzahlen heraus.

Besonders die letzte Methode ist unbefriedigend, da meine Suche eine reine UND-Suche ist und alle Suchergebnisse die Relevanz 2 etwa bekommen, wenn 2 Suchwörter eingegeben wurden.

In diesem Thread möchte ich also gerne eine Diskussion über mehr oder weniger aufwendige Alternativen für ein aussagekräftiges Relevanzranking von Suchergebnissen lostreten.

Über Eure rege Teilnahme würde ich mich sehr freuen.

Herzlichst

[Thilo Fester]

Herzlichen Gruß! :o)

Ich glaube, das ist nicht ganz so einfach. Die Frage nach der Relevanz ist irgendwo immer eine Frage nach der Relevanz für den User.

Ist vielleicht ne blöde Antwort, aber ich glaube, mit einer einfachen Abfrage, lässt sich die Frage nach der Relevanz nur ungenügend klären.

Kannst Du ein bisschen über den Kontext berichten?
Wenn es sich beispielsweise um eine Webseite handelt, ließe sich schon weitaus besser argumentieren : )
Da könnte man beispielsweise Schlagwortlinks in die Seiten setzen.
Seiten, auf die bei einem bestimmten Schlagwort oft gezeigt wird, könnte man allgemein für dieses Schlagwort als relevant betrachten.

Dazu bräuchtest Du Dir dann nur einen kleinen Schlagwortindex mit seinen Vorkommen zusammenbauen ^^

~ Thilo

[Herzlicher]

Hallo Thilo,

es ist eine Informations-Website mit Info-Seiten und einem Forum (ein wenig wie eine wiki). Beide werden durchsucht.

Das mit den Schlagwörtern ist so eine Sache - ich möchte ja gerade, dass die Suchmaschine sich selbst ein Bild macht. Eine Indizierung habe ich noch nicht durchgeführt, aber sobald man das hat, hat man ja einen Schlagwortindex - würde das weiterhelfen?
Man kann dann etwa verzeichnen, wie oft ein Schlagwort auf einer Seite enthalten ist. Wäre also eine Überlegung wert (sobald die Seite noch ein wenig wächst und eine Indizierung aus Laufzeitgründen unausweichlich ist).

Ich hatte mir auch schon gedacht, dass man beliebte Seite (öfter angeklickte) höher ranken könnte, nur für das ja dann zu einer Verstärkung des Effekts! Hohe Seiten bleiben oben.

Bekannte Suchmaschinen verwenden wohl eine Formel mit einer Gewichtung unterschiedlicher Kriterien (bei google z.b. die Verlinkung anderer Seiten auf eine bestimmte Seite sowie die eigene Bedeutung/Ranking dieser verlinkenden Seiten). So eine Formel muss man sich basteln.

Ich bin neugierig auf weitere Vorschläge.

[Thilo Fester]

Also direkt wie Google würd ich das nicht versuchen ^^ Es sei denn Dein Projekt hat eine Größe, die den Aufwand Wert ist!

Zum Stichwortindex: Solange es Dein Projekt ist und von außen keiner die Möglichkeit haben soll, von Suchbegriffen zu profitieren ist das allgemein eine gute Idee. Ansonsten ist das ja leider leicht manipulierbar.

Die Gewichtung durch häufige Aufrufe ist hingegen wieder so eine Sache. Du solltest das auf jedenfall zweitrangig ( im Sinne des Wortes) betrachten.
Was Du Dir noch vornehmen kannst ist eine Art Wertigkeit der Begriffe, die Du in Deinen Index aufnimmst.

Also speichere nicht nur die Anzahl, sondern auch eine Stelligkeit.
Ich persönlich würde ein Wort, dass in einem <h1>-Tag steht, höher gewichten, als eines in einem allgemeinen Kontext. ; )

Das ist doch schonmal einiges.

Wenn Du dann die tatsächliche Relevanz wissen willst, kannst Du ja die Suchergebnisse in ein Frame o.ä. umleiten und praktisch in einer Art Kopfzeile das Suchergebnis vom Benutzer bewerten lassen.
Solange die Benutzer dahinter nur die Informationen für sich beziehen und keine eigenen anbieten, ist die angelegenheit relativ zuverlässig, da ja kein Interesse daran bestehen sollte, Deine Werte zu manipulieren

~ Thilo

[Herzlicher]

Thilo,

in der Tat gibt es bei dieser Seite nur projekt-eigene Inhalte (außer Foren, aber die sind ja nicht das Problem), d.h. eine solche stichwortliste wäre schon einmal als ein Kriterium geeignet.
Auch sollte wie du ansprichst berücksichtigt werden, ob das Schlagwort in einem Datensatz als Überschrift vorkommt oder nicht und auf diese Weise eine Rangordnung geschaffen werden.

Das mit der Userbewertung des Suchergebnisses finde ich aber noch den genialsten und effektivsten Einfall:
Sobald ein Suchergebnis, also der Artikel, aufgerufen wird, erscheint an einer kleinen Stelle "Wie hilfreich war dieses Suchergebnis für Sie?" mit einer Skala von 1 bis 5 zum Anklicken. Beim Speichern wird das noch in Beziehung zu den Suchbegriffen (Stichwortindex) gesetzt und fertig ist ein meines Erachtens wirklich aussagekräftiges Maß für die Relevanz von Suchergebnissen.

Wenn einer noch weitere Ideen hat, ab damit in diesen Thread. ;)

[Christian Zill]

Hi,

leider bin ich weit entfernt von einer Lösung. Bzgl.  einer Lösung d. Problems müssten die Begriffe "Retrieval, Ranking & Mapping" mal angedacht werden. Dbzgl. Hinweise auf entspr. Wikis, mal lesen...

OK, hab ich noch nicht ganz, trotzdem mal folgendes, als Gedankenanstoß:

Gesucht wird z.B. der "Affe":

---------------------------------------------------
1. Affe, affe, Aff', Superaffe, Lackaffe et al. via Regex, Parser, FUZZY-Matching.
---------------------------------------------------
2. Diese "Treffer" bekommen einen "MATCHING"-Wert.
  Das "affe" in "Affinität'" ist kleiner als in "Affenhorde". Die Qualität d. Matching wird gemapt auf eine Skala, z.B. 0..1.
---------------------------------------------------
3.  Diese Treffer werden ausserdem gemapt auf eine RANKING-Skala. Als Teilkomponente, warum nicht, u.a. jener "Fachlich-Hilfreich"-Multiplikator, m.E. Aber i.d. Zusammenhang auch hilfreich, m.E., wäre d. Ermittlung d. inhaltlichen Kontextes d. Treffers. Wie jd. hier schon angestupste: "Treffer in <H1>". Das könnte weitergedacht werden... . Irgendwie, ich weiss nicht wie, also wie raenkt sich ein "Der Affe" gg. ein "Der Affe in Afrika". Welcher von den beiden Treffern ist besser? Wenn allgeneine Antworten gesucht werden halt der erstere Treffer, andernfalls dann vielleicht doch der zweite, so i.d. Richtung?
---------------------------------------------------

War das jetzt hilfreich???

Best regards
Christian

[Christian Zill]

Liebes Forum, hallo,

ich möchte mein Posting v. 07. Januar 2008, 18:46 erläutern dürfen, wo ich
anhand eines Beispiels mir 3 Punkte angedacht hatte bzgl. der gegebenen
Fragestellung "Volltextsuche: Diskussion zur Relevanz von Suchergebnissen":

Ich schrieb ca. folgendes, jetzt leicht verbessert, wie ich finde:

  
  
GESUCHT WIRD DER "Affe":  
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
  
Ich teile das Problem zunächst auf in seine Teilprobleme: Der Volltext wird  
gesplittet in "Wörter". Trivial wäre z.B. anhand der Leerzeichen, mgl. wäre also  
"Alles, was zwischen 2 Leerzeichen steht", oder auch "Die ununterbrochene Menge  
von Zeichen, die im Alphabet enthalten sind". Oder einfach "So viele  
Nicht-Leerzeichen wie möglich". Der Volltext ist jetzt schon mal eine Folge von  
Wörtern. Wenn wir schon mal da sind, streichen wir gleich die  
"Ich-sage-eigentlich-nie-was-wichtiges-aus-Wörter", also diese "der, die, das,  
einer, eine, warum, weshalb, darum" oder ähnliche( o.ä. ). Dbzgl. empfiehlt sich  
die Führung einer Bannliste von "Unwörtern", am besten in einer Text-Datei, die  
leichter zu pflegen ist. Bis jetzt könnte das Ganze als kleines C-Programm  
geschrieben werden, in Form einer Schleife, die solange läuft, bis der Volltext  
"aufgegessen" ist: Suche nächstes Leerzeichen, pack' in der Folge alle  
Nichtleerzeichen in die Variable "Wort", und wenn ein Leerzeichen kommt, schieb'  
den aktuellen Inhalt der Variablen "Wort" in die Liste der bisher gefundenen  
Wörter. Ich glaube, das ist mithilfe von Zeigern und C schnell genug. Zu prüfen  
wäre noch die Möglichkeit eines sogenannten Parsers, wg. der Schnelligkeit.  
Schön wäre auch die Möglichkeit, den Volltext schon hier weiter unterteilen zu  
können, ich will Teiltextblöcke. In einem Forumstext böte sich hier an der  
Thread. In einem HTML-Quelltext böte sich hier an der HTML-Quelltext. Zu  
letzterem:  
  
1\. Wenn der HTML-Text NICHT geparst wird, verliert man, meines Erachtens( m.E. )  
unnötigerweise, vielleicht später doch noch wichtige "Information". Ich meine damit  
folgendes: In HTML sollte der Text hierarchisch strukturiert sein, und er ist es in  
der Regel( i.d.R. ) auch. Wenn wir uns diese Hierarchien erhalten, können  
wir später z.B. von der Hierarchiestufe des "höchsten" Treffers nach unten hin  
wandernd alles das ausgeben, was drunter ist. Sozusagen, und( & ) besser m.E:  
Vom Allgemeinen ins Spezifischere. Erlaubt sei bitte folgendes, bevor ich's  
vergess' wieder mal, ein Beispiel( also ein Beispiel im Beispiel, grmpf.( ?! ) ):  
  
Gesucht wird "DIV-Layout". Gemeint ist aber vielleicht eher float-Layout, und das  
Kernproblem, welches beim Auffinden einen qualitativ wertvollen Treffer  
darstellen würde, bestünde für den User im Hinweis auf ein nötiges  
Clear:[left/right/both], "wann?" und "wo?" und "etc.?" ... . Also der User hat  
sich verrannt, im Tunnel, und da ist kein Licht. Da muß dann halt gebohrt  
werden, m.E., und es TUT weh. Deswegen fände ich an dieser Stelle  
"Schlagwortlinks" eine sehr gute Idee: Die gäben schon mal die Himmelsrichtung  
des Lichts( jaja, der Erkenntnis, nein, ich will's mir nicht immer verkneifen  
müssen, bitte ) an.  
  
Oder aber: Gemeint ist vielleicht eher 3-col-Layout( Der heilige Gral ): Das  
Kernproblem, welches beim Auffinden einen qualitativ wertvollen Treffer  
darstellen würde, bestünde für den User im Hinweis auf eine Komplettlösung, die  
in der Hierarchie nicht unterhalb seines eingegebenen "DIV-Layouts" liegt,  
sondern drüber.  
  
Ingesamt sollte es also in dem Text sowas wie oben, unten, Norden, Süden, Osten  
geben. Und das ist schön. Das gibt es ja auf einer Website. Man müßte diese  
Struktur also abbilden, und wir hätten ein baumartiges Gebilde. Ich denke jetzt  
an Wurzeln, Stämme, Zweige und Blätter im Wald( jaja, nein, es ging, danke ).  
Tragfähig wäre auch das Bild eines Bergwerkgebietes, dort wird gediggert, soll  
heißen "nach Treffern geschürft". Es gibt in diesem Gebiet Schatzkammern, und da  
müssen breite Tunnel gebohrt werden, insgesamt ein richtiges Netzgeflecht von  
Schatzkammern und Tunneln. Also richtiger Wahnsinn an totaldurchlöchertem  
Ruhrgebiet erstmal. Von jeder Schatzkammer zu jeder Schatzkammer einen  
Direktdurchgang. Jetzt könnte man zählen: Welche Tunnel haben wieviele  
Kreuzungen. Je mehr Kreuzungen, umso autobahnähnlicher sollte der Tunnel  
ausgebaut werden. Es ergibt sich u.U. sowas wie die allergrößte Autobahn( A0 ).  
Und vielleicht sowas wie A0-0, A0-1, A0-2, .., A0-n. Und seien die Kreuzungen K,  
und die Schatzkammern S, und in den Schatzkammern jeweils die Menge aller  
stetigen Folgen von Nicht-Leerzeichen, nämlich W. Und danns seien diese "W"s  
doch bitte auch noch in den richtigen Schatzkammern "S"s. Also packen wir doch  
diese Wortfolgen einfach gleich in diese Schatzkammern, wo sie gefunden wurden.  
Was? Ja genau, nur die "Goldenen Worte", also die oben ja schon geparsten. Also  
ich denke langsam an die 7 Zwerge, und Schneewittchen ist auch noch nicht  
gefunden, also weiter jetzt.  
  
Nehmen wir jetzt mal an, wir könnten das ganze Ruhrgebiet so stauchen und  
zerren, daß diese ganzen Tunnel entweder parallel oder rechtwinklig zueinander  
verlaufen. Wir haben dann eine Tabelle von Schatzkammern, und nicht nur eine,  
sondern in die Tiefe gestaffelt, viele, sozusagen eine 3D-Tabelle. Eisen & Kohle  
... . Desgleichen( =dito, also dto., grmpf;( ) eine 3D-Tabelle von den  
Autobahnen. Wir hätten also, wenn wir jetzt mal noch mehr basteln würden, in  
unserem Text ein Oben, Unten, und die Himmelsrichtungen, meines, vielleicht  
vorschnellen, Erachtens. Und wir hätten das Erz geschmolzen, die Kohle  
gereinigt. Das Ruhrgebiet ist jetzt quadratisch, praktisch gut, & die Briketts  
sind sauber gestapelt. Im Tunnelsystem brennt noch kein Licht, wofür auch, es  
gibt ja, - noch - , keine Hinweisschilder, und dbzgl. kriegen die Schatzkamern  
jetzt mal Namen?  
  
OK, wir machen extremes TF-IDF. Soll heißen wir denken mal nach, was suchen wir  
eigentlich? Eisen, Kohle, Kobalt, Nickel, Kupfer, Zinn, arghs, nein. Vielleicht  
steht das schon irgendwo? Also m.E. evtl. schon im Schlagwortindex, den wir aber  
noch nicht haben. Also stop, und ich glaube jetzt müssen wirklich WIR denken, &  
nicht der Computer. Wir müssen uns eine Liste der Wörter erarbeiten, die wichtig  
sind, also VIP-Wörter. Das sind, bei wie immer gebotener Userzentriertheit, DIE  
Worte, die die Menge aller User jemals eingegeben hat, und die keine "Unworte"  
sind, siehe oben( s.o. ). Also wir rennen jetzt einfach mal los. PAUUUUTZ! Wir  
sind mit dem Kopf gegen die Wand gerannt, totzdem, wir haben was gelernt. Wir  
sind jetzt bescheiden und werten nur noch Fragen aus, die von wenigen  
Auserwählten gestellt werden. Sozusagen Volksvertretern. Das sind dann schon mal  
weniger, und dann klappt das auch, selbst wenn alle dureinanderreden wie an der  
Börse ja auch. Zumindest ein Anfang wäre gemacht, der ja dann ergänzt werden  
könnte ... . Wir haben also jetzt also eine ganze Menge an möglichen  
Suchwörtern. Und jetzt? TF-IDF( ->WIKIpedia ). Also kurz: Wir zählen bzgl. jedes  
Suchwortes in jeder Schatzkammer, wie oft wir an die dortigen Briketts ein  
Schild "Treffer" hängen könnten. Machen wir das einfach mal. Und nochmal und  
nochmal. Am Ende hängen meinetwegen an jedem Brikett 100 Schilder, egal erstmal.  
Und meinetwegen werden die Hauptbriketts vergoldet, per Grammatik, später das  
auch noch, aber erstmal wird verglichen. Die Menge aller Briketts mit dem  
gleichen Schild wird jeweils pro Schatzkammer gezählt. Wovon am meisten drin ist  
das schreiben wir an eine Eingangstafel, die wir an den Höhleneingang hängen.  
Selbstverständlich, als ordentliche Wichtel, gewichten wir noch rum, und wägen  
ab. In den anderen Schatzkammern ist von derselben Sorte Briketts auch ein  
Haufen. Also die Schatzkammer mit dem größten Brikettstapel hat sich ein Schild  
verdient, sozusagen einen Wegweiser: "Hier sind die meisten DIVs". Weil es gibt  
DIVs zwar überall, die lauern zwar an jeder Ecke, aber DA kommen die scheinbar  
her, wir haben das Nest entdeckt, wovon die Plage ausgeht. Wir hängen gleich ein  
Schild hin: "Achtung! DIVS!", an den Eingang, und an jeden Eingang eins, so in  
der Art: "Also hier liegt zwar alles mögliche, aber in der Hauptsache eher DIVS".  
Fertig? Schön wär's. Und Schneewittchen? Also weiter.  
  
Wir geben uns mehr Mühe jetzt mit den Schildern. Wenn 118 DIVs in der Höhle  
sind, ist die Tafel 118x118, und die Höhle "Layout" z.B. hat 212x212. Simsalabim  
und voodoo, Quadratabweichung und eine Fehlertoleranz, wir wichteln weiter und  
hängen an jede Tür eine ganze Menge Schilder. Die grossen Schilder nach oben,  
die Kleinen nach unten. Und wir katalogisieren alle diese Schilder, in der  
Zentrale. Wir führen dort Listen. Z.B. eine Liste "DIV"s und eine Liste  
"Layout"s. Alarm in der Zentrale: Gefragt ist nach "DIV-Layout: Probleme beim  
Clearing. Hilfe!". Und, klappt's?  
  
Also: "DIV"s in den Schatzkammer S17, S23, S45, .. Sn, schön. "Layout"s in  
S18, S4711 und S69, auch schön. Schön für sich ist garnix, es muss harmonieren.  
Also wo sind zusammengezählt die "DIV"s und "Layouts"s am meisten. Schicken wir  
mal jemanden hin, kucken, ob dort auch noch "Clearing" zu finden ist. Wir finden  
"Clear", "Clearing", "Clear-Bug", "unclear". Wir bewerten die Treffer: "Clear"  
kriegt eine Eins+, "unclear" imerhin noch eine 4. Wir müssen gerecht sein. in  
"Clearing" ist zwar alles nötige gesagt worden, aber leider auch viel Falsches.  
Fehlerabzug. In "unclear" finden sich 4 Totalübereinstimmungen bzgl. der  
Buchstaben, aber das kleine c gilt nur halb. Oder alt gewichtet. Wir wichteln  
uns einen Wert von 0.75 für ein "OK, nur die Gross- & Kleinschreibung stimmt  
nicht". Also Trefferqualitat insgesamt 4,75 IdentischEinheiten( IE ). Aber  
ausserdem steht der Suchbegriff nicht am Wortanfang. 2 Punkte Abzug, 3? Also  
kurz gesagt: Fuzzy-Matching, die Qualität des Matchings wird gemapt auf eine  
normierte Skala, warum nicht [ 0, 0.25, 0.5, 0.75 .. 1 ]?  
  
Wir geben unsere Ergebnisse an die Zentrale. Die Zentrale sammelt die Ergebnisse  
der anderen Trupps. Und rechnet.  
  
S1: 4.75\*( (118x118) + (212x212) ) = soviel,  
S2: 4.75\*( (218x218) + (212x212) ) = soviel,  
S3: 3.75\*( (118x118) + (212x212) ) = soviel.  
  
Und der beste Treffer ist in S2. Wir machen Licht, und der Kunde fährt los.  
  
  
\-------------------------------------------------  
  
Phfftt, das war's. Lang geworden. Und grob, schnell, überfliegermäßig. Bin  
dankbar für jedes bischen Kritik am Text. Vielleicht a la "Käse\_Käse\_Käse" sollte  
besser heißen "So\_So\_So". Und schlagt mich nicht tot. Ich bin zwar ein alter  
Knochen, aber, was Foren angeht, ein junger Hund. Mit großen Pfoten.  
Und müde jetzt mal wieder. Darf ich das jetzt einfach mal so abschicken?  
  
Best regards  
Christian  
  
  
  
  
  
  
  
  
  

[Don P]

Hallo,

es ist eine Informations-Website mit Info-Seiten und einem Forum (ein wenig wie eine wiki). Beide werden durchsucht.

Das mit den Schlagwörtern ist so eine Sache - ich möchte ja gerade, dass die Suchmaschine sich selbst ein Bild macht.

[...]

Bekannte Suchmaschinen verwenden wohl eine Formel mit einer Gewichtung unterschiedlicher Kriterien (bei google z.b. die Verlinkung anderer Seiten auf eine bestimmte Seite sowie die eigene Bedeutung/Ranking dieser verlinkenden Seiten). So eine Formel muss man sich basteln.

...oder einfach Google arbeiten lassen. Wenn deine Seiten bei Google bekannt sind, kannst du ja dort nachfragen nach dem Muster

Suchbegriff1 Suchbegriff2 site:http://example.com

bzw.

http://google.de/search?q=Suchbegriff1+Suchbegriff2+site:http://example.com

Google liefert dann nur Ergebnisse von deiner Domain example.com.

Gruß, Don P

[Daniel Thoma]

Hallo Herzlicher,

Ein gängiges Schema, um die Relevanz von Dokumenten bezüglich einer Anfrage zu bewerten ist http://en.wikipedia.org/wiki/Tf–idf@TF-IDF. Neben der Häufigkeit des Suchbegriffes im Dokument wird dort auch die Aussagekraft des Suchbegriffes mit einbezogen. Man benötigt dazu allerdings erstmal einen Textcorpus. Außerdem kann MySQL sowas sicher nicht direkt.

Grüße

Daniel

[Christian Zill]

Hallo Herzlicher,

Ein gängiges Schema, um die Relevanz von Dokumenten bezüglich einer Anfrage zu bewerten ist http://en.wikipedia.org/wiki/Tf–idf@TF-IDF. Neben der Häufigkeit des Suchbegriffes im Dokument wird dort auch die Aussagekraft des Suchbegriffes mit einbezogen. Man benötigt dazu allerdings erstmal einen Textcorpus. Außerdem kann MySQL sowas sicher nicht direkt.

Grüße

Daniel

Könnte man nicht den von Dir angesprochenen Algorithmus sozusagen "prophylaktisch" über alle durchsuchbaren Dokumente drüberlaufen lassen? Und zwar bzgl. der Wörter eines Schlagwortindexes? Und den ermittelten TF-IDF-Wert dann in mySQL separat abspeichern, für jeden Textblock[1]? Also den Suchstring abklopfen auf Vorkommnisse etwaiger Schlagwortindex-Treffer[2], und die jetzt schon eingegrenzte Menge an noch in Frage kommenden Textblöcken in boolescher Art auf das Vorhandensein der "Neben"-Bedingungen[3] testet? Wg.mySQL & direkt weiss ich jetzt nicht genau weiter. Was sind "Closed Procedures" eigentlich genau? Kann man da evtl. eine Funktion mit antriggern, die solche "TF minus IDF" - Algorithmen durchführt? Oder wenigstens sowas Ähnliches was ich da mal angedacht habe jetzt? Fragen über Fragen von meiner Seite aus, leider, voerst.

[1] ...der Textblock XYZ hat folgenden Inhalt: "Ganz arg viel Fachchinesisch...., und der sibirischee Zwergtiger"
[2] Tiger: Zwergtiger, Riesentiger UND(?) "Tiger" in Weltkrieg, 2ter, Panzer
[3] Kampfkraft: Tiger->hoch, Äffchen->niedrig

Best regards
Christian

[Vinzenz Mai]

Hallo Christian,

Was sind "Closed Procedures" eigentlich genau?

meinst Du "Stored Procedures"?

Kann man da evtl. eine Funktion mit antriggern,

Trigger sind im Zusammenhang mit Datenbanken etwas ganz anderes.

"Ganz arg viel Fachchinesisch....,

Bitte verwende entweder überhaupt kein Fachchinesisch oder die dem Kontext
angemessenen Begriffe beziehungsweise die Begriffe dem Kontext angemessen.

Freundliche Grüße

Vinzenz

[Christian Zill]

Hallo Christian,

Was sind "Closed Procedures" eigentlich genau?

meinst Du "Stored Procedures"?

Ja. Danke.

Kann man da evtl. eine Funktion mit antriggern,

Trigger sind im Zusammenhang mit Datenbanken etwas ganz anderes.

Freundliche Grüße

Vinzenz

Das ist wohl auch richtig. Also mal das Ganze anders formuliert: Kann man nicht mit "Stored Procedures" von mySQL aus die bzgl. des Schlagwortregisters schon vorgesiebten Treffer-Textblöcke nochmal genauer auf die Wörter untersuchen, die in der Suchanfrage auch noch vorkamen, und die aber nicht im Schlagwortregister sind?

Best regards
Christian

[Christian Zill]

Hi,

Kann man nicht mit "Stored Procedures" von mySQL aus die bzgl. des Schlagwortregisters schon vorgesiebten Treffer-Textblöcke nochmal genauer auf die Wörter untersuchen, die in der Suchanfrage auch noch vorkamen, und die aber nicht im Schlagwortregister sind?

Evtl. eher mit  http://de.wikipedia.org/wiki/User_Defined_Function ? Gibt's die in mySQL? Augenblick..., also die gibts in mySQL. Zu prüfen wäre nur noch die optimale Art der Einbindung dbzgl.

[Daniel Thoma]

Hallo Christian,

Über die Implementierung habe ich mir jetzt einfach noch keine Gedanken gemacht.
Natürlich kann man da durch einige vorausberechnete Daten etwas erreichen.
Man kann schonmal für jedes Dokument den TF-IDF-Vektor berechnen.
Dann kann man nur noch die Distanz zwischen den Vektoren berechnen und danach sortieren.
Das Problem ist, dass man die Distanz zu jedem Dokument berechnen muss, man durchläuft also die komplette Tabelle. Vermutlich ist es geschickt, nur Dokumente zu auszuwählen die eines (der wichtigen) Wörter des Queries mindestens einmal enthalten. Dann hat man schonmal Dokumente weg, die ohnehin viel zu schlecht bewertet würden.

Grüße

Daniel