Към съдържанието

AI от ново поколение

Custom AI системи, които издържат и след демото

Изграждаме системи за търсене в документи, извличане на данни и агенти върху API на водещите модели — заедно с eval харнеса, guardrails и tracing-а, които решават дали всичко това ще оцелее при среща с реалните ви документи. Пускаме агент само там, където workflow доказано не се справя, защото multi-agent оркестрация изразходва около 15 пъти повече токени от chat повикване, а един агент — около 4 пъти (измерените стойности на Anthropic). Спрямо workflow с търсене разликата е по-малка, но е реална и идва с режими на отказ, каквито workflow няма.

30 минути с инженера, който би свършил работата — не с търговец. Без ангажимент, а каквото стигнем на разговора, остава при вас.

Инженери преглеждат резултатите от тестовете, преди retrieval системата да тръгне в продукция

Какво измерваме

5.7% → 1.9%
Пропуски при търсене в top-20: наивни embeddings срещу contextual embeddings, BM25 и rerankerПубликуваният benchmark на Anthropic за contextual retrieval, измерен като 1 − recall@20. Не е резултат на клиент на Palamed — това е целта, срещу която проектираме и която после измерваме върху вашия корпус.
под 25%
Успеваемост на агенти при pass^8 в tau-bench retail, срещу над 50% при едно изпълнение — GPT-4o, 2024 г.Публикувани данни от tau-bench за GPT-4o. Днешните водещи модели се представят осезаемо по-добре, но абсолютното число значи по-малко от формата: pass^8 винаги е далеч под pass^1 и тази разлика не изчезва с по-добър модел. В production агентите се чупят от липса на повторяемост, а не от липса на способност — затова докладваме pass^k върху вашите задачи, не еднократно демо число.
0.1x
Цена на входа при кеширан prompt префикс, срещу 1.25x за запис на петминутен кешПубликуваните цени на Anthropic за кеширане. Инвалидацията каскадира tools → system → messages, така че един timestamp в system prompt-а тихо занулява hit rate-а; следим cache_read_input_tokens от първата седмица.
95%
Корпоративни GenAI пилоти без измеримо отражение върху финансовия резултатMIT Project NANDA, „The GenAI Divide: State of AI in Business 2025“ — 52 структурирани интервюта, 153 анкетирани ръководители, 300+ публични внедрявания. Реалната възвръщаемост се концентрира в елиминиране на back-office процеси, докато над половината бюджети отиват към маркетинг и продажби. Не е резултат на Palamed.

Какво изграждаме

Двама анализатори преглеждат таблица с данни на монитор

Търсене, което издържа реалния ви документен масив

Повечето случаи, описани като „AI-ът си измисли“, всъщност са пропуснато извличане. Парсваме документите layout-aware с Docling или Unstructured, маркираме всеки chunk с идентификатор, ревизия и дата на влизане в сила, след което пускаме contextual retrieval: модел написва 50–100 токена контекст пред всеки chunk преди embedding. Това е еднократен контекстуализиращ пас, чиято цена зависи от входната тарифа на малкия модел — Anthropic измери $1.02 на милион токена документ при цените на Haiku от 2024 г.; преизчисляваме я спрямо текущите тарифи и реалния обем на вашия корпус, преди да я одобрите, защото при голям масив това е реално перо. Търсенето е хибридно — BM25 за партидни номера, вектори за перифраза — с reciprocal rank fusion и cross-encoder reranker. Rerank-ът е латентността, която плащате за точност, затова му залагаме бюджет, вместо да го откриваме после: търсене 50–200 ms, преподреждане 80–300 ms върху топ ~100 за избор на 10–20 и време до първи токен под 700 ms от край до край, защото над около 1,5 s потребителят приема, че системата е счупена.

  • Означен набор от въпроси върху вашия корпус, с измерени recall@20 и context precision преди и след работата — само recall е капан, защото по-широко top-k го вдига, а едновременно с това подава на модела разсейващи пасажи, които увеличават измислиците
  • Филтри по ревизия и дата на действие във filterable HNSW индекс, така че отменените SOP-и са недостъпни, а не просто по-ниско класирани
  • Отговори с проследими цитати към конкретен chunk и изричен отказ, когато нито един chunk не ги подкрепя
Инженер нанася бележки върху схема за системна интеграция

Извличане от документи с детерминистични валидатори

Извличането работи срещу строга JSON Schema с additionalProperties false, така че схемата е договорът с вашия ERP, а не пожелание. Детерминистичните валидатори се изпълняват след модела, никога вместо него: IBAN mod-97, контролна сума на ДДС номер, съгласуване на редовете със сумата, съпоставяне на доставчика с master data. Увереността идва от съгласието между валидаторите, а не от самооценката на модела, която не е надеждна.

  • JSON Schema, съгласувана с този, който отговаря за полетата в ERP, на която downstream системите могат да разчитат
  • Набор от валидатори, който решава кое минава автоматично и кое стига до човек
  • Опашка за преглед с осветена зона от изходната страница, за да потвърждава човекът, вместо да въвежда наново — а всяка корекция влиза в regression набора
Работна сесия около разпечатани диаграми на процеси

Агенти само там, докъдето workflow не стига

По подразбиране правим workflow и караме агента да се обоснове. Там, където последователността от стъпки наистина не може да се предопредели, инструментите остават тесни и идемпотентни, а разделянето на правата се налага чрез това кой MCP сървър ги излага, защото OAuth моделът на MCP авторизира сървъра, а не отделния инструмент — с валидиране на audience на токените и без препращане на вашия клиентски токен към следваща услуга. Записите минават през човек в първата версия, а цикълът върви върху durable execution, така че рестарт продължава от checkpoint, вместо да повтаря странични ефекти. Прекратяването е изрично — бюджет за стъпки, бюджет за токени, детектор за липса на напредък.

  • Опис на инструментите, всеки от които е тесен, документиран, идемпотентен и достъпен само през MCP сървъра, отговарящ на неговата граница на доверие
  • Изрични условия за прекратяване, защото MAST отдава 17.1% от провалите на multi-agent системи на повторение на стъпки и 9.8% на непознаване на условието за спиране
  • OpenTelemetry GenAI spans при всяко изпълнение, за да е възстановим всеки провал, а не преразказан
Инженер преглежда мониторинг табло вечер

Eval харнесът, който остава при вас

Резултатът не е prompt, а regression gate. Прочитаме 100+ ваши реални неуспешни trace-а и кодираме режимите на отказ ръчно — кодирането се насища около 30 trace-а, когато вече не се появява нищо ново — след което ги превръщаме в golden set от 150 до 400 случая с двоична оценка, написан заедно с ваш експерт. Съдниците валидираме по true-positive и true-negative rate спрямо тези етикети, защото самото съвпадение подвежда при небалансирани класове.

  • Golden set във вашето repository, с поименен собственик от ваша страна
  • Евтини детерминистични проверки при всеки commit: формат, забранени термини, наличие на цитат, латентност
  • CI gate, оразмерен така, че наистина да може да сработи: прагът за блокиране идва от измерената дисперсия на набора, а не от кръгло число, а когато golden set-ът е твърде малък, за да отчете малка разлика, го казваме и блокираме по детерминистичните проверки и по подмножества за отделните режими на отказ, вместо по обща оценка
Инженер обяснява документацията на клиент на лаптоп

Guardrails, единична цена и позицията по AI Act

Prompt injection е архитектурен проблем, не филтърен: адаптивни атаки пробиват повечето от дванадесет публикувани защити в над 90% от случаите, а човешки red team от 500 души пробива и дванадесетте. Затова агентът, който чете непроверени документи, не е агентът с права за запис в ERP — Rule of Two, наложено в топологията, а не обещано в политика. Цената се управлява по същия начин: по маршрут и по решена задача.

  • Резултати от адаптивен red team с promptfoo, съотнесени към OWASP Top 10 for LLM Applications 2025
  • Фиксирани точни ID-та на моделите вместо алиаси, fallback вериги на ниво gateway и champion-challenger оценка преди всяка смяна на версия
  • Класификация спрямо Анекс III с аргументацията към нея и Article 50 разкриване, вградено в шаблоните, а не описано в PDF политика

Системи, с които работим

Интегрираме се с това, което вече ползвате. Ако не виждате ваша платформа по-долу, кажете ни — подходът обикновено се пренася.

Каквото реално сме ползвали: модели и търсене

  • Anthropic Claude API и OpenAI structured outputs (strict JSON Schema)
  • PostgreSQL с pgvector
  • хибридно търсене с BM25 и вектори
  • слети с reciprocal rank fusion
  • Cohere Rerank за cross-encoder преподреждане, включително на български
  • Docling и Unstructured.io за layout-aware обработка на документи

