Fokus auf Suchqualität bei Lucene/Solr Revolution 2015

Ich bin gerade von der Lucene/Solr Revolution 2015 in Austin zurückgekommen und war sehr begeistert. Auf der Konferenz gab es…

Ich bin gerade von der Lucene/Solr Revolution 2015 in Austin zurückgekommen und war sehr begeistert. Auf der Konferenz gab es dieses Jahr viele spannende Vorträge, aber besonders spannend fand ich den Fokus auf die Suchqualität (Genauigkeit und Relevanz), auf das Problem, aus den Abfragen auf die Absicht der Nutzer zu schließen, das Nutzerverhalten zu verfolgen und dies zur Verbesserung der Relevanz usw. zu nutzen. Es gab diese Woche auch viele großartige Vorträge zu technologischen Themen, die das andere „Q“-Problem angehen – wir gehen immer weiter an die Grenzen dessen, was mit SolrCloud in großem Maßstab und unter Last möglich ist, indizieren Daten immer schneller mit Streaming-Technologien wie Spark und setzen Solr in immer mehr interessanten Bereichen ein. Big Data-Integrationen mit SolrCloud sind nach wie vor ein heißes Thema – und das zu Recht, denn die Suche ist wahrscheinlich die effektivste (einzige?) Antwort auf die explosionsartige Zunahme digitaler Informationen. Aber ohne qualitativ hochwertige Ergebnisse sind alle technologischen Verbesserungen in Bezug auf Geschwindigkeit, Skalierbarkeit, Zuverlässigkeit und dergleichen von geringem Wert. Quantität und Qualität sind zwei Seiten der gleichen Medaille. Quantität ist eher ein technologisches oder ingenieurwissenschaftliches Problem (Autoren wie ich, die zur „Kürze“ neigen, bilden hier eine mögliche Ausnahme) und Qualität ist ein Problem der Sprache und der Benutzererfahrung. Beide sind entscheidend für den Erfolg, wobei „Erfolg“ durch zufriedene Benutzer definiert wird. Was mich wirklich beeindruckt hat, waren die verschiedenen Methoden, mit denen die Leute das gleiche Grundproblem lösen – was will der Benutzer finden? Und wie können wir messen, wie gut wir uns schlagen?

Unser Lucidworks CTO Grant Ingersoll brachte den Ball in seiner Eröffnungsrede ins Rollen, indem er uns daran erinnerte, wie wir typischerweise Suchanwendungen testen, indem wir einen kleinen Satz von – wie er es nannte – „Lieblingsabfragen“ verwenden, die das Qualitätsproblem stückchenweise angehen, aber nicht annähernd lösen. Wir klopfen uns selbst auf die Schulter, wenn wir in Produktion gehen, und sind ziemlich selbstgefällig, bis echte Benutzer mit unserem System zu interagieren beginnen und die Tweets und/oder Anrufe beim technischen Support eintrudeln – und zwar nicht mit den Gefühlen, die wir erwartet haben. Wir brauchen bessere Methoden zur Entwicklung und Messung der Suchqualität. Ja, die Geschäftseinheit zahlt die Rechnung und hat bestimmte Standards (die, wie Grant betonte, in der Regel ihre Lieblingsanfragen sind), also geben wir ihnen Knöpfe und Regler, an denen sie drehen können, um ihre Nerven zu beruhigen und sie uns vom Hals zu halten. Aber wenn die Geschäftsregeln so allgegenwärtig werden, dass sie anfangen, die Aufgabe der Suchmaschine zu übernehmen, haben wir ein anderes Problem. Um das klarzustellen: Es gibt Situationen, in denen wir wissen, dass die Suchmaschine es nicht richtig machen wird, so dass wir eine manuelle Übersteuerung vornehmen müssen. Wir können entweder direkt ein Ziel ansteuern (mit einer Technik, die wir „Landing Pages“ nennen) oder das, von dem wir wissen, dass es die beste Antwort ist, an die Spitze setzen – so genannte „Best Bets“, die in Solr mit der QueryElevationComponent implementiert werden. Dies ist jedoch eindeutig ein Fall, in dem Mäßigung gefragt ist! Wir sollten diese Tools verwenden, um unsere Ergebnisse zu optimieren – d.h. um die unlösbaren Randfälle zu beheben, nicht um die Kernprobleme zu lösen.

