
Търсене, което издържа реалния ви документен масив
Повечето случаи, описани като „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 не ги подкрепя





