Одна история разработки своего Reasoning - Эпизод III
- Эпизод I
- Эпизод II
Шаг 20. Поспал и посмотрел на неработающий запрос свежим взглядом. И тут я понял, что больше сходу не вижу в формулировке вопроса того очевидного плана для ответа на него, который я видел только вчера (я же не эксперт, вот и выгрузился контекст во время сна). Значит и система его не увидит.
Я давал системе вопрос от эксперта и просил построить план ответа на вопрос. Это как если бы я позвал человека с улицы и попросил сделать то же самое: “посмотри на вопрос и выпиши различные условия или топики, которые надо изучить отдельно для ответа на этот вопрос”.
Система просто не видит всего этого богатства нюансов, которые бы позволили спланировать более тщательно. Ну упомянуты три синонима через запятую, что такого? Почему я от нее требую запускать параллельные поиски именно по этим сущностям в вопросе, а не по остальным? Там есть и не только синонимы.
Но, тем не менее, нюансы есть! В вопросе эксперт явно называл резолюцию, в разрезе которой надо было анализировать документы. И если смотреть с ее перспективы, то это не три синонима, а три разных события, которые влекут за собой разные последствия. Соответственно, и прописаны они должны быть в договоре отдельно. А, значит, и искать надо их независимо друг от друга.
Шаг 21. Я смог получить работающий блок планирования ответа!
Надо обязательно перед запуском планировщика определять перспективу, с которой мы смотрим на вопрос (она описана в регуляторном документе). Грузим релевантную онтологию в схему, докидываем пару ключевых слов для общего настроя и, вуаля, внезапно планировщик начинает видеть нужные нам нюансы в терминах. Во всяком случае теперь ответ всегда один и тот же, сколько раз не вызывай. С этим можно работать. Это поддается тестированию и аудиту.
Шаг 22. Правда теперь возникают другие грабли. Спланировали анализ мы в одной перспективе, а документы у нас проиндексированы с другой перспективе, и они не стыкуются. Получается, что нельзя вычитать документ LLM-кой один раз, а потом использовать получившуюся карту знаний для ответа на любые вопросы.
Эх, заново индексировать. Ладно хоть LLM не просят доплату за нудность работы.
Но зато это объясняет, почему система глупила при ответах на некоторые вопросы. Вопросы требовали понимания таких нюансов, про которые система не знала на момент индексации, вот она их и пропускала.
Конец.
Не в смысле, что конец истории, которая началась три месяца назад. На этом месте шаги не заканчиваются, как и грабли.
Просто теперь мы дошли до сегодняшнего дня. Большинство грабель уже понятны и знакомы. Не “ничего не работает”, а что-то вроде “ага, не хватает вот в этой онтологии точности при извлечении релевантных сегментов”. Работы там выше крыши и она только начинается.
Смотря на все эти телодвижения ретроспективно понятны две вещи.
(1) Любые агенты "из коробки" никогда не будут работать так хорошо, как обещают. В их мышлении нет того скелета, который обращает внимание на нюансы предметной области. Прошивать нюансы в reasoning pipelines - требует усилий и времени. Но если это сделать хорошо один раз, то потом система будет работать если не идеально, то с претензией на стабильность и возможностью улучшаться. А там, глядишь, и сойдется юнит-экономика на всю автоматизацию.
(2) Неземной респект командам OpenAI, которые смогли сделать reasoning движок, который само-адаптируется под неизвестные заранее вопросы. Причем не просто адаптируется, но и очень часто умудряется находить хорошие ответы на очень сложные вопросы.
Возможно когда-нибудь, можно будет брать последнюю версию LLM, и она сама сможет правильно индексировать все документы в какой-то отрасли, планировать исследования и без проблем приходить к ответу. Ну и еще сможет качественно учиться на ошибках.
Но я сомневаюсь, что это будет в ближайшие годы - слишком много важных нюансов. А что вы скажете?
Дальше - Reasoning кирпичик для Stargate
Ваш, @llm_under_hood 🤗
PS: Схема архитектуры на этот момент - в комментариях.
>>Click here to continue<<