Каквото реално сме ползвали: оценка, tracing и guardrails

  • Ragas и promptfoo, включително приставките за адаптивен red team
  • Langfuse или Arize Phoenix, self-hosted, когато го изисква резидентността на данните
  • OpenTelemetry GenAI semantic conventions
  • Pydantic и Zod за валидация на схеми и constrained decoding
  • OWASP Top 10 for LLM Applications 2025, NIST AI RMF 1.0 и AI 600-1, ISO/IEC 42001:2023 като рамките, към които съотнасяме намереното

Какво бихме избрали оттук нататък и докъде стига този списък

  • Model Context Protocol (JSON-RPC 2.0), с разделяне на правата чрез отделен сървър за всяка граница на довериеMCP авторизира сървър, не инструмент
  • Temporal за durable execution, когато агентният цикъл трябва да преживее спиране на процеса
  • Amazon Bedrock, Google Vertex AI или Azure AI Foundry, когато поръчката изисква endpoint в европейски регион
  • OVHcloud, Scaleway или Hetzner зад vLLM, когато отворените тегла трябва да останат в ЕС
  • Ако платформа, която ползвате, липсва тук, това значи, че не сме пускали нищо върху нея; попитайте и ще ви кажем дали подходът се пренася, или ви трябва някой друг

Как протича работата

  1. 01

    Преглед на trace-овете

    1–2 седмици, фиксирана цена

    Какво остава при вас

    Преброена таксономия на отказите, кодирана от 100+ ваши реални trace-а или сгрешени документи, плюс базови стойности за recall@20 и groundedness върху означен набор от въпроси, написан с ваш експерт.

    Решението, което етапът налага

    Дали проблемът ви е в извличането, в генерирането, в спецификацията или в самия корпус. Четирите се поправят по напълно различен начин и само едното е prompt.

    Кога спираме

    Ако таксономията покаже, че водещият отказ е липсващо, противоречиво или отменено съдържание, ви предаваме таксономията и спираме — и няма да предлагаме строеж на негова основа. Никаква архитектура на търсенето не възстановява документ, който никога не е бил написан.

  2. 02

    Тънък вертикален срез

    3–5 седмици

    Какво остава при вас

    Един завършен път в production форма — обработка, хибридно търсене, reranking, генериране, цитати, отказ — зад feature flag, с вече работещи golden set и CI gate срещу него.

    Решението, което етапът налага

    Дали измерените числа минават прага, който сте задали преди началото: recall@20, context precision, groundedness, дял на отказите, p95 латентност и цена за решена задача.

    Кога спираме

    Ако groundedness остане под 0.85 върху golden set-а след два цикъла на настройка, спираме, предаваме всичко изградено и плащате за отработените седмици и нищо повече — без фаза на втвърдяване, без месечен ангажимент и без ние да предлагаме такъв. Под 0.85 системата съчинява видимо, всяка седмица, и никаква работа по prompt-а не го скрива.

  3. 03

    Втвърдяване

    4–8 седмици

    Какво остава при вас

    Записана архитектура на guardrails спрямо Rule of Two, резултати от адаптивен red team, съотнесени към OWASP LLM Top 10 2025, фиксирани ID-та на модели с fallback вериги и класификация по EU AI Act с аргументация.

    Решението, което етапът налага

    Какво системата има право да прави без човек в цикъла и какво не бива да прави изобщо.

    Кога спираме

    Ако случаят се класифицира като високорисков по Анекс III, а вие не искате свързаните с това задължения на доставчик и внедрител, преработваме така, че решението да остава при човека, или спираме.

  4. 04

    Предаване и поддръжка

    2 седмици, след това месечен ангажимент

    Какво остава при вас

    Runbook, eval пакетът във вашето repository, dashboards върху ваша инстанция на Langfuse или Phoenix и записан бюджет за преиндексиране и миграция на embeddings — в евро и в часове.

    Решението, което етапът налага

    Кой отговаря за golden set-а, на какво блокира merge gate-ът и коя метрика задейства rollback.

    Кога спираме

    Ако от ваша страна няма поименно посочен собственик на golden set-а, не започваме фазата по поддръжка. Неподдържан eval пакет се изражда във фалшива зелена лампа за едно тримесечие.

Демото доказва, че моделът може. Продукцията доказва, че го прави всеки ден.

Какво вероятно си мислите

Пробвахме пилот, той си измисляше и спряхме.

