MongoDB toob otsingu ja vektorotsingu oma andmebaasi ka privaatkeskkondades

MongoDB teatas Bengaluru arendajaüritusel uutest otsingu- ja andmeotsingu võimalustest, millega ettevõte tahab vähendada üht levinumat takistust tehisarurakenduste tootmiskasutusse viimisel: ärirakendus peab leidma õige info õigel ajal, kuid ettevõtte andmed asuvad sageli eri süsteemides, eri õigustega ja regulatiivsete piirangute all.

Uudise keskmes on kolm suunda. Esiteks lisab MongoDB Voyage AI mudeleid kasutavad täpsema päringuotsingu võimalused. Teiseks teeb ettevõte Searchi ja Vector Searchi üldiselt kättesaadavaks ka MongoDB Enterprise Advancedi ja Community Editioni jaoks. Kolmandaks püüab MongoDB näidata, et tehisarurakenduste andmekiht ei pea alati tähendama eraldi vektorandmebaasi, eraldi otsingumootorit ja eraldi sünkroonimistorusid.

See on oluline just reguleeritud sektoritele, näiteks pangandusele, kindlustusele, tervishoiule, avalikule sektorile ja kriitilise taristu ettevõtetele. Nendes valdkondades ei saa andmeid alati avalikku pilve viia. Kui otsing, vektorotsing ja rakenduse operatiivandmed töötavad samas andmeplatvormis või kontrollitud privaatkeskkonnas, võib arhitektuur muutuda lihtsamaks ja paremini auditeeritavaks.

Samas tuleb MongoDB väiteid lugeda allikakriitiliselt. „Kuni 30 protsenti parem otsingukvaliteet” põhineb ettevõtte viidatud MAIR-benchmark’il ja Voyage’i juhiseid järgivate reranker-mudelite mõõtmistel, mitte sõltumatul ettevõttehanke auditil. Samuti oli kontrollimise hetkel dokumentatsioonis `voyage-context-4` märgitud veel eelvaate staatuses olevaks, kuigi pressiteates nimetati seda üldiselt saadavaks.

Artikli faktipõhi tugineb MongoDB 30. juuni 2026 pressiteatele, MongoDB ametlikule dokumentatsioonile, Voyage AI mudelite dokumentatsioonile, Gartneri hinnangule generatiivse tehisaru projektide ebaõnnestumise kohta, OWASP-i LLM-rakenduste riskiloendile, MongoDB SEC-i riskiteguritele ning Constellation Researchi varasemale analüütikukommentaarile Voyage AI omandamise kohta.

Mis täpselt muutus

MongoDB teatas, et Hybrid Search on üldiselt saadaval ning ühendab täistekstiotsingu ja vektorotsingu ühte päringuloogikasse. Täistekstiotsing sobib hästi täpsete terminite, nimede, koodide ja fraaside leidmiseks. Vektorotsing otsib tähenduse järgi: see aitab leida seotud sisu ka siis, kui kasutaja ei kasuta täpselt samu sõnu, mis dokumendis kirjas on.

Praktilises ärirakenduses on vaja sageli mõlemat. Kui kasutaja küsib „viimase kvartali lepingu muudatused”, peab süsteem aru saama nii sõnade tähendusest kui ka konkreetsetest dokumentidest, kuupäevadest, klientidest ja õigustest. Ainult semantiline otsing võib mööda panna täpsetest nimedest või koodidest. Ainult märksõnaotsing võib jätta leidmata samasisulise, kuid teise sõnastusega dokumendi.

Teine uus osa on Native Reranking MongoDB Atlases. Reranking tähendab, et süsteem ei piirdu esimese otsingutulemuste nimekirjaga, vaid järjestab tulemused teise mudeli abil uuesti. See on oluline RAG-rakendustes, kus keelemudel vastab kasutaja küsimusele andmebaasist leitud konteksti põhjal. Kui kontekst on vale või aegunud, on ka vastus suurema tõenäosusega vale.

Kolmas osa on `voyage-context-4`, mis on mõeldud pikkade dokumentide paremaks vektoriseerimiseks. Tavaline RAG-lähenemine lõikab dokumendid väiksemateks osadeks. See on praktiline, kuid võib kaotada tähenduse, sest lõik eraldatakse dokumendi laiemast kontekstist. MongoDB väitel suudab `voyage-context-4` luua lõikudele vektorid nii, et säilib rohkem tervikdokumendi tähendust.

Miks andmeotsing on tehisarurakenduste nõrk koht

