• Исходная документация: 847 страниц (около 1,2 млн токенов) при контекстном окне 200 тыс.
• Прототип SemanticZip дал «сжатие» 14x и QA-верификацию 94% на контрольных вопросах.
• При «распаковке» LLM генерировала разные версии текста и добавляла детали, которых не было в оригинале (пример: про PostgreSQL и репликацию master-slave).
• В тесте с документом на 50 фактов и 10 вопросами QA-верификация была 90%, но 12 из 40 непроверенных фактов исказились или потерялись, и появились 8 новых «фактов».
• При извлечении «ядра» из одного документа пять запусков дали пять разных наборов, включая непостоянное попадание параметров вроде SESSION_TTL=24h.
• По итогу автор пришёл к выводу, что SemanticZip — это скорее вариация RAG, а классический RAG лучше тем, что хранит и возвращает оригинальные фрагменты текста.

Почему это важно: Для архиваторов вроде 7-Zip «распаковка» должна быть обратимой и детерминированной, а у LLM восстановление превращается в творческую реконструкцию. В практических задачах это означает риск «правдоподобных» деталей, которые не подтверждены исходником. QA-подход проверяет, что сохранилось, но не выявляет то, что модель добавила сверх текста.

На что обратить внимание: В тексте подчёркивается разница между «ядром фактов» и тем, что модель сочтёт выводимым по умолчанию, поэтому итог зависит от контекста и формулировок. В экономике решения важны не только токены «потом», но и цена предварительной обработки: 6–8 вызовов API на документ автор сравнивает с альтернативой большого контекста. Как следующий шаг описываются практики: секционирование с хранением оригинала, явная приоритизация и поиск по документу вместо попытки пересказать его целиком.