Поверителността на AI данните се подобрява в Claude PDF работните процеси
Marktechpost AI Media Inc. пусна Token Saver на 30 юли 2026 г. — open-source MCP разширение за Claude Desktop, което използва локален хибриден RAG, за да намали разходите за токени при PDF файлове с 92% до 99%. За екипи, които работят с правни документи, годишни отчети и изследователски PDF-и, по-важната тема е поверителността на AI данните: файлът остава на локалната машина, а Claude вижда само пасажите, нужни за отговор на въпроса. Според публикацията на Marktechpost за релийза, инструментът се доставя като MIT-лицензирано разширение и не изисква Python среда или настройка през терминал.
Token Saver идва като локално MCP разширение за Claude Desktop
Обръщам внимание, когато инструмент за документи променя едновременно и разхода, и архитектурата. Token Saver е разработен от Arnav Rai по време на стаж в Marktechpost AI Media Inc., под ръководството на Jean-marc Mommessin и Asif Razzaq, и адресира добре познат проблем: всеки допълнителен въпрос по дълъг PDF може отново да задейства разходи за контекст.
Релийзът е важен, защото не просто компресира prompt-ове. Той променя пътя, по който се движат данните. Вместо да изпраща целия PDF отвъд границата към доставчика, Token Saver работи като локален сървър по Model Context Protocol и връща само подбрани пасажи. В изходната статия екипът твърди, че потреблението на токени е „slashed by 92% to 99%,“ което е достатъчно голяма разлика, за да има значение в реални процеси с интензивна работа по документи.
Защо PDF чатове в Claude изгарят токени при всеки следващ въпрос
В клиентска среда обикновено виждам едно и също погрешно допускане: хората мислят, че качването на PDF е еднократно действие. Често не е така. След като дълъг документ стане част от състоянието на разговора, моделът може да плаща за този контекст отново и отново в следващите ходове, особено когато потребителите искат уточнения, обобщения или проверки по страници.
Това бързо става скъпо при PDF файлове, защото обемът не е малък. Marktechpost отбелязва, че стандартната обработка в Claude може да включва изображения на страници плюс извлечен текст, а само текстът може да е между 1,500 и 3,000 токена на страница. Дори с функции като prompt caching, документът все пак преминава в инфраструктурата на доставчика. За организации, които изграждат частни AI решения или оценяват модели за on-premise AI, това разграничение е по-важно от самата сметка за токени.
От практиката на Encorp: При document AI първият архитектурен въпрос не е качеството на модела. Той е къде се случва retrieval, какво пресича границата и как това може да се докаже по-късно. Екипите, които вземат това решение рано, избягват скъпи преработки, когато сигурността поиска контрол на достъпа, auditability и поддръжка. Полезен ориентир за внедряване е AI Compliance Monitoring Tools.
Как локалният хибриден RAG държи файла на вашата машина
Моделът на внедряване тук е ясен и стабилен. Token Saver търси локално, след което изпраща към Claude само тесен набор от отговори. Това е правилният подход, когато пълният корпус е голям, а въпросът на потребителя е малък.
Според източника retrieval стекът комбинира търсене по ключови думи чрез SQLite FTS5 с тежест 0.4 и семантично търсене чрез локалния all-MiniLM-L6-v2 embedding model с тежест 0.6. Този тип архитектура за AI интеграция е практичен, защото точното търсене по термини улавя цитати, наименования на закони и продуктови кодове, а embedding моделът намира перифрази.
Харесвам и един детайл, който често липсва в демо среда: системата прилага gate. Ако даден пасаж не споделя точни ключови думи, той трябва да премине праг на семантична близост от 0.25. Това не е гаранция срещу грешки, но е конкретен начин да се намали retrieval с ниска увереност, преди LLM да започне да отговаря. За сигурно AI внедряване това е по-силен аргумент от твърдението, че моделът сам ще се справи.
Какво прави осемстепенният pipeline преди Claude да отговори
Описанието на Marktechpost дава достатъчно детайли, за да се провери потокът. Преди Claude да види каквото и да е, Token Saver извлича текст с pypdfium2 с резервен механизъм, разделя пасажите на части от приблизително 180 думи с припокриване от 40 думи, оценява ги чрез хибриден retrieval, филтрира слабите съвпадения, премахва почти идентични пасажи, свива ги само до релевантните изречения, ограничава payload-а до 8,000 символа и подава резултата с метаданни за страниците.
Този pipeline е важен, защото всеки етап има различна роля:
- извличането намалява нуждата от ръчна подготовка
- chunking запазва локалния контекст, без да влачи цели страници
- gating и deduplication ограничават повтарящия се шум
- trimming и budgeting поставят твърд таван на изходящия контекст
- page envelopes правят проверката възможна
На практика лимитът от 8,000 символа е един от най-важните контроли. Виждал съм как вътрешни document AI асистенти се провалят не защото retrieval е слаб, а защото никой не е поставил бюджет за това какво може да бъде подадено надолу по веригата. Когато това липсва, разходите отново започват да растат, а качеството на отговорите става по-нестабилно.
Колко големи са спестяванията при реални документи?
Числата от тестовете в изходната статия са убедителни като посока, дори и с изричното уточнение, че tiktoken и cl100k_base са използвани като заместител. При 33-страничен FDA drug label токените за целия документ са 23,959 срещу 1,021 върнати токена, или 95.7% спестяване. При 88-страничния GDPR text разликата е 70,260 срещу 996, или 98.6%. При 233-страничното решение по SFFA v. Harvard статията посочва 133,349 срещу 740, или 99.4%.
Истинската новина е в модела: по-големите документи носят по-големи спестявания, защото retrieval не расте линейно с общия брой страници. Ако отговорът е в два абзаца, изходящият контекст може да остане малък независимо дали източникът е 30 или 300 страници. Това е полезно за правни екипи, финансови организации и изследователски звена, където един файл често води до десетки последващи въпроси.
Все пак има компромис. Качеството на локалния retrieval зависи от качеството на извличане, избора на chunking и дисциплината при именуването на файловете. Ако изходният PDF е лошо сканиран или разрешената папка е хаотична, резултатите пак може да са слаби.
Какви контроли за поверителност правят Token Saver подходящ за enterprise среда?
Тук релийзът става по-интересен от стандартна история за оптимизация на токени. Източникът описва три практични контроли: zero uploads, allowlisting на папки и комуникация само през stdio без отворени мрежови портове.
За сигурност на AI в enterprise среда това са смислени решения. Allowlisting-ът на папки стеснява какво инструментът може да достъпва. Комуникацията само през stdio намалява attack surface спрямо услуги, които отварят локални портове. А това, че файлът остава локален, дава бърз отговор на един базов въпрос в процеса по одобрение: къде отиде документът?
Все пак бих разглеждал това като компонент за внедряване, а не като пълна рамка за контрол. Екипите трябва да тестват endpoint hardening, rollout на разширението, управление на обновяванията, ownership на поддръжката и политики за логване преди по-широко внедряване. Това е особено важно в регулирани функции, където услугите за AI внедряване често се провалят не на демото, а в операциите.
Какво да направят екипите преди да приемат локално MCP разширение
Ако трябваше да пилотирам това още следващата седмица, бих започнал с един тесен клас документи: съдебни решения, board packets, policy manuals или технически стандарти. След това в първата седмица бих измерил четири неща: обем на върнатите токени, дял на проверимите отговори, средно време за въпрос и колко често потребителите е трябвало да повторят името на файла или самия въпрос.
Екипите, които най-вероятно ще видят полза първи, са тези, които задават многократни въпроси към дълги и чувствителни PDF файлове. Това включва правни анализатори, които преглеждат решения, финансови екипи, които четат годишни отчети, и изследователски групи, които работят с статии и стандарти. Следващата важна тема за наблюдение е дали локални MCP разширения като това ще останат лесни за поддръжка при растящо използване и дали desktop AI клиентите ще предложат по-добри административни контроли за разрешени инструменти, папки и telemetry.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation