Skip to main content
LLMembeddingsevaluation

PEEK: як перевірити знання LLM без зайвих прогонів

PEEK — це не новий трюк для промптів, а спосіб оцінити, що насправді знає LLM, через ембединги та лінійний probe. Для бізнесу це важливо, бо така перевірка дешевша за звичайні прогони та допомагає точніше планувати AI integration перед релізом, виявляючи прогалини у знаннях.

Технічний контекст

Я одразу зупинився на формулюванні про «стислу передачу знань у промпті». PEEK про інше: це не prompt-хак і не спосіб компактно запакувати знання в системний промпт для AI automation. Це проксі-метод, який оцінює, чи знає модель факт, не ганяючи саму LLM тисячами запитань.

Схема у них проста і тому цікава. Я беру факт, кодую його embedding-моделлю, потім поверх ембедингу навчається лінійна голова, яка передбачає ймовірність того, що цільова LLM цей факт «знає». Тобто замість дорогих inference-прогонів я отримую наближення knowledge map моделі.

У статті заявляють до 90% AUC та до 86% accuracy, а серед ембедерів найкраще показав себе Linq, за ним NVE2. Для мене тут важливіша не сама цифра, а те, що сигнал загалом достатньо стійкий: отже, частину знань моделі можна витягнути через зовнішній embedding-простір, без постійного допиту самої LLM.

І ось тут стає зрозуміло, чому ідея чіпляє інженерів. Коли я розробляю архітектуру AI-рішень, мені потрібно розуміти не тільки, чи «модель загалом розумна», а де в неї є конкретні factual gaps. PEEK якраз допомагає швидко просіяти великий масив фактів і зрозуміти, що краще закривати retrieval-шаром, а що вже закладено в самій моделі.

Вплив на бізнес та автоматизацію

Практичний ефект я бачу в трьох сферах. Перше: дешевша pre-deployment перевірка. Можна заздалегідь зрозуміти, де агент почне фантазувати, і не платити за нескінченні тестові прогони через API.

Друге: це корисно для вибору архітектури. Якщо PEEK показує провали за доменними фактами, я не сперечаюся з моделлю, а відразу додаю RAG, валідацію або вузький knowledge layer. Так AI implementation стає не «поставили LLM і молимося», а нормальною інженерною системою.

Третє: виграють команди, які будують агентів під конкретну предметну область. Програють ті, хто намагається лікувати factual gaps лише промптами. Тут це не спрацює.

Я б ще окремо додав: PEEK не замінює evals на реальних задачах. Але як ранній фільтр це дуже міцний інструмент. Ми в Nahornyi AI Lab якраз такі штуки й вбудовуємо в клієнтські пайплайни, коли потрібно не просто підключити модель, а створити AI solution з передбачуваною якістю. Якщо у вас LLM вже працює в процесі і ви не розумієте, де вона знає предметну область, а де впевнено вигадує, давайте розкладемо це по шарах і побудуємо робочу перевірку без зайвих витрат.

Пов'язана частина цієї дискусії — як ми керуємо та надаємо контекст ШІ у практичних застосунках. Раніше ми розглядали, як UX-патерн карти коду дозволяє точно впроваджувати контекст для ШІ та прискорює навігацію, що може значно покращити розуміння LLM і зменшити потребу обходити явні обмеження контексту.

Поділитися статтею