osFoundry / Platform
Этапы пайплайна
Определяйте и версионируйте каждый этап вашего ИИ-пайплайна — извлечение, реранкинг, генерацию, постобработку.
Что это
Этапы конвейера — это часть osFoundry Studio, где вы разбиваете AI-рабочий процесс на именованные упорядоченные шаги вместо одного непрозрачного промпта. Типичный конвейер с расширением поиском выполняется как поиск → реранк → генерация → постобработка, и здесь каждый из этих шагов становится отдельным этапом, который можно настраивать, проверять и менять сам по себе. Поиск извлекает контекст-кандидаты из ваших знаний и данных; реранк сужает их до того, что действительно важно; генерация вызывает модель; постобработка очищает, проверяет или переформатирует вывод, прежде чем он покинет конвейер. Поскольку шаги явные, вы точно видите, откуда взялся ответ и какой этап исправлять, когда он неверен.
Внутри osFoundry каждый этап определяется в Studio и выполняется через тот же слой моделей BYOK, что и остальная часть рабочего пространства, поэтому модель вы выбираете для каждого этапа: небольшую локальную модель для реранка, облачную для генерации, что подходит, и платите напрямую своему провайдеру без наценки перепродавца. Этапы версионируются: когда вы меняете промпт, модель или параметры этапа, прежнее определение сохраняется, так что можно сравнивать версии, откатить ухудшение и знать, какая конфигурация дала тот или иной результат. Как локально-ориентированное настольное рабочее пространство, оно позволяет определениям конвейера и данным, которых они касаются, оставаться на вашем устройстве, а не проходить через размещённый сервис.
Это важно, потому что большинство проблем качества AI — это проблемы этапа. Когда поиск возвращает не те документы, никакая подстройка промпта на шаге генерации этого не исправит. Разделение и версионирование этапов превращают расплывчатое «AI ошибается» в конкретный проверяемый вопрос об одном шаге и позволяют улучшать конвейер так же, как любую другую инженерную систему: по одному изменению за раз, с историей, которой можно доверять.
Ключевые возможности
- Определяйте AI-конвейер как упорядоченные именованные этапы (поиск, реранк, генерация, постобработка) вместо одного монолитного промпта
- Версионируйте каждый этап независимо, чтобы сравнивать конфигурации, откатывать ухудшение и видеть, какое определение дало результат
- Выбирайте модель для каждого этапа со своими API-ключами (локальную, облачную или самостоятельно размещённую) и платите провайдерам напрямую без наценки
- Локализуйте проблему качества до одного шага: понимайте, в чём дело — в поиске, реранке, генерации или постобработке
- Держите определения конвейера и их данные локально на вашем компьютере, а не маршрутизируйте их через размещённый сервис
Сценарии использования
- Разработчик RAG: отделяет поиск и реранк от генерации, чтобы неверный ответ можно было проследить до плохого поиска, а не списывать на промпт
- ML-инженер: версионирует каждый этап при настройке, сравнивая новый реранкер или модель генерации с прежним определением перед тем, как зафиксировать его
- Команда, заботящаяся о приватности: выполняет поиск по локальным знаниям и держит всё определение конвейера на устройстве, вызывая облачные модели только на этапе генерации
Часто задаваемые вопросы
Какие этапы есть в AI-конвейере osFoundry?
Распространённая схема — поиск → реранк → генерация → постобработка: извлечь контекст-кандидаты, сузить до самого релевантного, вызвать модель, затем проверить или переформатировать вывод. Вы определяете нужные вашему процессу этапы и задаёте порядок; каждый настраивается сам по себе.
Могу ли я использовать разную модель на каждом этапе?
Да. osFoundry работает по принципу «свой ключ», поэтому каждый этап может вызывать другую модель: локальную для реранка, облачную для генерации, самостоятельно размещённую где-то ещё, используя ваши собственные API-ключи без наценки перепродавца.
Что на деле даёт версионирование этапа?
Когда вы меняете промпт, модель или параметры этапа, прежнее определение сохраняется. Вы можете сравнивать версии, откатиться, если изменение ухудшило результаты, и связать конкретный вывод с точной конфигурацией этапа, которая его породила.