GPT-5.6 Sol Pro сжал историю правок в SQLite более чем в 250 раз
Автор во время прогулки с собакой придумал схему для хранения истории правок текста в реляционной базе данных: собирать полный текст каждой предыдущей версии в один большой JSON-массив строк и сжимать весь массив целиком, Zlib или Zstandard. Идея в том, что из-за множества повторяющихся фрагментов такой массив должен сжиматься очень хорошо.
Сначала автор проговорил идею голосом через режим GPT-Live в приложении ChatGPT для iPhone, он отмечает, что этот режим стал заметно лучше, хотя делиться ссылками на голосовые разговоры по-прежнему нельзя. В расшифровке разговора он описал схему так: в таблице SQLite заводится столбец типа BLOB, в который кладётся сжатый Zlib или Zstandard JSON-массив текста всех предыдущих версий документа, и отдельный столбец, JSON-массив меток времени (unix-время), который сжимать не нужно.
После этого автор остановил голосовой режим и отправил GPT-5.6 Sol Pro текстовый промпт: построить на Python экспериментальные прототипы по этой идее. Модель работала 38 минут и выдала готовое решение вместе с файлами.
Схема сработала: на 1000 смоделированных правок документа исходный текст правок весил 20,4 МБ, а после сжатия Zstandard в виде JSON-массива, 80,3 КБ, то есть более чем в 250 раз меньше. Чтобы не разжимать и не пересжимать весь массив при каждой новой правке, Sol предложил разбивать историю на несколько строк: не более 128 правок или 3 МБ несжатого JSON на одну строку.
Ключевые факты
- Схема: столбец BLOB в SQLite хранит сжатый Zlib/Zstandard JSON-массив всех предыдущих версий текста; метки времени, отдельным несжатым JSON-массивом
- Идею автор сначала обсудил голосом в режиме GPT-Live в приложении ChatGPT для iPhone, затем текстовым промптом поручил построить прототип GPT-5.6 Sol Pro
- GPT-5.6 Sol Pro за 38 минут написал прототип на Python и протестировал его
- На 1000 смоделированных правок 20,4 МБ исходного текста сжались Zstandard-ом до 80,3 КБ, более чем в 250 раз
- Чтобы не пересжимать весь массив при каждой правке, Sol предложил разбивать историю на строки максимум по 128 правок или 3 МБ несжатого JSON
Почему это важно
История хранит две вещи сразу: практичную инженерную идею для типовой проблемы (эффективное хранение версий текста в базе данных) и живой пример быстрого AI-прототипирования, от голосового наброска идеи до работающего протестированного кода за 38 минут без участия человека в самом кодировании.
Кому это важно
Разработчикам, которые проектируют схемы баз данных для хранения истории версий текста (редакторы, вики, CMS, системы совместного редактирования) и ищут способ не раздувать таблицу лишними копиями. Также интересно тем, кто использует голосовые режимы ИИ-ассистентов для проговаривания идей перед их реализацией.
Как это применить
Схема простая: один BLOB-столбец хранит JSON-массив всех предыдущих версий текста, сжатый Zlib или Zstandard; второй столбец, несжатый JSON-массив меток времени. Чтобы каждая новая правка не требовала разжатия и повторного сжатия всего накопленного массива, историю имеет смысл разбивать на несколько строк с лимитом: не больше 128 правок или 3 МБ несжатого JSON на строку, это компромисс, предложенный самой моделью в ходе работы над прототипом.
Можно ли доверять
Это личный эксперимент одного разработчика, а не проверенное промышленное решение. Тесты проводились на смоделированных данных (1000 синтетических правок), результаты по объёму хранения выглядят убедительно и приведены с конкретными цифрами. В источнике нет данных о продакшен-использовании этой схемы.
Риски и подводные камни
В источнике не сравнивается скорость чтения и запросов к данным до и после сжатия, приведены только цифры по объёму хранения. Схема не проверялась в реальном продакшене, это прототип. Не проверялось, дал ли бы сравнимый результат Zlib (альтернатива, которую автор рассматривал изначально), тест проводился только со Zstandard.
«Схема работает действительно хорошо!»
— автор материала, о результатах прототипа сжатия