Skip to content

AI система за предварителен контрол на обществените поръчки — концепция (rule engine + AI слой) #231

Description

@lyubomir-bozhinov

Концепция за обсъждане/решение. Автор: @stefandl95 (експерт по обществени поръчки — опит като контролен орган в АОП и като възложител). Пълният документ („Концепция за интелигентна система за предварителен и междинен контрол на обществените поръчки", PDF) е споделен в Discord; предлага се да влезе и в docs/ след решение по посоката. Това е котвата на темата — конкретните парчета работа са отделни, плоски issue-та, изброени най-долу (кръстосано свързани).

Идея

Интелигентна система за предварителен (и междинен) контрол на обществените поръчки — хибрид Rule Engine + AI слой върху онтология от правила, която подпомага предварителния контрол на АОП. Целта е методическа подкрепа не само за поръчките над европейските прагове (където контролът вече е задължителен), а и за останалите — за да се хващат порочни практики рано, преди/по време на процедурата.

Защо сега. Пролетният доклад на ЕК отчита рекорд: ~41% поръчки само с един оферент и ~27% неуспешни/прекратени процедури. AI + правила върху богатия исторически архив на АОП може да ускори и разшири контрола и да намали порочните поръчки.

Граница спрямо съществуващото (важно)

Това е ПРЕД-контрол (преди/по време на процедурата), различен от ПОСТ-детекцията на аномалии, която вече градим:

Тази идея стъпва на същите данни и евристики, но ги прилага проспективно върху документите на конкретна процедура, а не ретроспективно върху архива.

Ядро на концепцията

Фокус на контрола — трите документа, в които най-често се ограничава конкуренцията: обявление, техническа спецификация, методика за оценка (+ прогнозна стойност и критериите за подбор/възлагане). Структурирани в ~20 контролни обекта с позовавания на конкретни членове от ЗОП/ППЗОП (чл. 63, 70–72, 92–93, 116–117 и др.) и рискова скала нисък → критичен.

Модул 1 — детерминистичен Rule Engine (14 етапа)

Отделен от AI-слоя. Pipeline: зареждане → извличане (OCR/NER/regex) → нормализация (единици, дати, валута, CPV) → картиране към контролните обекти → съпоставяне с полетата на ЦАИС ЕОП (eForms BT-полета) → правила „ако–тогава" → доклад по фиксирана схема Факт → Очакване → Проверка → Извод → Констатация → Препоръка.

Видове проверки за грешки: правна (съответствие с конкретни членове), логическа (консистентност между документи/полета), аритметична (стойности, ДДС, изчисления), крос-проверка (документи ↔ ЦАИС ЕОП), проверка чрез бази (референтни източници + пазарна база с референтни цени — необичайно ниска оферта, чл. 72).

Примерни детерминистични правила (фиксирани прагове): стойност без ДДС в поле с ДДС → висок; срокове в различни документи се разминават с >3 дни → среден; критерий „качество/цена" без методика → критичен; прогнозна стойност ≥ 1 млн. лв. без определено изискване (чл. 61, ал. 7) → висок; числени „очаквания" с толеранси (стойност ±20%, срок ±3 мес., 5–8 оферти ±2) → отклонение = флаг.

Изход: детерминиран етикет съответства / частично / не съответства + риск. Rule engine-ът е съветващ: дава „извод", окончателната „констатация" минава през човек (човешки надзор по AI Act).

Модул 2 — AI слой (недетерминистичен)

NLP/семантичен анализ, знаниеви графи, векторни бази, рисков скоринг, откриване на аномалии и схеми. Стъпва върху структурирания изход на Модул 1.

Рамка по AI Act

Заложена от самото начало: класификация високорисков + задължителен човешки надзор (документиране, логове, прозрачност, обяснимост).

Предложение за надграждане (от автора)

„Свързани лица" / конфликт на интереси да е отделен формализиран контролен обект (проверка срещу Търговския регистър / регистъра на действителните собственици), а не само anomaly detection — сред водещите проблеми по докладите на ЕК. Пряко се връзва с #226 / #224 / #229.

Честни ограничения / рискове (за да не подценяваме обхвата)

  • Правилата са представителни примери, не завършена rule library. Пълната библиотека (Етап 7) е компонент за надграждане, не е приложена в документа — това е най-голямото парче работа.
  • Зависимост от достъп до данни. Крос-проверката иска четене на eForms/BT полета от ЦАИС ЕОП и на самите документи на процедурата — извън това, което sigma чете днес. Достъпът/интеграцията е предпоставка, не даденост.
  • Извличането (OCR/NER) върху PDF/DOCX спецификации е нетривиално и е източник на грешки, който трябва да има собствени тестове и метрики.
  • AI Act високорисков носи реален съответствен товар (оценка на съответствие, документация, надзор) — да се остойности рано.
  • Позициониране. Това е контролен инструмент (за АОП/възложител), не публична прозрачност — да се реши дали е функция на sigma, съседна система, или изследователски коловоз.

За обсъждане (👍 / 👎 + коментар)

  • Контролът централизирано (при АОП) ли да работи, или на ниво възложител?
  • За кои прагове да е задължителен?
  • sigma-функция vs отделна система?

Свързани issue-та

Нови (парчетата, които липсват — плоски issue-та по тази концепция):

Стъпва на съществуващото (за преизползване, не за преправяне):

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionОтворен въпрос за обсъжданеenhancementНова функционалност или предложениеpriority: mediumСреден приоритетstatus: needs-decisionЧака решение от поддръжниците

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions