Seznam jako jediný český fulltextový vyhledávač obsahuje ve výpisu výsledků náhledy stránek. Kdy jste je nasadili a jak vás ta myšlenka napadla?

Náhledy stránek jsme nasadili poměrně dávno. Už když jsme začali pracovat na vlastní verzi vyhledávání, tak jsme s náhledy počítali. To bylo zhruba v roce 2005. V rané fázi Seznamu největší invenci do služeb vkládal Ivo Lukačovič a myslím, že s tímto nápadem přišel on.

Váš první generátor náhledů jste postavili na Internet Exploreru. Proč jste zvolili právě tohle řešení?

Udělali jsme si průzkum a Internet Explorer z něj vyšel jako nejovladatelnější. Pokud někdo programuje pro Internet Explorer, jistě to potvrdí. Na jádro IE lze navěsit callbacky na velkou množinu akcí, které IE dělá. Pomocí nich se dá jádro ovládat, aby dělalo to, co chceme, a také tím můžeme sledovat jeho činnost.

Zbylé varianty, které jsme zkoušeli, nebyly v dostatečně pokročilé fázi, aby nabídly totéž. Další výhodou IE bylo, že náhled, který z něj generujeme, obsahoval pluginy, např. Flash. Pokud bychom v té době zvolili jiné jádro, museli bychom takové věci doprogramovat, aby byl náhled plnohodnotný.

Štěpán Škrob (1974)

• S Ivem Lukačovičem v letech 1996–97 vytvořil fulltextový vyhledávač Kompas.
• Dnes je produktovým manažerem ve vyhledávacím týmu v Seznamu.
• Rád létá s modely letadel.
• Píše na Seznam Fulltext Blog pod přezdívkou Solamyl.

Vytvořili jste vlastní aplikaci, která embedovala komponentu IE?

Generátor běžel jako služba ve Windows, která využívala komponentu Internet Exploreru. Spustila si asi 20 instancí IE, které načítaly stránky a po jejich načtení snímaly obrázky. Ty byly následně zmenšeny.

Jaký byl výkon tohoto generátoru?

Ve špičce tak 2–3 snímky za vteřinu. Ale to byl celkový výkon několika strojů. Používali jsme tenkrát 2–3 počítače.

Můžete se ptát, proč 20 IE udělá tak málo screenshotů. Má to dva hlavní důvody – za prvé veškeré stahování z IE ve Windows jde (je to tedy jen domněnka, ale všechny indikace k tomu spějí) přes jediný download manager, který omezuje celkový průtok dat, takže přidávání dalších IE od určitého bodu nepomáhá. A ten druhý důvod je, že focení některých stránek prostě trvá dlouho. Pokud stránka obsahovala Flash, tak jsme od okamžiku oznámení načtení celé stránky ještě čekali asi 20 vteřin, aby náhled obsahoval nějakou pěknou část a nikoliv jen bílou stránku „Loading…“.

Dnes bez problému pořídíme asi 20 náhledů za vteřinu.

Takže jste se rozhodovali i podle vlastností dané stránky. Jaké informace vás při tom zajímaly?

Kromě toho, zda stránka obsahuje Flash a jiné dynamické prvky, jsme zjišťovali, jaké má rozměry. Detekce dynamických prvků je důležitá pro určení doby čekání pro vyfocení a rozměry pak pro nastavení šířky okna prohlížeče.

Některé stránky byly optimalizované pro šířku 1024 px, jiné měly centrovaný design a 600 px. Pokud bychom obě snímali na 1024 px, tak by stránka s 600 px byla příliš úzká. Proto jsme podle těchto údajů volili optimální rozlišení pro snímání náhledů.

Nedávno jste spustili novou verzi generátoru. Ta je postavena na jádru Gecko. Proč jste vůbec dělali změnu?

S tím prvním systémem byla řada provozních problémů. Máme u nás spoustu serverů a administrátoři, kteří je spravují, nemůžou tolik času věnovat pouze jedné aplikaci. A první systém byl náročný na údržbu. Po spuštění běžel průměrně asi měsíc, pak byla zapotřebí údržba. Na naše poměry to ale bylo příliš často.

To je jediná věc, ve které je nový generátor lepší?

Je jich víc, zkusím je shrnout:

• větší rychlost
• větší spolehlivost (původnímu generátoru se čas od času některé náhledy nepovedly)
• menší náklady na údržbu

Hodně nám záleželo právě na rychlosti. Před časem jsme zlepšili robota fulltextového vyhledávání, takže dnes stahuje stovky stránek za vteřinu. Vedle toho generátor náhledů zvládal ony 2–3 stránky za vteřinu. Proto byly náhledy někdy zastaralé.

