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

Проблемът с Recrawl: Поддържане на RAG Pipelines актуални

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

ragai-trainingdata-collectionvertical-aiuse-case

The Challenge

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

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

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

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

Подходът

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

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

Платформа като FourA управлява всеки от тези проблеми като приоритет от първостепенно значение.

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

За избора на proxy, Proxy Finder работи като част от всяко извикване на Single, Browser и Auto. Платформата избира работеща изходна точка за всеки request, връща нейния уникален идентификатор (id) в response meta.proxy и вие използвате повторно това id при следващи извиквания, когато трябва да се придържате към същата изходна точка. Вашият crawler не съдържа собствен алгоритъм за класиране на proxy-та. (Писахме защо размерът на пула спря да бъде разграничаващ фактор в Защо размерът на proxy пула спря да има значение през 2026 г..)

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

Ето как изглежда извикване за повторно обхождане за портал с документация, който изисква JS рендериране. Оставяме 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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["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). Екипите, с които сме разговаряли, изпълняват еженощни сравнения (diffs) спрямо предишното обхождане, генерират наново embeddings само за документите, които действително са се променили, и обновяват масиви от 500 източника за няколко часа реално време. Опашката от задачи остава ваша. Ротацията на proxy-та, решението за рендериране и определянето на успеха са наша грижа.

Резултати

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

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

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

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

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

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