Това обикновено е отказ на извличането, диагностициран като отказ на генерирането. Каноничната RAG таксономия разделя „отговорът изобщо не беше намерен“ (точки на отказ 1–3) от „моделът го имаше и сгреши“ (4–7), а поправките нямат нищо общо: chunking, метаданни и reranking срещу prompt и конструиране на контекста. Анализ на trace-овете от пилота решава въпроса за дни. Понякога честният отговор е, че пилотът е бил насочен към въпрос, на който документите ви не могат да отговорят — и това също ще го кажем.

Това не е ли просто обвивка около чуждо API?

Извикването на API е стоката и с право го оценявате така. Дали нещото ще работи се решава от pipeline-а за търсене, eval харнеса, топологията на guardrails, наблюдаемостта и обработката на отказите. Конкретно: MAST отдава 41.8% от провалите на multi-agent системи на проблеми в спецификацията, а tau-bench показа GPT-4o над 50% при едно изпълнение и под 25% при pass^8 през 2024 г. — днешните модели се справят по-добре, но разликата между pass^1 и pass^k остава. Нищо в API-то не поправя нито едното число. Точно тази разлика е работата.

Откъде да знаем, че няма да се влоши, след като си тръгнете?

Не знаете, ако няма gate. Затова резултатът е golden set от 150–400 означени случая, написан с ваш експерт, детерминистични проверки при всеки commit, съдници с валидирани 0.85+ true-positive и true-negative rate и CI проверка, чийто праг за блокиране идва от измерената дисперсия на набора, а не от кръгло число — при 200 случая една точка са два случая, което е в рамките на шума на съдника, затова, когато наборът не може да отчете малка разлика, го казваме и блокираме по детерминистичните проверки и по подмножества за отделните режими на отказ. Честната уговорка: golden set без поименен собственик изгнива. Ако не можете да посочите този човек, купете одита, не строежа.

Защо да не изчакаме SAP или Microsoft да го пуснат в пакета?

За хоризонталните случаи често наистина трябва да изчакате и ще ви го кажем, преди да похарчите каквото и да е. Пакетните продукти се справят добре с общ чат по документи и обобщения на срещи, а проучването на MIT установи, че купените инструменти и тези, правени с външен партньор, успяват в около 67% от случаите, срещу приблизително една трета от това при разработки, опитани изцяло вътрешно — довод да купите хоризонталния слой и да не се захващате сами с конкретния работен поток. Това, което те никога няма да моделират, е вашата номенклатура, правилата ви за ревизии, праговете ви за одобрение и логиката на изключенията в ERP-а. Купете хоризонталния слой; постройте само това.

Какво става, когато някой скрие инструкции в документ, който обработваме?

Филтрирането не е защита. Адаптивни атаки пробиват повечето от дванадесет публикувани защити срещу prompt injection в над 90% от случаите, а човешки red team от 500 души пробива и дванадесетте. Затова се решава архитектурно, чрез Rule of Two: нито един компонент не държи едновременно непроверен вход, достъп до чувствителни данни и изходяща комуникация. На практика агентът, който чете PDF-и от доставчици, не е агентът с права за запис в ERP-а, а всичко, което едновременно чете непроверено съдържание и може да действа, минава през човек. Бъдете наясно какво ви струва това: напълно автономната версия — чете PDF-а, записва в ERP-а, без човек — е версията, която няма да построим, защото няма известна защита, която да я направи безопасна. Вместо нея получавате два компонента и стъпка за одобрение. По-бавно е и се представя по-зле на демо. Ако бизнес случаят излиза само при пълна автономност, честният отговор е, че бизнес случаят още не излиза.

Кога не сме подходящи за вас

  • Искате един универсален асистент върху всичко, което компанията някога е написала. Такъв проект няма критерий за приемане, няма golden set и няма собственик — и точно такава форма приемат повечето пилоти без измеримо финансово отражение.
  • Случаят е високорисков по Анекс III — подбор на CV-та, разпределяне на задачи, наблюдение на представянето, кредитоспособност — и искате да решава автономно. Ще направим версията, в която решава човек, или няма да я направим.
  • Обемът е под няколкостотин документа, тикета или случая месечно. Под това ниво eval пакетът и текущата издръжка струват повече от ръчната работа, която заместват, и предпочитаме да го кажем на първия разговор, а не на третата фактура.

Въпроси, които ни задават

Как избираме между fine-tuning и RAG?

