Google voegt ondersteuning leestekens toe aan zoekmachine

Google heeft de mogelijkheden van zijn zoekmachine uitgebreid met ondersteuning voor leestekens. Dit maakt het onder andere gemakkelijker om zoekopdrachten gerelateerd aan informatica in te voeren. Voorheen werden leestekens uit de zoekopdracht gefilterd.

Socialemediaspecialist Henk van Ess hoorde van de verandering 'via het hoofdkantoor van Google' en deelde een mededeling hierover op zijn Twitter-pagina. Zijn bron brengt als voorbeeld dat er nu gezocht kan worden naar het verschil tussen '==' en '===' in Javascript. Ook worden er andere resultaten weergegeven wanneer een gebruiker een zoekopdracht met accolades en haakjes invoert. Een korte test leert dat de zoekmachine nu inderdaad leestekens ondersteunt.

Tot op heden werden alle leestekens in een zoekopdracht gefilterd, met uitzondering van tekens die geavanceerde functies in de zoekmachine activeerden, zoals aanhalingstekens en de asterisk. Dit leidde vooral bij programmeurs af en toe tot irritatie, als leestekens een integraal onderdeel van hun zoekopdracht waren. Nog niet alle leestekens zijn toegevoegd; onder andere de tilde en de schuine streep lijken geen afwijkende resultaten op te leveren.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (44)

Beter dat het er nu standaard in zit. Kun je tenminste gewoon zoeken op C# dingen. ben benieuwd hoe 'ingrijpend' zoiets is om toe te voegen.

[Reactie gewijzigd door cracking cloud op 24 januari 2017 10:42]

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]

Welke afweging hierin ook wordt gemaakt, in beide gevallen wordt de index van Google enorm veel groter.

Ze kunnen queries met tokens en zonder tokens al direct scheiden zodat de queries zonder tokens even snel verwerkt worden als vroeger en de queries met tokens door een aparte grotere index misschien iets langzamer verwerkt worden.

Pfff... Het korte antwoord is: Nee.

Verticale versus horizontale partitionering in search engines is nog zo'n onderwerp waar ik een heel boek over zou kunnen schrijven.

Optie 1 is het scheiden van documenten-collecties in een aparte index

Nee en een beetje ja. Ik zal het kort houden, dit is wat iedere serieuze zoekmachine doet, maar niet op deze manier. Scheiden op wel/niet de tokens gebruiken is daarbij niet heel nuttig, veel verstandiger is om te scheiden op taalmodel. Standaard zoek je vervolgens door 1 of 2 talen heen, afhankelijk van de query, land van herkomst, gebruikersprofiel, stand van de maan, etc, etc.

Dat komt door de impliciete aanname die je maakt, nl. dat zoekmachines binair werken zoals database queries. Die aanname is incorrect; het werkt vele malen complexer... Om een query met een goede kwaliteit (lees: goede zoekresultaten) op te lossen, heb je informatie nodig van hoe de taal als geheel eruit ziet binnen je query en hoe dat zich verhoudt tot het taalmodel en de documenten. Helaas betekent dat ook dat je een serieuze hoeveelheid (lees: representatieve steekproef) document-servers zal moeten raadplegen die de documenten hebben die matchen op de zoekvraag.

Ik maak het (veel) simpeler dan het is, maar dit betekent in de praktijk dat als je delen van je index gaat uitfaseren naar 'iets langzamers', in de praktijk alles langzamer gaat worden.

En daarin zit precies het probleem met leestekens: die zijn niet discriminerend voor een taalmodel, maar soms wel relevant. Dat betekent dus simpelweg dat het relevante deel van je index groter wordt. En dat betekent dus ook dat je niet een deel van je index kan afsplitsen in een aparte index.

Optie 2 is het scheiden van individuele tokens.

Theoretisch gezien kan dat inderdaad, praktisch gezien niet. Vrijwel alle serieuze experimenten die hiervoor in het verleden zijn uitgevoerd blijken qua performance een probleem te zijn. Dat komt m.n. door het extra netwerkverkeer.

Het punt is nl. dat tokens meer zijn dan alleen maar dingen die gebruikt worden voor een inverted index. Metadata van tokens in het dictionary worden ook gebruikt om de relevantie te bepalen van woorden, wat gebeurt op basis van statistieken van die tokens tov. het hele language model. Daarnaast heb je ook nog een direct index nodig, o.a. voor impliciete query expansion, abstract/snippet generation en zo nog wat meer.

Voor al deze dingen is het belangrijk dat je de documenten en inverted index bij elkaar houdt. En daarvoor is het belangrijk dat je dus de tokens die horen bij de documenten en de documenten zelf niet scheidt van elkaar.

Ik zei al wel dat ik wat dingen oversimplificeer. Bottom line is het antwoord op deze optie: Nee, dat kan niet.

En guess what, dat doet Google ook niet.

Speculatie van hoe het wel werkt...

Jawel, Google heeft wel degelijk een grote en een kleine "index" van het internet.

Bij Google gebruiken ze deze "kleine index" als een soort cache van het internet. Het doel ervan is de eerste -zeg- 50 documenten te bevatten die de meeste (zeg 95%) van de queries opvangen. Dit ding moet je alleen niet zien als een "kleine index", maar als een soort cache, die de relevante statistieken bevat van de grote index en een relatief kleine subset van de documenten. Hoe ze precies bepalen wanneer ze de grote index moeten raadplegen weet ik niet... dit is voor zover ik weet bedrijfsgeheim.