Diese ad-hoc oder subjektive Art der Messung der Suchqualität, von der Grant sprach, ist allgegenwärtig. Der Grund dafür ist, dass Qualität – im Gegensatz zu Quantität – schwer zu messen ist. Was meinen Sie mit „am besten“? Und wir wissen aus eigener Erfahrung und aus unseren datenwissenschaftlichen Überlegungen, dass das, was für einen Nutzer das Beste ist, nicht unbedingt das Beste für einen anderen sein muss, und dass sich dies für einen bestimmten Nutzer im Laufe der Zeit sogar ändern kann. Qualität und Relevanz sind also „unscharf“. Aber was können wir tun? Wir sind Ingenieure und keine Hellseher, verdammt! Paul Nelson, Chief Scientist bei Search Technologies, zeigte uns dann, wie wir die Suchqualität (Präzision und Recall) auf objektive (d.h. wissenschaftliche!) Weise messen können. Paul hielt einen faszinierenden Vortrag, in dem er die Arten von Diagrammen zeigte, die man normalerweise in einem Fachvortrag sieht und die die allmähliche Verbesserung der Genauigkeit im Laufe der Entwicklung von Suchanwendungen verfolgten. Die Magie hinter all dem sind Abfrageprotokolle und prädiktive Analysen. Wenn Sie also über diese Daten verfügen (selbst wenn sie von Ihrer früheren Suchmaschinenanwendung stammen) und wissen möchten, ob Sie „Verbesserungen“ erzielen oder nicht, haben Paul und sein Team bei Search Technologies eine Möglichkeit entwickelt, diese Informationen zu nutzen, um im Wesentlichen Regressionstests für die Suchqualität durchzuführen – ziemlich cool, oder? Sehen Sie sich Pauls Vortrag an, falls Sie keine Gelegenheit hatten, ihn zu sehen.

Aber sehen wir den Tatsachen ins Auge: Computer dazu zu bringen, Sprache zu verstehen, ist ein schwieriges Problem. Aber anstatt die Hände in den Schoß zu legen, fangen wir meiner bescheidenen Meinung nach gerade erst an, uns mit der Lösung dieses Problems zu beschäftigen! Es geht los, Leute. Eines der schwierigsten Probleme in diesem Bereich ist die Namenserkennung. Chris Mack von Basis Technologies hat einen sehr guten Vortrag darüber gehalten, wie Basis seine Sprachtechnologien einsetzt, um dieses Problem zu lösen. Der Abgleich von Namen ist schwierig, weil es viele Mehrdeutigkeiten und alternative Darstellungsweisen von Namen gibt und viele Personen denselben Namen tragen usw. usw. usw. Der Familienname von Chris ist ein Beispiel für dieses Problem – ist es ein Lastwagen, ein Cheeseburger (buchstabiert Mac) oder ein Nachname? Für diejenigen unter Ihnen, die von Fast ESP auf Solr umsteigen (an dieser Stelle ein Lob an das Unternehmen in Redmond Washington, das den Enterprise-Support für Fast ESP eingestellt hat – vor allem unter Linux – vielen Dank für die vielen Verkaufsanregungen, Jungs! Vielen Dank!) – sollten Sie wissen, dass Basis Technologies (und ich glaube, auch Search Technologies) eine Lösung für die Lemmatisierung anbieten, die Sie in Solr einbinden können (eine umfassendere Methode für das Stemming). Ich war gerade auf dem Stand von Basis Tech, um mir eine Entwicklungskopie ihres Lemmatizers zu besorgen, damit wir ihn potenziellen Fast ESP-Kunden vorführen können, als ich Chris traf. Abgesehen von der Bekanntheit des Namens hat Basis Tech noch eine Menge anderer cooler Dinge zu bieten. Ihr Vorzeigeprodukt ist Rosette – eine erstklassige ontologie- und regelbasierte Klassifizierungsmaschine. Probieren Sie es aus.

Der nächste auf meiner Liste war Trey Grainger von CareerBuilder. Trey leitet dort ein Team, das sich mit der Erkennung von Benutzerintentionen beschäftigt und diese zur Erstellung präziserer Abfragen nutzt. Als ich den Titel von Treys Vortrag „Leveraging Lucene/Solr as a Knowledge Graph and Intent Engine“ zum ersten Mal sah, dachte ich, er und sein Team hätten mich übertrumpft, denn mein eigener Titel ist sehr ähnlich – große Geister denken ähnlich, denke ich (was im Fall von Trey sicherlich zutrifft, ein wenig Selbstverherrlichung meinerseits, aber hey, es ist mein Blogbeitrag, also lassen Sie mich in Ruhe!) Im Grunde genommen verwenden sie Klassifizierungsansätze wie maschinelles Lernen, um einen Wissensgraphen in Solr zu erstellen und diesen dann bei der Abfrage zu verwenden, um festzustellen, wonach der Benutzer fragt, und dann eine Abfrage zu erstellen, die diese Dinge und andere eng verwandte Dinge zurückbringt. Das „verwandt mit“ ist sehr wichtig, vor allem in dem Buzz-Word-Salat, der heutzutage die meisten unserer Lebensläufe prägt. Die Neuformulierung der Abfrage, die Sie vornehmen können, wenn Sie dies richtig machen, kann durch die Lärmtreffer schneiden wie ein heißes Messer durch Butter.

Trey ist auch der Co-Autor von Solr in Action mit unserem Tim Potter – ich habe bereits über dieses wunderbare Buch berichtet – aber es war cool, was Trey getan hat – er hat ein kostenloses, signiertes Exemplar der Person angeboten, die den besten Tweet über seinen Vortrag hatte. Nette Idee – ich wünschte, ich hätte daran gedacht, aber, ach ja, ich müsste erst ein Buch schreiben – wer auch immer gewonnen hat, stellen Sie dieses Buch nicht einfach in Ihr Regal, wenn Sie nach Hause kommen – lesen Sie es!

Simon Hughes von Dice.com, Treys Konkurrent im Bereich der Stellensuche, hielt einen sehr interessanten Vortrag darüber, wie sie maschinelle Lerntechniken wie die Latent Semantic Analysis (LSA) und Googles Word2Vec-Software einsetzen, um ähnliche Dinge zu tun. Sie setzen Lucene Payloads auf sehr interessante Weise ein und entwickeln Lucene Similarity-Implementierungen, um Abfragen neu zu ordnen – eine anspruchsvolle Aufgabe, die auch den Fachleuten gefallen würde (der Code, über den Simon sprach, ist als Open Source verfügbar). Der Titel des Vortrags lautete „Implementing Conceptual Search in Solr using LSA and Word2Vec“. Das Schlüsselwort hier ist „Implementieren“ – wie ich bereits in diesem Beitrag sagte, implementieren wir diese Dinge jetzt und reden nicht nur darüber, wie wir es meiner Meinung nach schon zu lange getan haben. Simon betonte auch die Bedeutung der Phrasenerkennung und ich war begeistert, als ich feststellte, dass die von Dice verwendeten Techniken in meine eigene Arbeit einfließen können, insbesondere in die Erstellung von Autophrasen-Wörterbüchern, die dann vom AutoPhraseTokenFilter übernommen werden können. Mit mir im Publikum saßen Chris Morley von Wayfair.com und Koorosh Vakhshoori von Synopsys.com, die einige Verbesserungen an meinem Autophrasing-Code vorgenommen haben, die wir hoffentlich bald bei Solr und github einreichen werden.

Tomoko Uchida von Rondhuit Co stellte uns ein Tool vor, an dem sie arbeitet: NLP4L – ein Tool zur Verarbeitung natürlicher Sprache für Lucene. In dem Vortrag betonte sie wichtige Dinge wie Präzision und Rückruf und wie man NLP-Techniken im Zusammenhang mit einer Lucene-Suche verwendet. Es war ein sehr guter Vortrag, aber ich stand zu nahe an der Tür – denn es war schwierig, einen Sitzplatz zu bekommen – und einige laute Leute im Flur machten es schwierig, gut zu hören. Das ist ein gutes Problem, denn dieser Vortrag wie auch die anderen waren sehr gut besucht. Ich werde mich weiter mit Tomoko unterhalten, denn was sie tut, ist sehr wichtig und ich möchte es besser verstehen. Domo Arrigato!