RAG за знание, което се променя и трябва да се цитира; fine-tuning за формат, тон и латентност при стабилна задача с голям обем. Ефективното дообучаване направи изчислението евтината част още преди години — QLoRA събра модел от 65B параметъра на един GPU с 48GB още през 2023 г., а моделите с отворени тегла оттогава само олекнаха. Разходът е означеният набор от данни и eval пакетът. Две неща се пропускат: обикновено не можете да дообучите челния хостван модел, който ползвате в момента, а дестилирането на изходите му към по-малък модел е лицензен въпрос, преди да е инженерен — затова проверяваме условията, преди да го предложим. На практика редът е първо RAG, а после дестилиране на утвърдения масов път към по-малък модел, щом корекциите се натрупат в обучаващ набор.

Наистина ли се справя с български, или само на демото?

Пускаме системи на български: дигиталният речник на beron.mon.bg, изграден за Министерството на образованието и науката и използван в българските училища — отворете го и го проверете. Това е търсене в български изходен текст, публично, а не демо. То е и единствената ни публична референция за езикова система на български; останалото ни е европейски маркетплейс за автомобили с над 300 000 обяви, NLP модул, който класифицира и подготвя отговори на търговски запитвания по имейл и в Instagram — около 85% по-малко ръчно писане по повтарящите се въпроси по измерване на самия клиент, като всеки отговор се одобрява от човек, преди да тръгне — и автоматизация на имейл маркетинга, която намали времето за комуникация на козметична марка с 60%. Четири проекта — това е пълният списък. Оттам нататък се измерва, а не се предполага. Модели, бенчмаркнати основно на английски, обикновено са с 5–15 точки по-слаби на български, а една обща оценка го скрива напълно. Поддържаме отделен български golden set, избираме embedding и reranking модели по измерено представяне на кирилица, а не по маркетинг, и налагаме терминологията с валидиран глосар вместо с инструкция в prompt-а.

Колко ще струва това при нашите обеми?

Измерва се на решена задача, а не на токен, защото евтина заявка, която иска три повторения, не е евтина. Типичните стойности са 0,01–0,05 € за кеширан отговор с търсене и 0,20–1,50 € за многостъпков агентен случай. Лостовете са кеширане на prompt-а при 0.1x на четене, Batch API при 50% за всичко, което не е чувствително към латентност, и маршрутизиране на класификацията и извличането към малък модел. Мерим числото от първата седмица.

Могат ли данните ни да останат в ЕС и ще се използват ли за обучение?

И двете са решими и мястото им е в договора, а не в уверение. Endpoints в европейски региони на Bedrock, Vertex или Azure със zero-data-retention там, където доставчикът го предлага, условия по чл. 28 GDPR, или изцяло self-hosted отворени тегла на OVHcloud, Scaleway или Hetzner зад vLLM. Self-hosting е реална опция с реална икономика: continuous batching се изплаща само при устойчива заетост, затова го моделираме срещу вашите реални заявки в секунда.

Трябват ли ни собствени ML инженери, за да го поддържаме?

Не, но ви трябва един поименен собственик на golden set-а. Repository-то е обикновен Python или TypeScript плюс CI job, а таблата са Langfuse или Phoenix. Наистина специфичното ML умение е да се четат trace-ове и да се етикетират честно, което експерт по предметната област прави по-добре от инженер. Обучаваме този човек по време на предаването и оставяме ръководството за етикетиране.

Колко бързо виждаме нещо работещо в production?

Тънък вертикален срез зад feature flag обикновено излиза 3–5 седмици след прегледа на trace-овете и е истински: вашите документи, вашето търсене, вашите цитати, вашият golden set. Пълното разгръщане зависи почти изцяло от състоянието на изходния материал. Ако документите ви нямат метаданни за ревизия и няма един източник на истина, първите седмици са обработка и управление на съдържанието, а не моделиране — и ще ви го кажем, преди да подпишете.

Топли светлинни ленти върху тъмен фон

Какво е нужно, за да се доверим на това в production?

Изпратете ни 100 trace-а, които пилотът ви е сгрешил, или 100 документа, които е разчел погрешно. Прочитаме ги, кодираме режимите на отказ и ви казваме дали проблемът е в извличането, в спецификацията или в самия корпус. При взаимно споразумение за конфиденциалност и договор за обработване по чл. 28 GDPR, подписани, преди да е изпратено каквото и да е; обработката е в ЕС, а данните се изтриват при поискване или по подразбиране в края на прегледа. Ако предпочитате данните изобщо да не мърдат, правим прегледа във вашата среда.

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