Обновить

От LangChain к LangGraph: детально разбираемся с фреймворками и всей Lang-экосистемой

Время на прочтение13 мин
Количество просмотров7.1K
Всего голосов 15: ↑15 и ↓0+18
Комментарии5

Комментарии 5

LangChain абстрагирует различия между провайдерами и использует нативный запрос, если он поддерживается (OpenAI function calling API или Anthropic tool use), и фолбэк на json-mode или промпт инструкции, если у провайдера такой функциональности нет.

"json-mode" - это structured_ouptut?

Разве это не основной сейчас метод для большинства серьезных моделей (в сравнении с function calling API)?

Тут все сложно! 😀

Верхнеуровнево все так - structured output это более широкое понятие, но json это его самая популярная реализация. Поэтому с натяжкой знак тождественности между ними поставить можно.

Если более технически, то разница вот в чем: нативный "tool calling" (как бы он не назывался у конкретного провайдера) - это более сложное понятие, чем просто json-mode. И там и там мы ожидаем json и задаем его сами - да. Но под капотом происходит вот что: json-mode это отправка фактически простого запроса, который содержит в себе требования к json-схеме и этот запрос обрабатывается именно как простой запрос, то есть модель очень старается попасть в схему, но для нее это простой запрос, такой же как и предыдущие.

А когда мы отсылаем tool-calling запрос, то там все примерно похожее, но модель обрабатывает его иначе - используя свою зафайнтюненную версию именно на json-схемы и понятие инструментов - и потому вероятность успеха гораздо выше.

Под structured_ouptut я имел ввиду передачу модели json schema

В противовес function calling опять-таки

Спасибо за информацию! Сам хотел разобраться со всем этим Lang семейством, а здесь как раз подходящая статья.

Очень крутая и емкая статья без воды, спасибо огромное, прочел внимательно!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации