Сотруднику часто нужен конкретный ответ: где описан порядок согласования, какие требования действуют для выбранного изделия, чем новая инструкция отличается от предыдущей. Полезный помощник должен показать основание ответа и позволить открыть документ. Начинать проект стоит с одного процесса, владельца материалов и понятного способа проверки. Это помогает определить, нужен ли обычный поиск, поиск с генерацией ответа или более сложная система.
Как устроен поиск с ответами
В подходе RAG система находит относящиеся к вопросу фрагменты документов и передаёт их языковой модели вместе с запросом. Модель формирует ответ с опорой на найденный контекст. Внешняя база знаний и параметры модели — разные части системы. Такая архитектура описана в исследовании Retrieval-Augmented Generation.
Для корпоративного сценария предлагаем показывать рядом с ответом название документа, его редакцию и соответствующий фрагмент. Механизм ссылок можно реализовать отдельно: например, CitationQueryEngine в LlamaIndex связывает ответ с доступными для просмотра источниками. Наличие ссылки ещё не подтверждает правильность вывода: специалист должен проверить, действительно ли фрагмент обосновывает утверждение. Пример LlamaIndex использует облачные компоненты и сам по себе не является готовой локальной конфигурацией.
RAG, дообучение и собственная модель
Для подключения новых документов к RAG обычно обновляют корпус и поисковый индекс. Это не означает обучение базовой языковой модели. Дообучение меняет параметры уже обученной модели на подготовленных примерах под задачу или предметную область. Обучение с нуля начинается без готовых обученных весов и требует другого объёма данных и ресурсов. Различие между дообучением и исходным обучением объясняет документация Transformers.
Эти подходы можно сочетать. Выбор определяется проверяемой задачей: документы должны находиться, ответы — соответствовать источникам, а формат — подходить рабочему процессу. Дообучение рассматривают после разбора ошибок; оно не заменяет актуальные документы и проверку источников. Использование сторонней модели в проекте не превращает её в собственную базовую модель исполнителя.
Что согласовать в составе внедрения
В техническое задание стоит включить:
- перечень материалов, владельцев, допустимых форматов, редакций и правил обновления;
- подготовку текста, разбиение на фрагменты и сохранение связи с оригиналом;
- поиск, модель ответа, интерфейс и согласованные интеграции;
- роли пользователей, ограничения доступа, правила хранения запросов и журналов;
- контрольные вопросы, протокол проверки, инструкцию эксплуатации и порядок отката.
До начала нужны примеры рабочих вопросов, ожидаемые ответы и разрешённый для обработки корпус. Если PDF содержит сканы, распознавание и проверку извлечённого текста следует оценить отдельно. Таблицы, схемы, приложения и противоречащие редакции также требуют собственных контрольных примеров. Ответ по нескольким найденным фрагментам нельзя выдавать за полную проверку всех документов.
Как выбирать модель и оборудование
Сравнивайте несколько подходящих вариантов на одинаковых русскоязычных вопросах. Учитывайте качество ответа, время ожидания, параллельную работу, длину контекста, поддержку эксплуатации и условия использования конкретной версии. Карточка Qwen3-8B, например, содержит сведения о модели и отметку Apache-2.0; это пример источника для проверки, а не рекомендация единственной модели или вывод о лицензиях всего решения.
Универсального требования к GPU нет. llama.cpp поддерживает разные аппаратные платформы, квантование и совместную работу CPU/GPU. В Ollama потребность в памяти зависит в том числе от контекста и параллельных запросов. Конкретную конфигурацию подбирают по измерениям на согласованной нагрузке; обещать скорость заранее без такой проверки некорректно.
Что означает работа в вашем контуре
Проверять нужно всю цепочку: извлечение текста, поиск, модель, внешние API, журналирование и обновления. Например, Ollama отдельно описывает локальный режим и отключение облачных функций в официальном FAQ. Из этого следует практическое требование: локальная модель сама по себе не доказывает отсутствие исходящей передачи данных. Подтверждение требует проверки фактических настроек и сетевого поведения системы. Соответствие обязательным требованиям оценивается отдельно.
НЬЮ-ССТ предлагает обсудить документы, пользователей и ожидаемый результат, затем определить ограниченный первый этап. Базовый поиск по каталогу и следующий этап ИИ/RAG имеют разный состав; подключение ИИ, ролей и обновлений согласуется отдельно. Для первого разговора достаточно описать задачу без вложения закрытых документов. Обсудить задачу: цель, форматы материалов и результат, который нужно проверять.
Вопросы о локальном ИИ
Нужно ли обучать собственную модель на всех документах?
Не обязательно. RAG подключает материалы через поиск; дообучение изменяет готовую модель на примерах. Решение принимают после анализа задачи и ошибок. Для поиска актуальных положений сначала нужно обеспечить качество корпуса и извлечения источников. См. исследование RAG и Transformers.
Можно ли работать без передачи запросов в облако?
Можно проектировать такой режим, но его подтверждают для всей системы. Нужно проверить модель, поиск, распознавание, интеграции и сетевые обращения. Наличие отдельного режима отключения облачных функций в Ollama показывает, почему одной локальной установки недостаточно для вывода о всей архитектуре.
Гарантирует ли ссылка на документ правильный ответ?
Нет. Следует проверить редакцию, сам фрагмент и соответствие ему каждого существенного вывода. Просмотр исходного фрагмента предусмотрен, например, в CitationQueryEngine. При противоречии или недостатке данных помощник должен обозначать ограничение и передавать вопрос специалисту.
Как понять, стало ли лучше после обновления?
Сравнить принятую версию и кандидата на одном контрольном наборе, отдельно учесть новые риски и ошибки. Зафиксировать версии корпуса и компонентов, качество ответов, доступы и задержку. Возможность раздельной проверки компонентов и всей цепочки описана в Haystack; окончательное решение принимают по согласованным критериям.