Paljud ettevõtete tehisaruprojektid ei takerdu mudeli puudumise taha. Mudel võib olla võimekas, kuid kui see saab vale, vananenud või puuduliku konteksti, ei saa tulemus olla usaldusväärne. Andmeotsingu kvaliteet määrab sageli rohkem kui mudeli enda nimi.

RAG ehk retrieval-augmented generation tähendab, et vastuse koostamiseks otsitakse esmalt ettevõtte enda andmetest sobiv kontekst. Alles seejärel kasutatakse keelemudelit vastuse sõnastamiseks. See aitab vähendada väljamõeldud vastuseid, kuid ainult siis, kui otsing leiab õiged allikad ja kasutab kehtivaid andmeid.

MongoDB sõnum on, et eraldi süsteemide kokkuliimimine tekitab uusi riske. Kui operatiivandmed on ühes andmebaasis, otsinguindeks teises, vektorid kolmandas ja mudeli päringuloogika neljandas süsteemis, peab ettevõte tagama nende vahel järjepidevuse. Iga sünkroonimisviga võib tähendada, et agent või vestlusrakendus vastab aegunud seisust lähtudes.

See on eriti oluline süsteemides, kus andmed muutuvad kiiresti: klienditugi, partneriportaalid, hinnastamine, tellimused, arendusprojektid, logid, turvaintsidendid ja seadmehaldus. Kui rakendus loeb vana infot, võib viga edasi kanduda järgmisse tegevusse.

Mida Voyage AI siia lisab

MongoDB omandas Voyage AI 2025. aasta veebruaris, et tuua embedding- ja reranking-mudelid andmebaasikihi lähedale. Embedding tähendab teksti, pildi, koodi või muu sisu teisendamist arvvektoriks, mille järgi saab arvutada sarnasust. Reranker hindab hiljem, millised leitud tulemused vastavad päringule kõige paremini.

Voyage 4 mudeliperekonna kohta väidab Voyage AI, et `voyage-4-large` edestab üldotstarbelises Retrieval Embedding Benchmarki ehk RTEB võrdluses Google Gemini Embedding 001, Cohere Embed v4 ja OpenAI v3 Large mudeleid. See on tootja enda avaldatud võrdlus, kuid põhineb avalikul benchmark’il.

Uues teates on MongoDB jaoks tähtsam Native Reranking. Pressiteate järgi võib see parandada otsingukvaliteeti kuni 30 protsenti. Täpsustuses öeldakse, et näitaja põhineb Voyage’i instruction-following reranker’itel MAIR-benchmark’il ning mõõdab paranemist esimese otsinguetapi tulemuste järel. Seega ei tähenda see, et iga MongoDB rakendus muutub automaatselt 30 protsenti paremaks.

Oluline on ka kättesaadavuse staatus. Native Reranking on MongoDB pressiteate järgi public preview ehk avalikus eelvaates. See tähendab, et funktsioon on arendajatele testimiseks avatud, kuid selle käitumine, liidesed või piirangud võivad veel muutuda. Sellist lahendust ei tohiks kriitilises tootmiskasutuses võtta samamoodi nagu pikalt stabiliseerunud üldiselt saadaval teenust.

Search ja Vector Search jõuavad privaatkeskkondadesse

Suurim praktiline muutus puudutab MongoDB Enterprise Advancedi ja Community Editionit. MongoDB teatel on Search ja Vector Search nüüd üldiselt saadaval ka nendele kasutajatele. See tähendab, et Atlasest tuttavaid otsingu- ja vektorotsingu võimalusi saab kasutada ka oma hallatud keskkonnas, privaatpilves või kohalikes paigaldustes.

Community Editioni puhul on MongoDB dokumentatsioonis kirjas, et alates MongoDB Community Edition 8.2 versioonist saab kasutada täistekstiotsingut ja vektorotsingut otse andmebaasis. Toetatud on näiteks `$search`, `$searchMeta` ja `$vectorSearch` aggregation stage’id. Samas on oluline piirang: dokumentatsiooni järgi töötavad need võimalused Linuxi distributsioonidel, Dockeris ja Kuberneteses, kuid macOS ja Windows ei ole toetatud.

Enterprise Advancedi puhul on sõnum suunatud eelkõige organisatsioonidele, kes peavad hoidma andmeid oma taristus või rangelt kontrollitud privaatkeskkonnas. MongoDB teatel hindas enne väljalaset Searchi Enterprise Advancedi jaoks üle 20 suure panga ja finantsasutuse. See on ettevõtte enda väide, kuid see sobib laiemasse turuloogikasse: finantsasutused tahavad kasutada paremat otsingut ja RAG-i, kuid ei saa iga andmekihti avalikku pilve viia.

Selline samm paneb MongoDB konkureerima mitte ainult teiste andmebaasidega, vaid ka eraldi vektorandmebaaside, otsingumootorite ja pilvepõhiste RAG-teenustega. Konkurentide hulka kuuluvad näiteks Elasticsearch, OpenSearch, Pinecone, Weaviate, Qdrant, pgvectoriga PostgreSQL, Redis ja suured pilvepakkujad.

Miks see on äriliselt oluline

MongoDB on viimastel aastatel positsioneerinud Atlase ja oma andmeplatvormi tehisarurakenduste andmekihina. Selle loogika on selge: kui ettevõtte operatiivandmed on juba MongoDB-s, võib otsingu, vektorite, embedding’ute ja reranking’u lisamine samasse platvormi vähendada eraldi süsteemide arvu.

Ettevõtete jaoks tähendab see väiksemat arhitektuurilist keerukust. Vähem eraldi komponente tähendab vähem andmete kopeerimist, vähem õiguste eraldi seadistamist, vähem sünkroonimisvigu ja lihtsamat jälgitavust. See ei tähenda, et MongoDB oleks igas olukorras parim vektorotsingu või otsinguplatvorm, kuid integreeritud lahendus võib olla piisavalt tugev ja lihtsamini hallatav.

Gartner on hinnanud, et vähemalt osa generatiivse tehisaru projektidest jääb pärast kontseptsioonitõestust pooleli halva andmekvaliteedi, ebapiisava riskikontrolli, kasvavate kulude või ebaselge äriväärtuse tõttu. Sellises vaates müüb MongoDB mitte ainult uut funktsiooni, vaid lubadust vähendada üht levinumat juurutusprobleemi: andmekiht ei ole valmis.

Ka MongoDB enda SEC-i riskitegurid rõhutavad ettevaatlikkust. Ettevõte märgib oma aruannetes, et tehisaru ja masinõppe kasutamine toodetes, partnerlustes ja sisemistes tegevustes võib tuua maine-, õigus-, turbe- ja regulatiivseid riske. See on oluline taust: sama tehnoloogia, mida müüakse tootlikkuse ja täpsuse parandajana, loob ka uusi vastutuskohti.

Ekspertide ja juhtide vaade

MongoDB Core Productsi tootejuht Ben Cefalo ütles teates, et ettevõtete peamine takistus ei ole ainult keelemudel, vaid mälu, andmeotsing, täpsus ja vastavusnõuded. Tema väitel tekitab lisasüsteemide juurdepanemine rohkem tarnijaid, latentsust ja rikkevõimalusi. See on MongoDB jaoks ka äriline positsioon: andmebaas peaks olema koht, kus otsing ja kontekst kokku saavad.

Emergent Labsi juht Mukund Jha ütles MongoDB pressiteates, et nende agendid kirjutavad koodi, muudavad andmestruktuure ja loevad tulemust tagasi miljoneid kordi päevas. Tema sõnul hakkab vale või aegunud otsingutulemus sellises töövoos kiiresti viga suurendama. MongoDB kasutamine olevat võimaldanud neil hoida agente andmete jooksva seisuga kooskõlas ja jooksutada kahte miljonit rakendust skaalal. See on klienditsitaat, mitte sõltumatu audit, kuid kirjeldab hästi probleemi olemust.

Constellation Researchi analüütik Holger Mueller ütles pärast Voyage AI omandamist, et hallutsinatsioonide vähendamisel on kõige asjakohasem viis mudeli maandamiseks päring usaldusväärsesse andmebaasi. Tema hinnangul oli Voyage AI omandamine MongoDB klientide jaoks oluline, sest see tõi embedding’u ja reranking’u lähemale andmetele endile.

Turbevaates tuleb lisada OWASP-i hoiatus. OWASP-i LLM-rakenduste riskiloend toob välja tundliku info avaldumise, ebaturvalised pistikprogrammid ja liigse tegutsemisõiguse. RAG ja agentide töövood ei ole ainult otsingu täpsuse küsimus. Need on ka õiguste, andmekaitse, auditi ja ründepinna küsimus.

Eesti lugeja vaade

