Стэнфордский LLM-as-a-Verifier обещает +9% точности и экономию ×11 — красиво на бенчмарке, но в проде самопроверка упирается в зацикливание модели, её идеалистичную самооценку и цену N вызовов вместо одного. Разобрал три нюанса на опыте продакшена и рассказал, как это решается: лимиты итераций, судья другой архитектуры, факты из графа знаний. Читать: https://presniakov.ru/blog/samoproverka-ii-agentov
напишите коммент
2 коммента
можете перейти, но сначала проверьте ссылку и будьте аккуратны: не вводите по ссылке пароли, номера телефонов и банковских карт, и другие личные данные
https://
уверены, что хотите выйти?
придется авторизоваться заново, а заполненные данные будут удалены
пост закреплён — пока закрепить можно только один пост
что-то пошло не так — попробуйте снова чуть попозже
· 21.08
в проде перед llm-судьёй ставлю дешёвый эмбеддинг-скоринг: если косинусная близость ответа к retrieved-контексту выше порога, верификатор вообще не дёргаю. режет api-вызовы на 60–70%, потому что большинство «галлюцинаций» — дрейф от контекста, а не логическая ошибка, и граф знаний тут избыточен когда rag с нормальным chunking'ом закрывает то же самое проще
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 21.08
Так тоже год назад делали, очень много мути выдавал в документации очень много сокращений, поэтому-то точность повысили сначала за счет graphRAG, потом за счет KAG — прослойки, поэтому, есть всё равно не точности, но это решается за счет наращивания прослойки.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён