Het is vrij ingrijpend. Op hoofdlijnen zijn er 2 problemen.
Probleem 1.
Het parsen van leestekens en speciale tekens is een beetje lastig. Denk bijvoorbeeld aan "t-mobile" en dergelijke dingen. In de zoekmachine die we destijds bij Teezir maakten (ik was daarvoor verantwoordelijk) gebruikten we daarom speciale rules om ervoor te zorgen dat deze dingen worden verwerkt als 1 token en niet als 2 tokens.
Het maken van een goede tokenizer is bijzonder lastig. Je zit met taal-constructies (kijk goed naar dat woord
) waarbij mensen streepjes, vraagtekens en andere tekens gebruiken, die je op de juiste manier wilt behandelen.
De mensen die NLP hebben gedaan als vak op de universiteit bedenken op dit moment dat het ook mogelijk is om tokenizers te maken op basis van machine learning en dat machine learning deze problemen oplost. Dat klopt en sterker nog, in het standaardwerk van Manning & Schutze (
http://nlp.stanford.edu/fsnlp/ ) wordt hier ook vanuit gegaan. Echter, deze redenatie houdt geen rekening met het feit dat query's meestal heel erg kort zijn, contextloos en dat de tokens die uit de query en de documenten rollen op elkaar moeten matchen. Zonder context gaat machine learning niet werken - en is een rule based tokenizer weer beter. En helaas... rule-based tokenizers zijn helaas weer niet goed in het verwerken van speciale tekens.
Per land heb je vervolgens ook weer iets andere regels... en ik denk dat je hiermee wel een vereenvoudigd beeld hebt gekregen van wat een hel het is om dit goed te doen
Probleem 2.
Standaard wordt in zoektechnologie gewerkt met een "inverted index". Google is hierin niet anders (er zijn zelfs publicaties over storage details te vinden). In simpele termen is een inverted index een index zoals achterin een boek, waarbij per token (uit bovenstaande tokenizer) een lijst van (document id's en woord id's) staan. Bij het zoeken worden de tokens horende bij de query opgezocht en hiervan worden de document id's vervolgens met elkaar gematcht. Snippets, phrase queries, etc. worden gemaakt op basis van de woord id's... en dan is er nog een hoop magie om scores te berekenen wat ik even achterwege laat voor het gemak.
Stel je nu eens voor dat je een beperkt aantal tokens toevoegt, die in een enorme hoeveelheid documenten voorkomen. Dit is exact wat er gebeurt bij het indexeren van speciale tekens. De lijsten die moeten worden gematcht worden vervolgens heel veel langer en daarmee wordt de performance een issue.
Een manier om dit op te lossen is door speciale tekens op basis van het type document anders te indexeren. '/*' heeft bijv. betekenis in C# en kan je zien als 1 token. '/**' zal dus 2 tokens worden (nl. '/*' en '*'). Dit vergroot het aantal tokens, maar maakt de tokenizer weer heel veel complexer.
Welke afweging hierin ook wordt gemaakt, in beide gevallen wordt de index van Google enorm veel groter. Omdat ze hun search engine in principe (wederom een oversimplificatie...) in-memory houden levert dat ook weer meteen performance problemen op. Als ik me goed herinner leverde de tests die wij destijds hebben gedraaid een index op die 1,5x groter was. Op Google schaal wil ik niet eens weten wat de impact daarvan is...
Kortom... tis allemaal niet zo makkelijk.
[Reactie gewijzigd door atlaste op 24 januari 2017 16:46]
) waarbij mensen streepjes, vraagtekens en andere tekens gebruiken, die je op de juiste manier wilt behandelen. 