Eesti ettevõtete jaoks on MongoDB teade praktiline eelkõige kolmes kohas: andmeresidentsus, lihtsam arhitektuur ja prototüübist tootmiskasutusse liikumine. Kui andmeid ei saa avalikku pilve viia, kuid organisatsioon tahab siiski kasutada vektorotsingut ja RAG-i, muutub oma hallatud keskkonnas töötav otsingukiht oluliseks.

Avaliku sektori, finants- ja tervisevaldkonna puhul tuleb enne sellise lahenduse kasutuselevõttu teha andmekaitse- ja riskihinnang. Küsimused on samad nagu teiste andmeplatvormide puhul: kus indeksid asuvad, kuidas neid krüpteeritakse, kes pääseb päringutele ligi, kuidas logitakse kasutus, kas kustutamisnõuded jõuavad ka vektorindeksitesse ning kuidas välditakse seda, et mudelile antakse rohkem konteksti kui vaja.

Arendajale annab Community Editioni tugi võimaluse katsetada lokaalselt täistekstiotsingut, vektorotsingut ja hübriidotsingut ilma eraldi teenust ostmata. Kuid piirangud on olulised: ametliku dokumentatsiooni järgi on tugi seotud MongoDB 8.2 ja Linuxi-põhiste keskkondadega. Kui arendaja töötab Windowsi või macOS-i peal, tuleb arvestada Dockerit või Linuxi keskkonda.

Väikeettevõttele on MongoDB lähenemise peamine väärtus mitte „kõige uuem mudel”, vaid väiksem hulk liikuvaid osi. Kui klienditoe teadmistebaas, tootekataloog või sisemine dokumentatsioon on juba MongoDB-s, võib otsingu ja RAG-i lisamine samasse keskkonda olla lihtsam kui eraldi vektorandmebaasi juurutamine. Kui aga organisatsiooni andmed asuvad valdavalt PostgreSQL-is, Elasticsearchis või andmelaos, ei pruugi MongoDB kasutuselevõtt ainult selle funktsiooni pärast olla mõistlik.

Riskid ja piirangud

Esimene piirang on kättesaadavuse staatus. MongoDB pressiteade kirjeldab `voyage-context-4` kui üldiselt saadaval mudelit, kuid MongoDB dokumentatsioonis oli kontrollimise ajal sama mudel „preview” märgistusega. Ettevõtted peaksid enne tootmiskasutust kontrollima täpset SLA-d, tuge, versiooni ja kasutuspiiranguid.

Teine risk puudutab mõõdikuid. Kuni 30-protsendiline otsingukvaliteedi paranemine ei tähenda ühtlast paranemist kõigis andmestikes ja keeltes. Eesti keele, valdkonnaspetsiifiliste dokumentide, vigaste failide, OCR-tekstide või segakeelsete andmete puhul tuleb tulemust ise mõõta.

Kolmas piirang on see, et integreeritud platvorm ei kõrvalda andmekvaliteedi probleemi. Kui andmebaasis on vanad dokumendid, dubleerivad kirjed, ebatäpsed õigused või puudulikud metaandmed, leiab otsing endiselt vale või segase konteksti. Parem otsing ei paranda iseenesest halba andmekorda.

Neljas risk on tarnijalukk. Kui embedding’ud, reranking, otsing ja äriloogika ehitatakse tihedalt ühe platvormi ümber, võib hilisem liikumine teise andmebaasi või mudelipakkuja juurde muutuda kalliks. Avatud arhitektuur ja eksporditavad andmevormingud jäävad tähtsaks.

Viies risk puudutab turvet. Kui agent saab pärida andmebaasist liiga laia konteksti, võib ta väljastada kasutajale infot, mida inimene ise ei oleks tohtinud näha. Seetõttu peab RAG-rakendus austama samu õiguseid, rolle ja andmepiire, mis kehtivad tavalises rakenduses.

Mida edasi jälgida

Esimene asi on MongoDB dokumentatsiooni ja tegeliku saadavuse ühtlustumine. Kui pressiteade ütleb „üldiselt saadaval”, kuid dokumentatsioon näitab „preview”, peab ettevõte kontrollima konkreetset funktsiooni, keskkonda ja lepingutingimust.

Teiseks tuleb jälgida, kuidas Native Reranking liigub avalikust eelvaatest tootmisküpsesse kasutusse. Tootmiskeskkonnas on oluline mitte ainult kvaliteet, vaid ka latentsus, hind, piirangud, jälgitavus ja versioonikontroll.

