← Всички публикации
Случай на употреба 5 мин. четене

Проблемът с повторното обхождане: Поддържане на RAG pipelines актуални

Вашата RAG база от знания остарява седмицата, в която я пуснете. Ето как екипите обхождат повторно стотици вертикални източници, без да надвишават инженерния си бюджет.

ragai-trainingdata-collectionvertical-aiuse-case

Предизвикателството

Стартъпите за вертикален AI се сблъскват с една и съща преграда около втория месец. Те пускат support copilot, асистент за правни проучвания или compliance bot. Първото демо печели клиенти. След това данните остаряват и отговорите започват да се разминават с реалността.

Наблюдавали сме екипи, които изграждат чисто AI частта, а данните остават на заден план. Ingestion pipeline-ът е един Python скрипт, работещ на нечий лаптоп. Той скрапва 200 изходни URL адреса веднъж, изсипва чист Markdown във vector store и всички празнуват. Шест седмици по-късно, половината отговори цитират премахнати страници, спрени API-та или продуктови функции, пуснати през март и променени отново през май.

Решението звучи просто: повторно обхождане на всеки източник всяка седмица. Реалността е по-грозна. До 2026 г. около 60% от реномираните сайтове блокират AI crawlers (спрямо 23% в края на 2023 г.), а защитите вече не са прости User-Agent проверки. Те анализират поведението на сесията, ритъма на request-ите и сигнали на ниво handshake. Наивен скрипт, който е работил през януари, тихо връща празни страници през март.

Още по-лошо, някои сайтове вече сервират tarpit съдържание (Markov-генерирани безсмислици, които приличат на реален текст), докато то не отрови вашите embeddings. Така инженерите ви прекарват половината си седмица в кърпене на скрейпъра, вместо да разработват продукта. Качеството на извличане спада, клиентите забелязват, а екипът, който сте наели да гради AI, се превръща в работилница за поддръжка на скрейпъри.

Подходът

Проблемът с повторното обхождане се разделя на три конкретни решения, които трябва да се вземат при всеки request:

  1. Render или не? Повечето портали за документация сервират чист HTML. Нарастващ дял (всичко изградено на Next.js, всичко с client-side rendering) се нуждае от пълно browser рендиране, за да върне полезно съдържание.
  2. Кой proxy? Residential, datacenter, mobile, geo-pinned, специфичен за ISP. Правилният избор се променя според целта.
  3. Всъщност проработи ли? 200 с празно тяло или CAPTCHA HTML страница е успешен HTTP request и провален crawl.

Платформа като FourA третира всяко от тях като приоритет от първо ниво.

За решението за рендиране извиквате Single за евтиния и бърз случай и Browser за JS-тежки цели. Тялото на извикването има същата структура, така че вашият ingestion код се разклонява веднъж чрез флаг за всеки източник, вместо да носи стотици специфични за сайта странности.

За избор на proxy, Proxy Finder работи като част от всяко Single, Browser и Auto извикване. Платформата избира работещ изход за всеки request, връща неговия непрозрачен id в response-а (на r.proxy top-level при Single/Browser или r.session.proxy при Auto) и вие преизползвате този id при последващи извиквания, когато трябва да се придържате към същия изход. Вашият crawler не носи собствен алгоритъм за класиране на proxy-та. (Писахме защо размерът на пула вече не е диференциатор в Why Proxy Pool Size Stopped Mattering in 2026.)

А за въпроса "всъщност проработи ли", всеки request поддържа validate блок. Вие декларирате какво се брои за успех: приети status codes, задължителни header стойности, низове в body, които трябва или не трябва да се появяват. FourA връща един от седем резултата и само success се таксува. 200, което се проваля на вашите правила за съдържание, получава печат application_fail и никога не влиза във вашия набор от данни.

Ето как изглежда едно извикване за повторно обхождане за портал с документация, който се нуждае от JS рендиране. Оставяме Auto да оркестрира. Той избира правилния продукт (Single, Proxy или Browser), справя се с bot защитите и връща сесийната тройка, така че следващият recrawl да може да се придържа към същия изход:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Ако целта хвърли Cloudflare interstitial, правилото validate.data.fail го улавя. Резултатът, отбелязан срещу вашето потребление, е application_fail. Вие не плащате за това, а вашият ingestion код знае, че трябва да опита отново с различен proxy, вместо да подава страница "Just a moment..." към вашите embeddings.

За по-широкия корпус обвивате същия модел във вашата съществуваща job queue. Екипите, с които сме разговаряли, изпълняват нощни diff-ове спрямо предишния crawl, преизчисляват embeddings само за документите, които действително са се променили, и опресняват корпуси от 500 източника за няколко часа реално време. Job queue-то си остава ваше. Промяната на proxy-та, решението за рендиране и присъдата за успех са наши.

Резултати

Как изглежда цикълът на свежест, след като инфраструктурата спре да бъде тясното място (илюстративен сценарий, базиран на модели, които виждаме в различни екипи за вертикален AI):

  • 500 изходни URL адреса, обхождани повторно всяка седмица, вместо еднократно обхождане на 200 URL адреса при стартиране
  • Инженерно време за скрейпъра: под 2 часа седмично, спад от 1 до 2 дни
  • Прозорец на остаряване на извличането: 5 до 7 дни, вместо неограничен
  • Процент на боклука във vector store близо до нула, защото Cloudflare interstitials и tarpit страници се отхвърлят на слой validate, преди да достигнат до вашия embedding модел
  • Предвидима цена на източник, защото провалените обхождания не се появяват в сметката

Целта не е, че някое от тези неща е магия. Целта е, че те са скучни. А скуката е това, от което се нуждае production AI. (За повече информация къде математиката спира да работи с хоствано LLM извличане, вижте When LLM Extraction Stops Paying for Itself.)

Ключов извод

Повечето екипи, изграждащи вертикален AI, смятат, че защитният вал е prompt-ът, изборът на модел или алгоритъмът за извличане. Не е така. Защитният вал е цикълът на свежест: небляскавата инфраструктура, която поддържа базата от знания честна седмица след седмица.

Екипите, които ще спечелят във вертикалния AI до 2026 г., няма да бъдат тези с най-умните prompt-ове. Те ще бъдат тези, чиито потребители никога не забелязват, че данните са актуални, защото те винаги са такива.