La motoro, kiu havis ses polusojn — La mito de la dek linioj de kodo

Enketo en ses epizodoj pri la kialoj, pro kiuj la dokumenta ĵaboto, kiun oni vendis al vi, daŭre elpensiĝas — kaj pri la malsama direkto, kiun iu komencis sekvi komence de 2026.

Enketo en ses epizodoj pri la kialoj, pro kiuj la dokumenta ĵaboto, kiun oni vendis al vi, daŭre elpensiĝas — kaj pri la malsama direkto, kiun iu komencis sekvi komence de 2026.

Enkonduko — La motoro, kiu havis ok polusojn (sed havis ses)

Milano, marto 2026. Administranto malfermas la internan entreprenan ĵaboton, el tiuj muntitajn "en du semajnoj" de la IT-oficejo kun granda entuziasmo kaj malmulte da suspektemo. Tre simpla demando: "Kiel multajn polusojn havas la motoro CMP40M?". La ĵaboto respondas kun ĉiuj certeco, kiun grandaj lingvaj modeloj scias montri: "La motoro CMP40M havas ok polusojn."

Erara. Ĝi havas ses. La ĝusta respondo ne troviĝis en la katalogo de 422 paĝoj, kiun iu, monatoj antaŭe, kun plena fido versis en vektora datumbazo, konvinkita ke de tiam la sistemo "scius ĉion". Tiu dato, en la katalogo, simple ne ekzistis. Ĝi troviĝis en PDF-dokumento aldoniĝinta al retpoŝto de la teknikistoj de SEW, arkivita en dosierujo, kiun neniu prenis la penon indici.

Ĉi tiu sceno, kun variaĵoj de sektoro kaj dialekto, ripetiĝas en centoj da oficejoj en Italio. La promeso estis simpla kaj alloga: donu al via AI-asistanto ĉiujn entreprenajn dokumentojn, kaj ĝi povos respondi al ajna demando pri ili. La realo estas multe pli proza: la chatbot legas sed ne komprenas, serĉas sed ne trovas, kaj kiam ĝi ne trovas — anstataŭ diri tion — inventas. Ĝi inventas flue, kun perfekta gramatiko, kun kredindaj nombroj. Kio estas multe pli malbona ol ne respondi.

Inter la fino de 2024 kaj la komenco de 2026, ni pasigis monatojn farante la aŭtopsion de ĉi tiuj fiaskoj. Ne por nutri polemikojn, sed por kompreni unu aferon: kial ideo tiel lineara — "donu al ĝi la dokumentojn kaj poste demandu aferojn" — fariĝas tiel malfacila kiam ĝi elvenas de la scenejo de la demonstro kaj eniras en la ĉambro de la veraj serviloj.

Ĉi tiu esplorado en ses ĉapitroj rakontas tion, kion ni trovis: silentaj eraroj, kiuj forigis tutajn katalogoojn, nubaj rerankigoj kun misaj poentoj, halucinoj naskitaj ne de la modelo sed de poluigitaj datumoj jarojn antaŭe, fakturoj elirantaj, kiuj igis ĉiun demandon pli multekosta ol ĝia valoro, kaj "popularaj" kadroj, kiuj promesas ĉion en dek linioj da kodo kondiĉe, ke oni ne petas tro multe de ili. Kaj en la lasta ĉapitro, la malsama direkto, kiun iu, silente, komencis sekvi komence de 2026 — arkitekturo en kiu la serĉstrategio ĉesas esti kodo kaj fariĝas dokumento, kiun ĉiu, en la firmao, povas legi kaj modifi.

Ĉiu ĉapitro staras memstare. Se vi volas komenci per la historio de la 342 malaperintaj tabeloj, aŭ per tiu de la mensoganta rerankigilo, vi estas libera fari tion. Sed la rakonto en sia tuteco havas moralon, kiu aperas nur fine: la entreprena RAG — tiu teknika akronimo, kiu staras por Retrieval-Augmented Generation, do "generu respondojn bazante sur dokumentojn, kiujn vi unue reserĉas" — ankoraŭ ne estas finita produkto. Ĝi estas limregiono. Kaj kiel ĉiuj limregionoj, ĝis nun ĝi estis rakontita ĉefe de vendistoj. Estas tempo aŭskulti ankaŭ tiujn, kiuj vivis en ĝi.

Ĉapitro 1 — La mito de la dek linioj da kodo