Kolmandaks tuleb vaadata, kuidas MongoDB Community Editioni otsingu- ja vektorotsingu kasutus arendajate seas levib. Kui lokaalne katsetamine muutub lihtsamaks, võib see kasvatada MongoDB rolli prototüüpide ja väiksemate RAG-rakenduste alustehnoloogiana.

Neljandaks tuleb hinnata, kas MongoDB suudab tõestada oma väiteid sõltumatutes ettevõttejuurutustes. Turunduslikult on sõnum selge: vähem eraldi süsteeme ja täpsem otsing. Otsustavaks saab see, kas kliendid näevad päriselt väiksemat keerukust, paremat kvaliteeti ja madalamat kogukulu.

Kokkuvõte

MongoDB uus teade on osa laiemast nihkest: tehisarurakenduste väärtus sõltub üha rohkem andmekihist, mitte ainult mudelist. Kui rakendus ei leia õiget, värsket ja lubatud konteksti, ei päästa seda ka võimekas keelemudel.

Searchi ja Vector Searchi toomine Enterprise Advancedi ja Community Editioni jaoks muudab MongoDB positsiooni tugevamaks nende ettevõtete silmis, kes tahavad ehitada RAG-rakendusi oma taristus või privaatpilves. Voyage AI mudelite lisamine annab MongoDB-le täpsema otsingu ja ümberjärjestamise loo, mida ettevõte saab kasutada konkurentsis eraldi vektorandmebaaside ja otsingumootoritega.

Eesti ettevõttele on praktiline järeldus lihtne: enne tööriista valikut tuleb hinnata andmete asukohta, õiguseid, värskust, keelt, mõõdikuid ja vastavusnõudeid. MongoDB uus pakett võib olla tugev valik siis, kui operatiivandmed, otsing ja RAG peavad elama samas kontrollitud keskkonnas. See ei asenda siiski andmekvaliteedi, turbe ja vastutuse põhjalikku tööd.

KKK

Mis MongoDB teatas?

MongoDB teatas Bengaluru üritusel uutest otsingu- ja andmeotsingu võimalustest. Nende hulka kuuluvad Hybrid Search, Native Reranking, `voyage-context-4` ning Searchi ja Vector Searchi üldine saadavus MongoDB Enterprise Advancedi ja Community Editioni jaoks.

Mis on Vector Search?

Vector Search ehk vektorotsing otsib sisu tähenduse järgi. Tekst, pilt, kood või dokument teisendatakse arvvektoriks ning otsing leiab sarnasuse põhjal seotud tulemusi ka siis, kui päringus ei kasutata täpselt samu sõnu.

Mis on Hybrid Search?

Hybrid Search ühendab täistekstiotsingu ja vektorotsingu. See aitab korraga arvestada nii täpseid märksõnu, nimesid ja koode kui ka päringu üldist tähendust.

Mis on Native Reranking?

Native Reranking järjestab esimeses otsinguetapis leitud tulemused teise mudeli abil uuesti. MongoDB puhul töötab see Atlasis avaliku eelvaatena ja kasutab Voyage AI reranker-mudeleid.

Kas `voyage-context-4` on juba tootmisküps?

MongoDB pressiteade nimetab `voyage-context-4` üldiselt saadavaks, kuid kontrollimise ajal märkis MongoDB dokumentatsioon selle veel eelvaates olevaks. Enne tootmiskasutust tuleb kontrollida konkreetset dokumentatsiooni, SLA-d ja kasutuspiiranguid.

Miks see on ettevõtetele oluline?

Paljud tehisarurakendused vajavad täpset ja värsket konteksti ettevõtte enda andmetest. Kui otsing ja vektorotsing töötavad operatiivandmete lähedal, võib väheneda sünkroonimisvigade, vananenud andmete ja eraldi süsteemide haldamise risk.

Mida tähendab see Eesti arendajatele?

Community Editioni tugi annab võimaluse katsetada täistekstiotsingut ja vektorotsingut lokaalselt ilma eraldi pilveteenuseta. Samas tuleb arvestada, et MongoDB dokumentatsiooni järgi on tugi seotud MongoDB 8.2 ja Linuxi-põhiste keskkondadega.

Millised on suurimad riskid?

Peamised riskid on ebatäpne või aegunud andmekontekst, õiguste vale seadistus, tundliku info lekkimine, liigne sõltuvus ühest platvormist ning see, et benchmark’i tulemused ei pruugi korduda konkreetse ettevõtte andmetel või eesti keeles.