La strategio kiel dokumento — La sepna ĉapitro

Ĉapitro 6 — La strategio kiel dokumento, ne kiel kodo

Ni alvenas al la ideo, kiu plej ofte, en la rakonto de tiuj, kiuj konstruis RAG ekde 2023, aperas kiel "la afero, kiun mi volus kompreni de la unua tago".

Tradiciaj kadroj traktas la serĉstrategion kiel Python-kodon. Ĉu vi volas, por teknikaj katalogo, unue serĉi laŭ produkta kodo, poste laŭ ŝlosilvortoj, poste laŭ semantikaj vektoroj, kaj nur fine generi la respondon? Skribu funkcion. Ĉu vi volas, por fotoalbumoj, tute saltigi la tradician semantikan serĉon kaj fidi je specialigita rerankigilo por bildoj? Skribu alian funkcion. Ĉu vi volas, por entreprenaj filmoj, disigi la aŭdion de la vida trako, transskribi ilin aparte, trakti ilin kiel apartajn fontojn kaj poste rekombini ilin en la fina respondo? Alia funkcio denove. Ĉiu tipo de enhavo, ĉiu domajno, ĉiu kliento finas per generi branĉon de kodo, kiu diferenciĝas de la aliaj, ĝis la punkto, kie ŝanĝi strategion postulas programvaran liberigon, kodan revizion, testciklon, deplojon. La tempo inter "Mi havas ideon pri kiel plibonigi la serĉon en teknikaj manlibroj" kaj "La ideo estas en produktado" mezuras en semajnoj. Por ĉiu ideo.

La alternativa ideo estas triviala diri kaj profunda en siaj konsekvencoj: la strategia de serĉado ne estas kodo. Ĝi estas dokumento. JSON — strukturita teksta formato kiun ĉiu redaktisto, kun duonhoro da trejnado, povas legi — kiu diras: "unue provu ĉi tion, poste tion, se la unua fiaskas, pasu al la tria, reordigu tiel, respondu per ĉi tiu modelo." Ĉi tiu dokumento vivas en datumbazo, ne en deponejo. Ĝi modifiĝas per interfaco, ne per peto pri enŝovo. Ĝi versiiĝas, kopiĝas, specialiĝas por domajno. Strategio por teknikaj katalogoj, unu por fotoalbumoj, unu por instalaj manlibroj, unu por videoj, unu por aŭdio, unu por juraj kontraktoj, unu por bilanĉoj. Ĉiuj kunekzistas en la sama sistemo. Ĉiuj modifeblaj en reala tempo.

Tiuj, kiuj laboris kun ĉi tiu aliro — ni nomu ĝin, sen tro da fantazio, Meta-RAG — rakontas ŝanĝon de rapido, kiu iras preter la inĝenierado. Peto de kliento kiel "aldonu specifan serĉon por la produkto-kodoj, kiuj enhavas akronimojn kiel CMP40M aŭ RH1M" ne plu estas evoluiga bileto por du semajnoj. Ĝi estas nova paŝo aldonita al JSON-proceduro, rapide testita en prepara medio, promociita en produktadon en unu posttagmezo. La demando "kio ŝanĝiĝas se ni uzas alian re-rangiganton por la fotoj, konservante la aktualan por la teksto?" estas respondita per modifado de linio de konfiguracio. La eksperimento ne kostas, la malfarado ne kostas (sufiĉas restarigi la antaŭan version de la dokumento), kaj la akumulita scio — kio bone funkcias por certa tipo de enhavo — fariĝas versia kaj transigebla heredaĵo, ne la tacita scio de tiu, kiu skribis tiun partikularan branĉon de kodo kaj hodiaŭ estas en ferio.

Ekzistas ankaŭ interesa socia efiko, kiu aperas en organizoj kiuj adoptas ĉi tiun aliron. Kun strategioj kiel dokumento, la limo inter "evoluinto" kaj "spertulo-uzanto" ŝoviĝas. Cifereca bibliotekisto, entreprena arkivisto, domena fakulo — la estro de la teknika oficejo, la responsulo pri dokumentado, la produkta administranto kiu scias kiel neniu alia la verajn demandojn de la klientoj — povas legi strategion, kompreni kion ĝi faras, proponi modifojn, foje eĉ skribi ilin rekte. Li ne devas pasi tra la funelo de la evolua bileto, li ne devas klarigi al evoluinto aĵojn, kiujn la evoluinto ne scias (ĉar ne estas lia metio scii ilin). La RAG ĉesas esti produkto, kiun vi konsumas, kaj fariĝas ilo, kiun vi modelas laŭ via organiza scio. Tio, laŭ sperto de tiuj, kiuj provis ĝin, ŝanĝas la moralon de la projekto eĉ antaŭ ol la nombroj de la metrikoj.