Ein weiterer faszinierender Vortrag wurde von Rama Yannam und Viju Kothuvatiparambil („Viju“) von der Bank of America gehalten. Ich hatte Viju bereits früher in der Woche kennengelernt, als er an unserem Solr- und Big Data-Kurs teilnahm, der von meinem Freund und Kollegen Scott Shearer geleitet wurde. Ich war als Teaching Assistant für Scott ausgewählt worden. Cool, ein TA, das hatte ich seit dem Studium nicht mehr gemacht, ich fühlte mich jünger … Jedenfalls hielten Rama und Viju einen wirklich großartigen Vortrag darüber, wie sie Open-Source-Tools für die Verarbeitung natürlicher Sprache wie UIMA, Open NLP, Jena/SPARQL und andere einsetzen, um das Q&A-Problem für Benutzer der BofA-Website zu lösen. Sie bauen auch eine Ontologie auf (hier kommen Jena und SPARQL ins Spiel), die mir, wie Sie vielleicht wissen, sehr am Herzen liegt, sowie NLP-Techniken wie die Erkennung von Parts Of Speech (POS).

Sie haben einige interessante Anpassungen an Solr vorgenommen, aber leider ist dies proprietär. Es war ihnen auch nicht erlaubt, diesen Vortrag zu veröffentlichen, indem sie ihre Folien online zur Verfügung stellten oder den Vortrag aufzeichneten. Die Leute haben mit ihren Handys Fotos von den Folien gemacht (ich nicht, das verspreche ich), wurden aber gebeten, diese nicht auf Facebook, LinkedIn, Instagram oder dergleichen hochzuladen. Auf einer der Folien befand sich auch ein Disclaimer, wie man ihn auf DVDs sieht – die geäußerten Meinungen sind die des Autors und werden nicht unbedingt von der BofA geteilt – ta da ta dum – lawyereze Gefasel, denn wir haften nicht für ALLES, was diese Leute sagen, aber es wird ihnen leid tun, wenn sie sich nicht an das genehmigte Skript halten! Sie werden mir also glauben müssen, dass es ein großartiges Gespräch war, aber ich muss hier vorsichtig sein – ich bewege mich vielleicht schon auf dünnem Eis mit der BofA-Rechtsabteilung und am Ende des Tages hat die Bank Of America bereits all mein Geld! Trotzdem war ich dankbar für diese Arbeit, denn sie wird mir persönlich als BofA-Kunde zugute kommen, auch wenn ich den Quellcode nicht sehen kann. Ihre intelligente Suche erkennt den Unterschied zwischen der Abfrage meines Kontostands und der Bestellung von Schecks. Wie man in Boston sagen würde – „Wicked Awesome“! Eine interessante Randbemerkung: Ramman und Viju haben erwähnt, dass der POS-Tagger, den sie verwenden, bei ganzen Sätzen (auf denen die Modelle trainiert wurden) sehr gut funktioniert, aber bei Satzfragmenten (Substantivphrasen) weniger gut – aber immer noch nicht so schlecht – etwa 80%. Mehr dazu in Kürze. Aber hey, Banken – man muss sie einfach lieben – lassen Sie mich nicht mit den Gebühren für Geldautomaten anfangen.

Zu guter Letzt (hoffentlich?) – wie mein Chef Grant Ingersoll zu sagen pflegt – war mein eigener Vortrag, in dem ich versuchte, mit all diesen coolen Sachen konkurrenzfähig zu bleiben. Ich musste aufpassen, dass ich ihn nicht Ted-Talk nenne, denn das ist ein patentiertes Markenzeichen und ich wollte nicht von der „Ted-Polizei“ erwischt werden. Beachten Sie, dass ich meinen Namen hier nicht in Großbuchstaben geschrieben habe – das ist ein eingetragenes Warenzeichen und wäre wahrscheinlich von den Ted-Autobots entdeckt worden. Aber genug von mir. Zuerst habe ich meine eigene Lieblingsbeschäftigung vorgestellt – warum wir an Präzision und Abruf denken sollten , bevor wir uns über Relevanzoptimierung Gedanken machen, denn technisch gesehen ist es genau das, was die Lucene-Engine tut. Wenn wir Präzision und Rückruf nicht richtig hinbekommen, haben wir ein Garbage-in-Garbage-out-Problem für die Ranking-Engine geschaffen. Ich habe dann ein wenig über Autophrasing gesprochen und wieder einmal meine New York – Big Apple Demo hervorgeholt. Ich gebe zu, dass es sich hierbei um ein Spielzeugproblem handelt, aber es zeigt, dass man das Problem der Phrasenerkennung und der Synonyme durchaus in den Griff bekommen kann, was die Präzision und den Rückruf auf 100% bringt. Obwohl es sich hier nicht um ein reales Problem handelt, habe ich die Rückmeldung erhalten, dass Autophrasing derzeit Produktionsprobleme löst, weshalb Chris und Koorosh (wie oben erwähnt) den Code gegenüber meinem ursprünglichen Hack für ihre jeweiligen Dot-Coms verbessern mussten.

Der Schwerpunkt meines Vortrags lag dann auf der Arbeit an der automatischen Filterung von Abfragen, bei der Sie die Substantivphrasen mit Hilfe des Field Cache aus dem Lucene-Index selbst erhalten (und ja, Hoss, äh Chump, es funktioniert großartig, ist weniger füllend als einige andere NLP-Techniken – und es gibt ein JIRA: SOLR-7539, schauen Sie es sich an). Dies ist in einer Situation mit strukturierten Daten nützlicher, in der Sie String-Felder mit Substantiv-Phrasen darin haben. Autophrasing eignet sich für Solr-Textfelder (d.h. tokenisierte/analysierte Felder), so dass sich die Techniken durchaus ergänzen. Ich werde Sie hier nicht mit den Details langweilen, da ich bereits drei Blog-Beiträge zu diesem Thema geschrieben habe, aber ich werde Ihnen sagen, dass die Verbesserungen, die ich in letzter Zeit gemacht habe, mich dazu veranlassen werden, einen vierten Teil zu schreiben – (hey, vielleicht kann ich einen Filmvertrag bekommen, wie der Typ, der Der Marsianer geschrieben hat, der als Blog begann … naaaah, seiner war technisch, aber meiner ist viel zu technisch und er hat keine NASA-Verbindungen … )

Jedenfalls füge ich jetzt die Auflösung von Verben und Adjektiven zu dem Mix hinzu. Das Query Autofiltering ähnelt jetzt langsam echtem NLP, daher nenne ich es NLP-Lite. „Pseudo-NLP“, „Quasi-NLP“ und „Abfragezeit-NLP“ sind weitere Begriffe, die in Frage kommen. Ich habe versucht, eine Demo dazu zu machen (die teilweise erfolgreich war), indem ich eine Musik-Ontologie verwendet habe, die ich gerade entwickle und bei der ich die Fragen „Wer ist in The Who“ und „Beatles-Songs, die von Joe Cocker gecovert wurden“ richtig beantworten konnte, aber Murphy war mir dicht auf den Fersen, so dass ich weitermachen musste, weil die „Time’s up“-Vollstrecker drohten und ich ein Flugzeug erwischen musste. Ich sollte sagen, dass die Techniken, über die ich gesprochen habe, das klassische NLP nicht ersetzen. Vielmehr nutzen wir (kollektiv gesprochen) das klassische NLP, um Wissensdatenbanken aufzubauen, die wir auf der Abfrageseite mit Techniken wie der automatischen Filterung von Abfragen verwenden können. Das ist sehr wichtig, und ich habe dies wiederholt gesagt – je mehr Werkzeuge wir haben, desto größer ist die Chance, dass wir das richtige für eine bestimmte Situation finden. POS-Tagging funktioniert gut bei ganzen Sätzen und weniger gut bei Satzfragmenten, wo sich der Query Autofilter auszeichnet. Es handelt sich also um „Front-End-NLP“ – Sie verwenden klassische NLP-Techniken, um die Daten zur Indexzeit zu durchsuchen und Ihre Wissensbasis aufzubauen, und Sie verwenden diese Art von Technik, um das Gold zur Abfragezeit zu ernten. Auch hier kann die „Wissensbasis“, wie Trey in seinem Vortrag und ich selbst betonen, der Solr/Lucene-Index selbst sein!