O kolik bude nový generátor výkonnější?

Výkon ještě ladíme, ale už dnes bez problému pořídíme asi 20 náhledů za vteřinu. Tam, kde jeden původní stroj zvládal 1 náhled za vteřinu, jich nový zvládá 10. A budeme ještě zrychlovat.

Je nový generátor architektonicky podobný původnímu systému?

Současná verze je řekněme o generaci dál. Celá aplikace je mnohem rozsáhlejší. Původní verze se starala jen o generování náhledů. Nová verze obstarává také jejich výdej. Jedná se o velké množství malých obrázků, které by nebylo efektivní nabízet jako statické soubory z webserveru, proto jsme tyhle dvě funkce zkombinovali dohromady.

Která jádra prohlížečů jste zvažovali?

Než jsme začali pracovat na nové verzi, udělali jsme si nový průzkum HTML enginů. Horkým kandidátem byl WebKit. To bylo ale již před časem a tehdy neběžel WebKit na Linuxu ještě tak optimálně, jak bychom chtěli. Dokázali jsme přes něj generovat náhledy, ale byl tam problém s Flashem a nedokázali jsme se dostat na DOM stránky. Právě tohle šlo totiž s IE jednoduše, u něj jsme před sejmutím náhledu ze stránky získali potřebné informace a podle nich jsme snímání náhledu uzpůsobili.

WebKit ale vypadá nadějně a pokud se bude někdy dělat třetí generace, tak bude určitě ve hře. My jsme vybrali projekt MozEmbed, což je embedovaná Mozilla. Jednoduše řečeno jádro prohlížeče (Gecko) zabalené do knihovny.

Ovšem co se týče ovladatelnosti, z enginů, které jsme zkoušeli, je na tom asi nejhůř. Má velmi slabé možnost ovládání. Můžeme nabídnout URL a sejmout náhled, ale kupříkladu zjistit rozměr stránky nebo přítomnost Flashe, JavaScriptu apod., to se z rozhraní dost dobře nedá.

Na druhou stranu Gecko řešilo naše problémy. Vytvářelo náhledy pěkné a spolehlivě i včetně Flashe. A to nakonec převážilo. Získání vlastností stránky jsme vyřešili jinak. Stránka se nyní zpracovává dvoufázově. Je tam předřazená aplikace, která stránku načte a zjistí z ní potřebné údaje.

Podle provozu, který nyní máme, bych řekl, že Mozilla funguje spolehlivě.

Náhledy tedy snímáte za stejných podmínek, jak stránky vidí uživatel, tedy včetně JavaScriptu a pluginů?

Ano, ten JavaScript je dobře poznat na mapách. Většina mapových aplikací, jako jsou Mapy.cz, to jsou jen holé stránky. Mapové dlaždice se již nahrávají JavaScriptem. Kdybychom používali jen čistý HTML engine, ve většině takových případů bychom viděli jen prázdnou stránku.

Určitě bychom chtěli generovat náhledy i pro URL, které vedou do světa.

Jak jste v tom případě připraveni na bezpečnostní problémy prohlížečů?

Vše běží na oddělených virtuálních serverech. Není tam přímý přístup k železu a síť je nastavená tak, aby se z nich dalo dostat jenom tam, kam se mají dostat. Takže to je určité bezpečnostní opatření pro tuhle aplikaci.

Ale i kdyby. Tím, že jsme použili Mozillu a máme řešení na Linuxu, to pro nás znamenalo extrémní zvýšení bezpečnosti proti Windows. Původní systém běžel na Windows Serveru. Když si člověk představí, že tam běžel puštěný Internet Explorer a za každý den navštívil necelých 100 tisíc náhodných stránek z internetu. Na těch strojích běžel antivirus, ale i přesto…

…se občas zavirovaly?

Antivirové programy umí spolehlivě odstranit pouze známé viry. U zcela nových virů používají heuristiky a snaží se rozpoznat podezřelé chování. I když je to velmi účinné, není to nikdy 100 %.

Ovšem, pokud bych měl první systém postavený na Internet Exploreru zhodnotit, tak abych pravdu řekl, ještě dnes jsem v šoku z toho, že dokázal běžet tak dlouhou dobu sám bez dozoru, aniž by se o něj někdo musel starat. Když tedy pominu onu údržbu přibližně jednou za měsíc.

Nedovedu si představit, že bych na svém notebooku denně otevřel desítky tisíc stránek a tak to dělal po celý měsíc bez restartu.

Setkali jste se už s tím, že by se někdo snažil „optimalizovat“ svůj web pro co nejlepší náhled v Seznamu? A třeba i podváděl, např. zobrazil generátoru náhledů místo webu obrovskou fotografii spoře oděné slečny a snažil se tak zvýšit proklikovost na svůj odkaz v Seznamu?

Ano přesně s tím jsme se setkali, ale bylo to v počátcích v roce 2005. Náhledy se objevily jako novinka a našli se i vtipálci.

Když na něco takového přijdete, co s takovým podvodníkem provedete? Vyřadíte ho z indexu?

Řešíme to individuálně, jelikož to není standardní případ. Rozhodně se smazal ten náhled.

Nedávno Seznam oznámil, že nahradí u vyhledávání ve světě Google za technologii Live Search od Microsoftu. Mezi důvody padla i možnost vkládání náhledů do výsledků od Live Search. Takže uvažujete o tom, že budete mít náhledy pro celý Web? Nebo jen nějaké vybrané stránky?

Existuje plugin do Firefoxu, který do vyhledávačů přidává náhledy. U všech odkazů zobrazuje náhled homepage. A to nám nepřipadá technologicky složité. Ve stejné kvalitě to zvládneme také. Takže určitě bychom chtěli generovat náhledy i pro URL, které vedou do světa a uvidíme, jak to půjde.

V původním generátoru byly náhledy identifikované skrze ID stránky, kterou máme v databázi. To prakticky znamenalo, že jsme nemohli mít náhled pro URL, kterou nemáme v databázi. S tím by nám screenshotování ve světě nešlo, protože to nejsou URL z naší databáze. V novém  systému je náhled identifikovaný přes URL, a proto jsme schopni vytvářet náhledy pro libovolné adresy. Není to již úzce svázané s fulltextovým vyhledávačem.

Zkoumali jsme situaci, která kolem mikroformátů panuje. Je to takový začarovaný kruh.

Navíc v původním systému se zasílal požadavek např. na náhled s id=3. Věděli jsme, zda jej máme nebo ne, ale nemohli jsme ovšem dělat nic dalšího. V novém systému dostaneme URL, a když náhled pro danou URL nemáme, snažíme se URL zkracovat, dokud nějaký náhled nenajdeme. V nejhorším případě to skončí u náhledu homepage toho webu. Tím bychom měli eliminovat chybějící náhledy ve vyhledávání. To se totiž ukázalo jako problém. Uživatelé na takové výsledky méně klikají.

Řekněme, že jsem redesignoval svůj web a Seznam stále zobrazuje moje původní náhledy. Jak dlouho mám čekat, nebo můžu celý proces nějak urychlit?

Záleží, o jak navštěvovaný web se jedná. U webů typu Root.cz se náhled hlavní stránky aktualizuje v řádu dvou týdnů. Pokud web není tolik navštěvovaný, je možné si jednoduše nechat nové náhledy vygenerovat. Pro všechny stránky, které vložíte do přidávacího formuláře – a je jedno, že ty stránky již vyhledávač zná – se vygenerují náhledy zhruba do čtvrt hodiny.

Vyhledávač Seznamu začal před několika týdny podporovat mikroformát geo. V čem  podpora spočívá?

Tak o mikroformátech obecně jsme již nějaký čas věděli a konkrétně mikroformát geo se nám líbil nejvíc. Pokud jej někdo použije na své stránce, objeví se u stránky ve výsledcích hledání navíc odkaz „Zobrazit na mapě“.

Zkoumali jsme situaci, která kolem mikroformátů panuje. Je to takový začarovaný kruh. Lidé ve stránkách mikroformáty moc nepoužívají, protože je vyhledávače nepodporují. A vyhledávače je nepodporují, protože mikroformáty nikdo moc nepoužívá.

Vy tedy ten kruh chcete v ČR prolomit?

Ano, aby se ten kruh dal prolomit, řekli jsme si, že uděláme podporu do našeho vyhledávače.

Uvažujete do budoucna o podpoře některých dalších mikroformátů?

Dívali jsme se i na další mikroformáty. Jsme schopni je rozpoznat na stránkách a přečíst z nich informace. Ale je otázka, jak je je jednoduše prezentovat, aby to ve výsledcích hledání bylo přínosné a nerušivé.

Plánujete používat mikroformáty i přímo na webech Seznamu? Čili sami psát HTML pomocí mikroformátů?

Zatím jsme do katalogu Firmy.cz všude doplnili mikroformát geo. Ale ty stránky obsahují i kontaktní informace, tam bychom mohli využít i mikroformát hCar­d.

Blíží se příchod IE8. Ten obsahuje vylepšené integrované vyhledávání s našeptávačem a podporou náhledů. Budete tuto novinku využívat? Uvidíme např. náhledy Seznamu přímo v našeptávači IE8?

Náhledy ve fulltextovém vyhledávání jsou poměrně velké a nejsem si jistý, zda by byl našeptávač IE8 stále tak ergonomický, kdybychom je do něj přidali. Naopak u Zboží.cz jsou fotky produktů o řád menší. Proto myslím, že na Zboží.cz toho můžeme využít.

Zabrousím trochu do historie. Vy jste současně také autorem původního fulltextu Kompas.

Ano, zrovna nedávno jsem doma náhodou našel jeho zdrojáky. (smích)

To byl pokud vím první český fulltextový vyhledávač.

Jsem si jistý, že přede mnou určitě v ČR fulltextové vyhledávání psala řada lidí, ale Kompas byl asi první vyhledávač na zdejším internetu, který fungoval jako websearch. Vytvářel jsem ho na vánoce 1996 a běžel od jara 1997.

V jakém jazyce byl naprogramován a jak dlouho jeho vývoj trval?

Byl napsán v céčku. Já jsem vytvářel čistě vyhledávač. A největší implementační část jsem měl hotovu během vánočních prázdnin. Robota potom vytvářel Ivo Lukačovič, a ten byl v Perlu.

Vyhledávač má vždy dvě části, které lze zcela nezávisle oddělit. Tou první je robot. Jeho funkce je dodávat stránky, které mají být zaindexované. Druhou částí je vlastní vyhledávač. Ten bere od robota HTML stránky – v té době byly předávané přes STDIN – a vytváří z nich index. Já vytvářel tu druhou část.

Vychází stávající vyhledávač Seznamu nějak z původního Kompasu nebo byl kompletně napsán znova na zelené louce?

Nemají spolu nic společného. Mezi Kompasem a současným vyhledávačem byla několik let propast, kdy Seznam používal Jyxo a další vyhledávače. Teprve po tom se začal vyvíjet nový vyhledávač.

Kompas jste vytvořil sám s Ivo Lukačovičem. Kolik lidí se podílí na vývoji fulltextu dnes?

Když spočítám celý fulltextový tým, což zahrnuje i správce databáze, administrátory a vývojáře, tak je to okolo 30 lidí dohromady.

Je dnešní vyhledávač taky napsán v céčku?

Je napsán v C++. Některé části jsou v Pythonu, ale ty hodně výkonné části jsou v C++.

Dnes je v „módě“ tzv. test driven development. Máte k vyhledávači napsány nějaké testy, abyste hlídali jeho kvalitu?

Tohle je těžká otázka. Máme automatické testy, které dokáží kontrolovat funkčnost komponent. Týká se to ale jen těch komponent, které ze vstupů generují jasné výstupy, tam to jde kontrolovat.

Jenže testovat tímhle způsobem, zda ve vyhledávání někde není chyba, by bylo myslím nedostatečné, protože výsledek vyhledávání je závislý na spoustě faktorů, které se mění – internet se pořád vyvíjí.

Máme aplikaci pro kontrolu kvality vyhledávání. To je ale jiný nástroj a nesouvisí s progresivními metodami programování. Jsou lidé, kteří hodnotí dotazy, a tato aplikace na základě ručního hodnocení měří kvalitu vyhledávání. Tím ji můžeme sledovat.

První byl Kompas, nyní máte nový vyhledávač. Plánujete někdy do budoucna vytvořit třetí generaci vyhledávače znova na zelené louce? Nebo vám v boji s konkurencí postačí zlepšovat a vyvíjet dále stávající vyhledávač?

Abychom začali psát celou aplikaci úplně znovu, k tomu by musela nastat nějaká velká pauza, podobná jako nastala mezi Kompasem a současným vyhledávačem, kdy nemělo smysl navazovat.

Budeme vyvíjet verzi, jakou máme. To ale neznamená, že neděláme i velké změny. Náš vyhledávač se skládá z řady komponent. Pokud je potřeba něco zgruntu předesignovat nebo posunout technologicky dál, tak se nějaká část vyhledávače kompletně přepíše.

Nikdy se nestává, že by bylo třeba přepsal všechny komponenty. Ale když něco dosluhuje, přepíše se např. jedna komponenta, ale vztahy na ostatní komponenty zůstanou zachované.  Jako když na autě měníte letní gumy za zimní. Nejsou třeba dvě auta, kde by jedno vždy půl roku stálo v garáži. Jde to realizovat na jednom autě.

Děkuji za rozhovor.

Otázky za Zdroják kladl Martin Hassman, fotografie pořídila Ivana Dvorská.