Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Систему ответов по меняющемуся корпусу научили не путать действующие факты с черновиками, старыми версиями и удалёнными записями. В работе Endgame Labs, Asia AI Institute и Musashino University, которая не прошла рецензирование и содержит замеры самих авторов, дешёвая модель ответила точно лишь в 1 из 30 попыток по сырым фрагментам и во всех 30 — по заранее подготовленным фактам, при этом средняя стоимость вопроса снизилась в 12,89 раза. Для продукта это переносит сложную работу с версиями с каждого чтения на момент загрузки данных.
Как документы превращаются в записи с действующим значением
В обычной схеме система находит несколько подходящих фрагментов и передаёт их LLM. Если среди них лежат черновик, исправление, отзыв и запись из тестовой среды, модель должна при каждом вопросе заново определить, какой факт действует сейчас.
Компиляцией фактов авторы называют подготовку корпуса, после которой ответ строится не по набору исходных фрагментов, а по уже разрешённому состоянию. Этот процесс состоит из нескольких последовательных операций.
Разделить источники. Документы режут на фрагменты и сохраняют для каждого происхождение, версию и среду.
Переформулировать факты. LLM превращает фрагмент в короткие самостоятельные утверждения без местоимений и ссылок на соседний контекст. Факт должен сохранять смысл вне исходного документа.
Применить правила корпуса. Система исключает черновики, тестовые и будущие записи, учитывает отзыв документа и дату удаления, выбирает старшую допустимую версию и предпочитает доверенный источник импортированному.
Сохранить результат. Действующий факт записывают вместе с сущностью, полем, значением, версией, состоянием, источником и датой вступления в силу. Источник ответа становится частью данных, а не догадкой модели.
Читать готовую запись. При вопросе система находит одну типизированную строку, а недорогая LLM формулирует ответ и переносит из неё ссылку на источник и версию.
После такой подготовки правила лучше исполнять обычным кодом: отфильтровать состояния, сравнить версии и проверить дату можно детерминированно. LLM нужна раньше, когда эти признаки ещё скрыты в прозе, и позже — чтобы превратить найденную запись в естественный ответ.
Подготовленный слой снял с модели задачу восстановления версий
Основной эксперимент провели на синтетическом корпусе из 80 сущностей и повторили на пяти вариантах данных. В корпус добавили устаревшие значения, черновики, тестовые строки, будущие даты, отзывы и отметки об удалении. Ответ считали точным, только если совпали значение, источник и версия.
На более простых вопросах обе архитектуры отвечали без ошибок, но путь через подготовленные записи расходовал в 21,6 раза меньше токенов. Значит, выигрыш возник не только из-за провалов дешёвой модели на сложных правилах: даже при одинаковом качестве ей не приходилось перечитывать шумный контекст.
Отдельно проверили переформулирование на диалогах Federal Reserve и статьях Wikipedia. У многословных диалогов объём сократился до 0,49 исходного, а 97,6% полученных фактов автоматическая модель-оценщик признала подтверждёнными источником. Краткий энциклопедический текст почти не сжался, поэтому экономия на этом этапе зависит от стиля исходных материалов.
Проверка остаётся демонстрацией механики, а не оценкой работы на корпоративной базе. Правила испытывали на синтетическом корпусе, переформулирование — на двух типах открытых текстов, а соответствие фактов источникам проверяла другая LLM без контрольной разметки людьми.
Когда архитектуру продукта стоит пересмотреть
Подход меняет планы систем, где одни и те же сведения читают много раз, а между чтениями документы исправляют, отзывают или заменяют. К таким корпусам относятся политики компании, проектные решения, стенограммы, справочники поддержки и записи со статусами согласования.
Для них поиск похожих фрагментов решает только половину задачи. Если действующее состояние всё равно восстанавливает модель, продукт платит за длинный контекст при каждом запросе и получает ответ, который зависит от способности LLM разобраться в правилах.
Компилируемый слой фактов стоит вынести в отдельный компонент загрузки данных. Ему понадобятся схема записи, явные правила приоритета, журнал происхождения, обработка изменений и повторная сборка затронутых фактов. При удалении или исправлении источника система должна обновить сохранённое состояние, иначе одна ошибка будет воспроизводиться во всех последующих ответах.
Порог окупаемости нужно считать для конкретного корпуса: работа сравнивает стоимость чтения, но не измеряет полный цикл поддержки слоя при постоянных изменениях. Практический тест — параллельно собирать типизированные факты для ограниченного раздела базы и сравнить расходы на загрузку с экономией на повторных вопросах.
Для редко читаемого или почти неизменного корпуса новая прослойка добавит схему и обслуживание без доказанной выгоды. Но если продукт уже вводит правила версий в подсказку для модели, эти правила фактически стали частью данных — их разумнее исполнить один раз и хранить результат вместе с происхождением.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