Deze cache (of "kleine index") vangt sowieso al het grootste deel van de zoekvragen op, omdat mensen niet ineens hele andere zoekvragen gaan stellen. Awesome.

Daarnaast hebben ze ook hybride indexes bij Google. Wist je bijvoorbeeld dat GMail vooral op disk werkt? Het zou mij niet verbazen als ze gewoon de leestekens op de lokale SSD's schrijven en de frequentere termen (lees: de niet-stopwoorden) in-memory houden. De snelheid van de langzaamste SSD in je cluster is dan de bottleneck geworden voor de snelheid van de query. Ik heb even een snelle rekensom gemaakt en volgens mij is dat snel genoeg...

Anyways... bottom line dus: geen aparte indexes voor dingen met leestekens.

Ik weet nog dat Mark Zuckerberg ergens in een interview zei dat het implementeren van bijvoorbeeld een simpele dislike-button een behoorlijk flinke operatie is. Dus de kans is best groot dat deze simpel ogende feature ook behoorlijk wat werk heeft gekost.

mark zegt ook dat mensen dumb fucks zijn, dat nieuws echt is, de views kloppen en hun advertentie programma accuraat is. van de steur zegt ook van alles [..] men zegt veel

Ze zeggen dat ze maar wat zeggen, maar dat zeggen ze maar.

Technisch gezien zal het heus wel meevallen. Het probleem met de dislike button was vooral een ethische volgens mij.

Zeker geen technisch probleem, ook niet echt een etisch maar meer een commercieel probleem.

Denk aan bedrijfs/product profielen waar mensen ineens een dislike op zouden kunnen zetten. Dat willen ze natuurlijk niet!

Bij Facebook is het al ingewikkeld om gewoon alles te sorteren op meest recent.

Hij gaat echt niet roepen het was een kwartiertje werk. Dan reageert iedereen van waarom zo lang gewacht?

C# kon je al lang op zoeken, al tijden toegevoegd aan whitelist

Inderdaad, al bijna zo lang als het bestaat. Voor heel veel veelgebruikte termen zijn gewoon uitzonderingen.

Volgens mij bedoeld hij de leestekens in de syntax..

Dit is toch wel dé innovatie van 2017!

Ik vind het zelfs vreemd. Vreemd dat dit nog niet kon.

Dat kon ook zeker allang, alleen niet in Google

Ik gebruik altijd http://www.symbolhound.com/
Mogelijk blijft deze van toegevoegde waarde, bij mijn weten zoekt deze op alle symbolen. Ben al jaren een erg dankbare gebruiker!

Dit gaat eindelijk ook het zoeken achter foutmeldingen verbeteren. Je krijgt dikwijls speciale karakters in de foutmelding die je gewoon copy&paste in google zwiert. Dat leverde ook niet altijd een goed resultaat. Ik vind dit in ieder geval super.

Vreemde tekens in een foutmelding is eerder een gebrek van het programma dan van een zoekmachine.

Dat ligt maar net aan de situatie en toepassing, beetje kortzichtig hoor.

.NET errors geven vaak direct de functieaanroepen en een stack dump weer, denk dus dat dat wel meevalt.

Ik meende mij te herinneren dat men al specifiek kon zoeken op worden of teksten met bijvoorbeel een + voor een woord om aan te geven dat dat woord er in MOET staan en een - als het woord er niet in mocht staan.

en als je tekst tussen "" zette dat hij dan tekst zoekt waar in die woorden bij elkaar staan.
of heeft deze nieuwe update ergens anders betrekking op?

Daarmee verfijn je je zoekopdracht, zie deze link voor meer uitleg: https://support.google.com/websearch/answer/2466433?hl=nl

Maar dit nieuwsbericht gaat juist over dergelijke leestekens kunnen behandelen als gewone tekst, zodat je ook echt op een + symbool kunt zoeken

Vind het dan wel knap dat men dan dus onderscheid kan maken, met name met de + en de -

Maar wel mooi dat het nu kan ^_^

Je kon voorheen niet opzoeken: "wat is een &". Dat kan nu wel.

ging dat al niet via advance search? https://www.google.com/advanced_search

VHIG dat Google een advanced search functie heeft. Handig!

VHIG?

Vandaag heb ik geleerd. Bvb: VHIG wat VHIG betekent!

Vandaag Heb Ik Geleerd. (Nederlandse variatie op het Engelse TIL, Today I learned)

Vandaag heb ik geleerd, variant op TIL van een of andere Reddit community

Speciaal voor jou......

Wat een verademing

Ah nice!

Heb persoonlijk wel gehad dat ik een stukje code had gezien, maar wist niet meer waar.. Of ik weet de oplossing voor een (terminal) probleem 'ongeveer' en kan dan een search doen op de delen die ik zeker weet.

Google, +1

Hele verbetering hoe meer informatie je kan toevoegen aan een zoekopdracht des te gerichter je kan zoeken. en je minder hoeft te filteren in de zoekresultaten.

Eindelijk!
Niet dat het dagelijkse zoekopdrachten inhoud, maar een aantal keer per jaar / kwartaal komt het toch wel voor dat je een zoekopdracht met leestekens wilt uitvoeren.

Beste nieuws van de week, ik ben primair onderzoeker maar wij scripten/programmeren zelf vele tools in Matlab/Simulink, F# en Java. Dat google leestekens uit zoekopdrachten filterde was een bijna dagelijks terugkerende ergenis Maakt mijn leven een stuk makkelijker in ieder geval!

Konden we voorheen niet gewoon op < enzo zoeken dan?