Ne estas magio, kaj ĝi havas siajn kostojn. Necesas motoro, kiu efike kaj sekure ekzekutas ĉi tiujn strategiojn-kiel-dokumentojn. Necesas priskriba lingvo sufiĉe riĉa por kovri realajn kazojn kaj sufiĉe malriĉa por ne fariĝi alia Turing-kompleta en kaŝita formo. Necesas iloj por versioj, testoj, reeniro. Sed ĉi tio estas problemo de tiuj, kiuj konstruas la motoron — unufoje, kaj por ĉiuj uzantoj. La individua fina kliento vidas nur unu aferon: la eblecon evoluigi sian serĉstrategion je la rapido de pensado, anstataŭ je la rapido de la ciklo de programvaraj eldonoj. Kaj ĉi tio, por tiuj, kiuj estas en ĝi, estas silenta revolucio, kiu ankoraŭ ne trovis sian nomon en fakaj revuoj.

Fermado — La septa ĉapitro, post kelkaj monatoj

Komence de 2026, sumante la lecionojn de la antaŭaj ĉapitroj — la tabeloj kiuj perdiĝis, la rerankigantoj kiuj mensogis, la halucinoj heredititaj, la nubaj fakturoj kiuj kreskis pli rapide ol la valoro, la prometantaj sed rigidaj kadroj — iu, en Italio, komencis konstrui malsaman RAG-serveron. Skribita en Python, desegnita por funkcii sur alirebla hardvaro, kapabla paroli kun nubaj modeloj kiam ĝi konvenas, kaj kun lokaj modeloj kiam la privateco postulas aŭ la kosto ne estas justa. Servilo en kiu la serĉaj strategioj estas modifeblaj dokumentoj, la rerankiganto estas loka procezo sur GPU, la tabeloj ne perdiĝas ĉar ili estas traktataj kiel unuklasaj civitanoj, la fotoj ne heredas objektojn de polvaj arkivoj de aliaj epokoj, kaj la kosto por demando — kaj en mono kaj en datumoj eksfiltritaj al triaj partioj — estas konata kaj kontrolata ĝis la centimo.

Ni ne nomos la projekton. Ĉi tiu artikolo ne estas la loko por fari tion, kaj ni ne volas transformi esploron en reklamon. Sed se la antaŭaj ĉapitroj igis vin rekoni situacion, kiun vi travivas — ĉu ĉu entreprena chatbot respondas kun certeco al malĝustaj demandoj, RAG-projekto kiu ne ekflugas dum monatoj, nub-fakturo kiu kreskas pli rapide ol la utileco, kiun ĝi produktas, aŭ kreskanta dubo ke viaj konfidencaj dokumentoj vojaĝas al lokoj, kiujn vi ne konas —, tiam indas scii, ke ekzistas alia vojo, kiun iu en Italio iris, kaj kiu en 2026 komencis doni la unuajn respondojn, kiujn oni atendis en 2023.

La bona novaĵo estas, ke entreprena AI, fine, eliras la demonstracian fazon. La malbona estas, ke ĝi eliras portante ĉiujn vundojn de la vojo: gonflitajn kadrojn, dependecon de provizantoj, monolitaj arkitekturoj, malpurajn datumojn, silentajn erarojn, kaj iom da tendenco de la industrio vendi solvojn eĉ antaŭ ol kompreni la problemon. Ni rakontis ilin en ses ĉapitroj. La sepantan — la historion de kio okazas kiam iu fine faras la aferojn bone, kun pacienco, en la itala kaj en la malferma fonto — ni skribos baldaŭ, kun malpli da singardeco pri la nomoj kaj pli da nombroj sur la tablo.

Intertempe, se vi jam venis ĝis ĉi tie, vi jam faris pli da postmorto-analizo ol 90% de la decidantoj, kiuj nuntempe subskribas kontrakton por entreprena ĵabot sen demandi iujn el la demandoj, kiujn vi faris legante ĉi tiujn ĉapitrojn. Ĝi estas pli bona komenco ol tiu, de kie ili komencis. Kaj en la venontaj monatoj, la diferenco inter tiuj, kiuj faris ĉi tiujn demandojn, kaj tiuj, kiuj ne faris, estos tre videbla sur la fakturoj — kaj sur la respondoj, kiujn via AI donos al viaj klientoj.

Ĉi tiu enketo estis redaktita en aprilo 2026, bazante sur la sperto de dek ok monatoj pri desegno, konstruo kaj optimigo de entreprenaj RAG-sistemoj inter la fino de 2024 kaj la komenco de 2026.