Официальное описание WeKnora перечисляет пять крупных функциональных направлений — RAG, Agent, MCP, песочницу и автоматическую Wiki-документацию — поэтому стоимость базы знаний WeKora нельзя считать только по числу загруженных файлов. Сначала разделите бюджет на обработку данных, индексацию и хранение, модели для ответов, вызовы инструментов, выполнение в песочнице и эксплуатацию; для небольшой проверки выберите локальный или низкопараллельный запуск, а расширение выполняйте по фактическим запросам, параллельности и частоте обновлений данных. Это подтверждается официальным описанием возможностей WeKnora.
Эта методика предназначена руководителю корпоративной базы знаний, которому нужен объяснимый бюджет RAG и Agent-проекта. Она также подойдёт продуктовым инженерам, оценивающим импорт документов, поиск, вызовы инструментов и автоматическую Wiki, и независимым разработчикам, которым необходимо заранее понять расходы облачного рабочего пространства и постоянной эксплуатации.
Сначала разделите бюджет на шесть независимых контуров
В проекте WeKnora одна пользовательская операция может пройти через несколько подсистем. Документ необходимо разобрать, очистить, разделить на фрагменты, превратить в векторы и записать в индекс. Затем запрос пользователя проходит через поиск, возможное переранжирование и генерацию ответа. Если включён Agent, к этому добавляются рассуждение, инструменты, MCP-серверы, веб-поиск или выполнение кода в песочнице.
Для расчёта используйте следующую модель:
Общий бюджет = обработка данных + индексация и хранение + RAG-модели + Agent и инструменты + песочница + эксплуатация.
Это не означает, что каждый компонент обязательно оплачивается отдельной строкой. Некоторые расходы могут приходиться на одну и ту же виртуальную или физическую машину, а часть сервисов может быть общей для нескольких рабочих процессов. Задача формулы — не вывести вымышленную цену, а не забыть ресурсный контур.
| Контур | Что входит | Главная переменная бюджета |
|---|---|---|
| Обработка данных | Разбор PDF, офисных файлов, изображений, очистка и извлечение структуры | Объём новых и изменённых документов |
| Индексация и хранение | Фрагменты, векторы, метаданные, резервные копии, версии | Размер индекса и срок хранения |
| RAG | Встраивание запроса, поиск, переранжирование, генерация ответа | Число запросов и размер контекста |
| Agent и MCP | Планирование, вызовы API, инструменты, веб-поиск | Число шагов на задачу и доля ошибок |
| Песочница | Изолированное выполнение кода и временные файлы | Время выполнения и параллельность |
| Эксплуатация | Мониторинг, обновления, резервное копирование, доступы и поддержка | Режим работы и требования к доступности |
Нельзя смешивать стоимость модели с инфраструктурой. Даже если генерация ответа обходится недорого, постоянно работающий индекс, резервные копии, сетевой доступ, обработчики документов и контроль доступа всё равно формируют отдельную статью.
Важное ограничение. В этой статье намеренно нет вымышленных цен, фиксированных требований к серверу или обещаний производительности. Конкретные версии, переменные окружения и способ запуска нужно сверять с текущими официальными инструкциями и шаблоном окружения WeKnora.
Как посчитать импорт документов и обслуживание индекса
Первичный импорт и последующая синхронизация — разные рабочие нагрузки. При первом запуске система обрабатывает накопленный архив: извлекает текст, определяет структуру, режет материал на фрагменты, создаёт представления для поиска и формирует индекс. При поэтапном обновлении меняется только часть данных, однако для корректного удаления старых версий нужно хранить идентификаторы документов, метаданные и связь между исходным файлом и индексированными фрагментами.
Оценку удобно вести в трёх сценариях:
- Первичный импорт: количество файлов, средний размер, доля сканов, таблиц и изображений, длительность обработки, объём временного хранилища.
- Поэтапная синхронизация: число новых, изменённых и удалённых документов за период, расписание запуска, необходимость повторного встраивания неизменённых фрагментов.
- Массовая перестройка: смена модели встраивания, изменение правил сегментации, исправление парсера или восстановление после повреждения индекса.
Для каждого сценария зафиксируйте:
D — число документов;
S — средний объём исходного документа;
F — число фрагментов после сегментации;
E — доля фрагментов, которым требуется новое встраивание;
T — объём временного и постоянного хранения;
P — число одновременно обрабатываемых задач.
Тогда нагрузку на обработку можно представить как F × E, а пиковую потребность в рабочих ресурсах — как функцию P, размера отдельных файлов и сложности форматов. Это полезнее, чем умножать число документов на условную «среднюю цену»: один текстовый файл и один сканированный архив могут требовать совершенно разной обработки.
Проверьте, какие параметры DocReader задействованы в вашей схеме: официальная документация переменных среды DocReader показывает, что обработку документов нельзя оценивать отдельно от конфигурации окружения. До запуска зафиксируйте лимиты размера файла, тайм-аут, временный каталог, путь к результатам и поведение при ошибке.
Скрытые расходы здесь обычно появляются в четырёх местах:
- Повторная обработка документа после незначительного изменения, если нет надёжного контроля версий.
- Хранение исходников, промежуточных результатов и текущего индекса одновременно.
- Ручная проверка сложных файлов, которые формально импортировались, но потеряли таблицы, заголовки или ссылки.
- Перестроение всей коллекции после смены правил сегментации или модели встраивания.
Как оценить стоимость RAG-запроса без выдуманной цены
Вопрос «сколько стоит корпоративная база знаний» нельзя свести к количеству запросов. Один короткий запрос с точным совпадением и один вопрос, требующий большого контекста, вызывают разные операции. Для каждого типа обращения разделите путь на четыре слоя:
- встраивание пользовательского запроса;
- векторный поиск;
- поиск по ключевым словам;
- объединение результатов и переранжирование;
- передача отобранного контекста генеративной модели.
В гибридной схеме векторный и текстовый поиск работают вместе, а переранжирование добавляет отдельный этап обработки. Возможность такого подхода и его ограничения описаны в документации по гибридному поиску и в примере переранжирования результатов.
Для бюджета введите следующие переменные:
Q — число пользовательских запросов;
K — среднее число поисковых операций на запрос;
R — число документов, переданных на переранжирование;
C — объём контекста, отправляемого модели;
M — доля запросов, которые требуют повторного ответа или уточнения.
Тогда модель нагрузки выглядит так:
нагрузка RAG = Q × (поиск + K × переранжирование + генерация контекста C) × (1 + M).
Здесь не нужно подставлять неизвестные тарифы. Сначала соберите фактические значения из журнала запросов, а затем сопоставьте их с ценами выбранных моделей и инфраструктуры. Если вы ещё не выбрали поставщика модели, сохраняйте объём входного и выходного контекста отдельно: это позволит сменить модель без пересмотра всей аналитики.
Сравнение сценариев RAG
| Сценарий | Что происходит | Что сильнее всего влияет на бюджет | Что контролировать |
|---|---|---|---|
| Короткий справочный ответ | Один поиск и компактный контекст | Число запросов и размер контекста | Максимальный объём передаваемых фрагментов |
| Сложный нормативный вопрос | Гибридный поиск, переранжирование и расширенный контекст | Число кандидатов, повторные обращения, длина ответа | Порог релевантности и лимит контекста |
| Неуверенный ответ | Повторный поиск, уточнение или передача оператору | Доля неудачных поисков и повторных генераций | Метрики отказа и правила эскалации |
| Массовый анализ | Много документов обрабатываются пакетно | Объём входных данных и параллельность | Очередь задач и время запуска |
Практический вывод: уменьшение контекста не всегда означает экономию. Если после агрессивного сокращения контекста растёт число повторных вопросов и ручных проверок, итоговая нагрузка может увеличиться. Поэтому измеряйте не только цену одного ответа, но и долю ответов, которые пользователь принимает без повторного запроса.
Как учитывать Agent, MCP, автоматическую Wiki и песочницу
Agent меняет единицу расчёта: вместо «один вопрос — один ответ» появляется задача с несколькими шагами. Agent может сначала найти материал, затем вызвать MCP-инструмент, проверить результат, сформировать промежуточный вывод и только после этого ответить пользователю. Автоматическая Wiki добавляет пакетную генерацию и повторную обработку страниц, а песочница создаёт отдельную нагрузку на изолированное выполнение.
Разделите задания на три класса:
- Обычная задача: один или несколько предсказуемых вызовов без тяжёлого выполнения.
- Сложная задача: несколько инструментов, расширенный поиск, проверка результата и длинный контекст.
- Неудачная задача: тайм-аут, ошибка инструмента, неполный результат или повторный запуск.
Используйте формулу:
стоимость Agent-нагрузки = N × (L × модель + U × инструменты + W × поиск + S × песочница) × (1 + E),
где N — число задач, L — среднее число шагов рассуждения, U — число вызовов инструментов, W — число внешних поисковых операций, S — число запусков в песочнице, а E — доля повторов и сбоев.
Официальная страница песочницы WeKnora нужна для проверки фактических ограничений изоляции, доступных навыков и параметров запуска. Не подменяйте песочницу обычным процессом приложения: у неё должны быть отдельные правила тайм-аута, доступа к файлам, сетевого взаимодействия и удаления временных данных.
Сценарий: отдел загружает внутренние инструкции и просит Agent еженедельно формировать Wiki. Если считать только число страниц, бюджет будет занижен. Нужно учесть повторное чтение изменённых документов, генерацию черновиков, проверку ссылок, возможный вызов инструментов и повторный запуск после частичной ошибки. При этом автоматическая Wiki может быть выгоднее ручной подготовки только тогда, когда доля принятых без доработки материалов измеряется отдельно.
Установите защитные пределы:
- максимальное число шагов Agent на одну задачу;
- перечень разрешённых MCP-инструментов;
- лимит вызовов одного инструмента;
- отдельный тайм-аут песочницы;
- запрет бесконечных повторов;
- максимальный размер временных файлов;
- обязательную запись причины завершения задачи.
Как выбрать локальное, облачное или гибридное размещение
WeKnora подходит для разных схем, но у каждой есть цена в виде обслуживания, доступа и контроля данных. Локальное размещение удобно для проверки на закрытом наборе документов и для организаций, которым нельзя выносить содержимое за пределы контролируемой среды. Облачный вариант проще масштабировать для удалённой команды, но требует расчёта постоянно работающих ресурсов, сетевого доступа, резервирования и политики хранения.
Гибридный режим может разделить контуры: чувствительные документы и основной индекс остаются под контролем организации, а временные вычисления или внешние рабочие процессы запускаются отдельно. Такая схема не является автоматически дешёвой — сложнее становятся маршрутизация, аутентификация, мониторинг и диагностика ошибок.
| Условие | Локальная проверка | Облачное размещение | Гибридная схема |
|---|---|---|---|
| Чувствительность данных | Наиболее простой контроль периметра | Требует проверки политики провайдера и каналов доступа | Позволяет разделить данные и вычисления |
| Нагрузка | Подходит для ограниченного числа пользователей | Проще менять ресурсы под рост | Требует согласования двух контуров |
| Удалённая работа | Нужны VPN, шлюз или безопасный прокси | Доступ обычно проще организовать | Нужны маршруты между средами |
| Обслуживание | Вы отвечаете за обновления и сбои | Часть инфраструктуры передаётся платформе | Контроль и ответственность распределены |
| Рост проекта | Расширение связано с имеющимся оборудованием | Масштабирование гибче, но расходы нужно контролировать | Возможна оптимизация, но архитектура сложнее |
Решение принимайте по условиям, а не по моде на облако:
- Если данные нельзя передавать во внешнюю среду, выбирайте локальную проверку или гибрид с локальным индексом.
- Если команда мала, а запросы нерегулярны, сначала выбирайте локальный или низкопараллельный режим; не оплачивайте постоянную высокую готовность до появления измеренной нагрузки.
- Если пользователи работают из разных сетей и нужен постоянный доступ, рассматривайте облако после проверки требований к хранению и журналам.
- Если есть резкие пики пакетной обработки, вынесите тяжёлые задачи в отдельный вычислительный контур, но оставьте лимиты очереди и песочницы.
- Если нужны физические интерфейсы, локальные устройства или стабильная круглосуточная нагрузка, аренда удалённой среды может оказаться менее подходящей, чем собственная инфраструктура.
Для проверки окружения сопоставьте выбранную архитектуру с официальной конфигурацией Docker Compose. Это не готовая смета: состав сервисов, переменные и режимы запуска могут меняться, поэтому перед закупкой зафиксируйте версию и повторите расчёт.
Если вы сравниваете варианты рабочего окружения для удалённой команды, полезно заранее проверить условия заказа и доступные варианты Macstripe. Это не заменяет расчёт хранилища, моделей и сетевых сервисов WeKnora, но помогает отделить стоимость временной вычислительной среды от расходов на постоянную инфраструктуру.
Как поставить бюджетные ограничения до запуска
Перед публикацией базы знаний подготовьте не только технический план, но и правила остановки. Минимальный набор ограничений выглядит так:
- Определите допустимое число документов и объём новых данных за период.
- Задайте максимальный размер файла и отдельный маршрут для сложных сканов.
- Установите лимит результатов поиска и максимальный контекст для генерации.
- Ограничьте число шагов Agent и вызовов каждого MCP-инструмента.
- Укажите тайм-аут песочницы и максимальный объём временного хранилища.
- Запретите повторный запуск без ограничения по количеству попыток.
- Разделите тестовые и рабочие индексы, чтобы массовая перестройка не остановила ответы пользователей.
- Включите журналирование стоимости или хотя бы ресурсных показателей по каждой задаче.
- Назначьте владельца еженедельного пересмотра квот.
- Зафиксируйте условие перехода к следующему классу инфраструктуры.
Проверяйте бюджет по неделям, записывая:
новые документы → обработанные фрагменты → запросы → средний контекст → задачи Agent → вызовы инструментов → сбои → повторы → занятое хранилище → время обработки.
Если растёт только число документов, а запросы и Agent-задачи остаются стабильными, первым изменится контур импорта и индекса. Если документы почти не меняются, но растёт количество пользователей, основным ограничением станет RAG и параллельность. Если запросов немного, но каждый проходит через много инструментов, ищите причину в Agent-маршрутах, а не в объёме базы.
Опыт эксплуатации. Увеличение квот без разбора сбоев часто маскирует плохую маршрутизацию. Сначала выясните, почему задача повторяется, какой инструмент возвращает неполный результат и нужен ли пользователю весь передаваемый контекст.
Условия выбора перед расчётом WeKnora
Используйте этот список как быстрый маршрутизатор:
- Если вы проверяете идею на ограниченном наборе документов и ещё не знаете профиль запросов, выбирайте локальный запуск с ручным сбором метрик; иначе переходите к низкопараллельному облачному окружению.
- Если обновления документов происходят редко, считайте первичный импорт отдельно от редких перестроений; иначе добавьте постоянную нагрузку синхронизации.
- Если ответ требует только поиска и генерации, не включайте песочницу в каждый запрос; иначе задайте отдельный лимит запусков.
- Если Agent вызывает инструменты только в исключительных случаях, учитывайте их как отдельный сценарий; иначе стройте бюджет по среднему числу шагов на задачу.
- Если индекс хранит чувствительные материалы, выбирайте локальный или гибридный контур; иначе облачная модель может быть проще в эксплуатации.
- Если постоянная нагрузка уже стабильна и высока, сравните собственную инфраструктуру с арендой; если нагрузка временная, экспериментальная или переменная, рассмотрите аренду рабочего окружения.
Стоимость базы знаний WeKora становится управляемой только после такого разделения: бюджет привязывается не к красивому числу файлов, а к реальному маршруту данных — от загрузки до ответа, инструментального вызова и контроля эксплуатации.
Если текущий вариант — самостоятельный сервер, он может потребовать постоянного обслуживания, резервирования, удалённого доступа и ручного расширения при пиках; облачная платформа, в свою очередь, способна накапливать расходы за постоянно запущенные ресурсы и сложные сетевые контуры. Для временной проверки, удалённой команды или переменной нагрузки аренда Mac через Macstripe может быть практичнее покупки отдельной машины: вы сначала сверяете рабочий сценарий и нужную конфигурацию, а затем выбираете среду в каталоге конфигураций Macstripe, не превращая экспериментальный Agent-проект в долгосрочную закупку оборудования.