La slajdo estas identa en ĉiu konferenco pri AI ekde 2023: "Via entreprena dokumenta asistanto en 10 linioj de kodo." Sub la titolo, bloko de Python en pastelaj koloroj montras malferman fontan bibliotekon — tipe unu el tiuj famaj amerikaj, kies nomo evocas ĉenojn de arboj aŭ tibetajn lamo-jn — kiu ŝargas PDF-ojn, fragmentigas ilin, gluas ilin en vektora datumbazo kaj interdemandas ilin per lingva modelo. En kvin minutoj, vi havas chatboton. En kvin minutoj, la aplaŭdoj. En kvin minutoj, meza itala entrepreno konvinkiĝas, ke la problemo estas solvita kaj ke ĝia IT-fako povas fari ĝin en du semajnoj.

La problemo — tio, kion la slajdo ne diras — estas, ke la demonstro estas konstruita kun tri bone formatitaj PDF-oj, demando adaptita por kongrui kun la enhavo, scenejo sen realaj latencoj, kaj prezentanto, kiu provis la tuton dudek sep fojojn antaŭ ol suriri. En la realeco, entreprenaj dokumentoj estas geologia katastrofo: skanoj de skanoj, tabeloj kiuj superkovras la tekston, subnotoj kiuj enfiltriĝas en la alineojn, alfanumericaj kodoj kiel "RH1M" kiujn la fragmentilo tranĉas duone kredante ilin vortoj, bildoj kiuj enhavas sepdek procentojn de la utila informo sed kiun neniu vere elprenas, kaj dismetoj tiel kreivaj, ke ili postulas arkeologon pli ol analizilon.

La RAG — jen la ideo sub la kapoto — estas bonega ideo. Prenu la demandon de la uzanto, serĉu en via arkivo la plej relevantajn dokumentojn, pasigu ilin al la lingvomodelo kaj ricevu respondon bazitan sur tiuj dokumentoj. Teorie, ĝi elegante solvas la problemon de halucinoj: la modelo ne plu devas "savi" la respondon, ĝi nur devas "legi" ĝin en la pecoj, kiujn vi provizis. Praktike, ĉiu maŝo de la ĉeno — la dispecigo, la enmetado, la retrievado, la reordigado, la fina generacio — havas siajn manierojn rompiĝi, kaj la rompo rare manifestiĝas kiel videbla eraro. Ĝi manifestiĝas kiel iomete erara respondo. Tiam kiel tute erara respondo. Tiam kiel administranto, kiu demandas sin, kial li pagas por sistemo, kiu scias malpli ol la praktikanto.

La malferma-fontaj kadroj kiuj popularigis la RAG (Retrieval-Augmented Generation) estas faritaj por demonstri, ne por produkti. Ili estas elegantaj ĉenoj de abstraktigoj en kiuj ĉiu tavolo kaŝas neesprimitan antaŭsupozon: ke viaj PDF-oj havas decentan OCR-on, ke viaj fotoj jam estis priskribitaj, ke viaj tabeloj sekvas konvencion, ke la enmet-modelo vere parolas vian lingvon (spoiler: multaj bone parolas nur la anglan), ke via arkivo jam estis purigita de duplikatoj. Kiam unu el ĉi tiuj antaŭsupozoj fiaskas — kaj almenaŭ unu ĉiam fiaskas, preskaŭ ĉiam tri — la sistemo ne ĉesas funkcii. Pli malbone: ĝi ĉesas funkcii bone, sed daŭre donas respondojn. Glatajn, certajn respondojn, kaj ofte senkonektitajn de la vero.

Ekzistas frazo kiu cirkulas inter tiuj, kiuj konstruas ĉi tiujn sistemojn profesie, kaj kiun vi neniam legos en instrumaterialoj: "La RAG estas facile fari, kaj malfacile fari bone." Inter la unua demonstro kaj la servo en produktado estas abismo, kiu ne povas esti superata per aldono de GPU-oj aŭ ŝanĝo de modelo. Ĝi estas superata per kompreno de malfacila afero: kiam vi konstruas entreprenan RAG-on, vi ne skribas kodon. Vi dezajnas malgrandan, obstinan serĉmotoron surmezure por viaj dokumentoj, kun ĉiuj redaktaj elektoj, kiujn ĉi tio implicas — kio estas bruo, kio estas signalo, kion oni devas indici dufoje, kion oni devas forĵeti. Nur en la instrumaterialoj de dek linioj ĉi tiuj elektoj estas faritaj anstataŭe de vi, unufoje, de iu, kiu neniam vidis viajn dokumentojn. Kaj ili estas preskaŭ ĉiam la malĝustaj por via kazo.