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

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

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

ragai-trainingdata-collectionvertical-aiuse-case

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

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

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

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

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

Подходът

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

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

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

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

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

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

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

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 междинна страница, правилото validate.data.fail я прихваща. Резултатът, отчетен към вашето потребление, е application_fail. Не плащате за него, а вашият код за ingestion знае да опита отново с различен proxy, вместо да подава страница "Just a moment..." към вашите embeddings.

За по-големия масив от данни прилагате същия шаблон във вашата съществуваща опашка за задачи. Екипи, с които сме разговаряли, изпълняват нощни diff проверки спрямо предишното обхождане, генерират нови embeddings само за реално променените документи и обновяват масиви от 500 източника за няколко часа реално време. Опашката за задачи остава ваша. Ротацията на proxy адреси, решението за render и проверката за успех са наша грижа.

Резултати

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

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

Целта не е да се покаже, че тези процеси са магия. Целта е, че те са предвидими и рутинни. А именно това е необходимо за AI в продукционна среда. (За повече информация къде сметките спират да излизат при hosted LLM извличане, вижте Кога извличането с LLM спира да бъде рентабилно.)

Основен извод

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

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