Schließlich habe ich über eine Arbeit gesprochen, die ich in Kürze veröffentlichen werde und die sich mit Auto Suggest befasst. Ich war auf der Suche nach einer Möglichkeit, präzisere Typeahead-Abfragen zu generieren, die sich über mehrere Felder erstrecken und die der Query Autofilter dann verarbeiten kann. Ich entdeckte eine Möglichkeit, Solr-Facetten zu verwenden, insbesondere Pivot-Facetten, um Phrasen mit mehreren Feldern zu generieren, und reguläre Facetten, um den Kontext zu ermitteln, so dass ich eine eigene Suggestor-Sammlung aus einer Inhaltssammlung erstellen konnte. (Die Pivot-Facetten ermöglichen es mir, ein Muster wie „genre,musician_type“ in „Jazz Drummers“, „Hard Rock Guitarists“, „Classical Pianists“, „Country Singers“ und so weiter zu verwandeln. Wenn ich also ein Pivot-Muster wie „Name,Komposition_Typ“ verwende, um Vorschläge wie „Bob Dylan Songs“ zu generieren, kann ich andere mit Bob Dylan verwandte Dinge wie „The Band“ und „Folk Rock“ abrufen, die ich dann verwenden kann, um einen Benutzerkontext für den Vorschlagenden zu erstellen. Wenn Sie nun nach Bob Dylan-Songs suchen, kann der Suggerator damit beginnen, diese zu verstärken, so dass Songtitel, die normalerweise ganz unten auf der Liste stehen würden, ganz oben erscheinen.

Das passt zu einer unheimlichen Sache, die Google tat, während ich die Musikontologie aufbaute – nach einer Weile begann es, lange Songtitel mit nur zwei eingegebenen Wörtern vorzuschlagen, wenn meine „Agenda“ für diesen Moment konsistent war. Wenn ich also zum Beispiel nach Beatles-Songs suche, werden mir nach ein paar Suchvorgängen bei der Eingabe von „ba“ (in der Kopfzeile) „Baby’s In Black“ und „Baby I’m a Rich Man“ vor den unzähligen Liedern die mit Baby beginnen, sowie alles anderen in ihrem Typeahead-Wörterbuch, die mit „ba“ beginnen. WOW – das ist cool – und das sollten wir auch können! (d.h. mehr „Google-esque“ zu sein, wie es einer meiner Kunden in seinem Geschäftsanforderungsdokument formulierte) Ich nenne es „On-The-Fly Predictive Analytics“ – wie wir im Geschäft mit der Suchqualität sagen – es geht immer um den Kontext!

Ich sage oben „last but not least“, denn für mich war das die letzte Sitzung, die ich aufgrund meiner bevorstehenden Flugbuchung besucht habe. Es gab ein paar Vorträge, die ich aus verschiedenen anderen Gründen verpasst habe (es gab einen Terminkonflikt, mein Unternehmen hat mich dazu gezwungen, einige Vorverkaufsarbeiten zu erledigen, ich war auf einer Wollsammlung oder beim Plaudern/Netzwerken usw.), bei denen die Autoren anscheinend auf der gleichen Suche nach Suchqualität waren. Vorträge wie „Nice Docs Finish First“ von Fiona Condon bei Etsy, „Where Search Meets Machine Learning“ von Leuten bei Verizon, „When You Have To Be Relevant“ von Tom Burgmans von Wolters-Kluwer und „Learning to Rank“ von diesen großartigen Solr-Jungs bei Bloomberg – die beide ‚Qs‘ großartig hinbekommen haben!

Da ich nicht in der Lage war, an diesen Vorträgen teilzunehmen und nicht aus einer Position der Unwissenheit darüber schreiben möchte, lade ich die Autoren (oder jemanden, der sich inspiriert fühlt, darüber zu sprechen) ein, Kommentare zu diesem Beitrag hinzuzufügen, damit wir hier eine Diskussion nach dem Treffen in Gang bringen können. Und jeder Autor, den ich erwähnt habe und der der Meinung ist, dass ich seine Arbeit falsch dargestellt habe, kann mich gerne korrigieren. Und schließlich sind alle, die an dem Wettbewerb „Tweet about Trey’s Talk and Win an Autographed Book“ teilgenommen haben, aufgefordert, Ihre Beiträge hier zu re-tweeten – äh zu posten.

Vielen Dank für die großartige Arbeit zu diesem wichtigen Thema der Suche. Vielleicht können wir Watson nächstes Jahr dazu bringen, einen Vortrag zu halten, damit wir sehen können, was die Computer über all das denken. Immerhin hat Watson alle Songtexte von Bob Dylan gelesen, also muss er (sie?) inzwischen ein ziemlich cooler Typ sein. Ich frage mich, was er über „Stuck Inside of Mobile with the Memphis Blues Again“ denkt? Um es mit den Worten des Liedes zu sagen: Ja, Mama, das ist wirklich das Ende. Also, bis wir uns nächstes Jahr bei der Revolution wiedersehen, viel Spaß beim Suchen!