Hacker News Digest

Проект hist-rs представляет собой высокопроизводительный утилиту для подсчета уникальных строк, написанную на Rust. Его ключевое преимущество — скорость работы, которая в 25 раз превышает производительность классической команды sort | uniq -c в Unix-системах. Это делает его идеальным инструментом для анализа больших лог-файлов и наборов данных, где важна скорость обработки.

Проект реализует эффективный алгоритм подсчета, минимизируя потребление памяти и процессорного времени. Он особенно полезен для разработчиков и системных администраторов, работающих с большими объемами текстовых данных. Код проекта открыт и доступен на GitHub, что позволяет сообществу вносить вклад в его развитие и адаптацию под различные задачи обработки текста.

• Обсуждение началось с вопроса о производительности различных инструментов для подсчёта уникальных строк в файле, где был упомянут clickhouse-local как самый быстрый способ.
• Участники обсуждали различные инструменты, включая sort, uniq, awk, uniq -c, sort | uniq -c | sort -n, tsv и csv, а также их производительность и использование памяти.
• Были упомянуты такие инструменты как tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, `tsor

Исследователи обсуждают концепцию "оптического сжатия" — представления текста как изображений для обработки в больших языковых моделях. Согласно статье, DeepSeek продемонстрировал, что из одного токена изображения можно извлечь 10 текстовых токенов с точностью почти 100%, что делает внутреннее представление изображений в моделях в 10 раз эффективнее текстового. Этот подход уже используется некоторыми компаниями и open-source проектами, хотя не является штатным режимом работы существующих моделей.

Почему это может работать? Текстовые токены дискретны и ограничены (около 50 000), тогда как токены изображений непрерывны и могут выражать гораздо больше информации. Внутри модели текстовые токены преобразуются в неэффективное представление, в то время как изображение уже содержит компактную форму данных. Более того, обработка текста как изображений ближе к тому, как работает человеческий мозг, воспринимающий текст визуально. Однако автор отмечает, что многие теоретически перспективные идеи в ИИ не работают на практике, а обучение новых моделей на тексте в виде изображений представляет собой сложную задачу.

• Обсуждение вращается вокруг идеи преобразования текста в изображение и обратно, включая OCR, токенизацию и форматирование, и как это влияет на обучение моделей.
• Участники обсуждают, что преобразование текста в изображение может быть полезно для обучения моделей, но также может привести к потере информации.
• Также обсуждается, что визуальные токены могут быть более информативны, чем текстовые токены, но также может привести к потере контекста.
• Участники также обсуждают, что визуальные токены могут быть более устойчивы к шуму и искажениям, но также могут быть более чувствительны к разрешению и форматированию.

Алекс Чжэн (Alex L. Zhang) исследует рекурсивные языковые модели (RLM), где модель может рекурсивно вызывать саму себя или другие модели для обработки контекста, который слишком велик для одного вызова.

Ключевая идея: RLM позволяет обрабатывать контекст практически неограниченной длины, избегая "гниения контекста" — когда модель теряет информацию из-за переполнения. Например, вместо того чтобы загружать весь длинный текст в один вызов, RLM разбивает его на части, рекурсивно обрабатывает каждую часть и комбинирует результаты.

Результаты впечатляют: RLM на базе GPT-5-mini превосходит обычный GPT-5 на сложных тестах, удваивая производительность, и делает это дешевле. Они также создали новый тест на основе BrowsePlos-Plus, где RLM снова выигрывает.

Важно: RLM может работать даже с контекстом в 10+ миллионов токенов, что демонстрирует масштабируемость подхода. Это открывает дорогу к обработке книг, длинных документов и сложных исследований без потери качества.<｜begin▁of▁sentence｜>

• Обсуждение в основном вращается вокруг RLM (Recursive Language Model) и его влияния на архитектуру агентов, при этом участники спорят, насколько это новая идея или просто ребрендинг существующих подходов.
• Участники обсуждают, что такое RLM: просто рекурсивный вызов LLM или же более сложная система, где корневая модель может вызывать другие модели, и как это отличается от существующих подходов, таких как ViperGPT и CodeAct.
• Также обсуждается, что такое рекурсия в контексте LLM: насколько она отличается от простого взаимодействия с внешними инструментами, и насколько она важна для архитектуры агента.
• Наконец, участники обсуждают, какие практические последствия это может иметь для разработки систем, которые используют такие агенты, включая вопросы производительности и стоимости.

Революция в ИИ: языковые модели учатся работать с отдельными символами

Современные модели ИИ, такие как GPT-5 или Claude 4.5, демонстрируют значительный прогресс в обработке текста на символьном уровне. В отличие от своих предшественников, они научились точно манипулировать отдельными символами — например, заменять букву "r" на "l" в предложениях и наоборот, что раньше было серьезной проблемой. Это стало возможным благодаря более совершенной архитектуре, которая лучше справляется с токенизацией, несмотря на то, что текст разбивается на токены (которые могут соответствовать целым словам или их частям).

Ключевые улучшения включают точный подсчет символов, включая сложные случаи вроде подсчета букв "r" в слове "strawberry", где раньше модели ошибались. Теперь даже компактные модели, такие как GPT-5 Nano, справляются с этой задачей. Более того, они успешно решают и более сложные задачи, такие как декодирование текста, зашифрованного с помощью Base64 и ROT13 (или его вариаций, как ROT20). Например, когда им дают строку в Base64, соответствующую тексту "Hi, how are you doing? Do you understand the cipher?", модели способны декодировать и ответить на нее осмысленно.

Этот прогресс особенно важен для задач, требующих работы с отдельными символами, таких как парсинг, декодирование или генерация текста с определенными условиями. Теперь ИИ может надежно использоваться в сценариях, где критически важна точность на уровне символа, а не только на уровне слов или предложений.

• LLM-ы продолжают «проверять» на задачах, для которых они не были разработаны (подсчет символов, разбор слов, игра в Quartiles), что вызывает дискуссии о ценности и ограничениях моделей.
• Пользователи отмечают, что модели не могут подсчитать количество символов или применять детерминированные алгоритмы, но в то же время признают, что LLM не предназначены для таких задач.
• Некоторые участники обсуждения выдвигают идею, что вместо того, чтобы «тестировать» модели на их способности выполнять такие задачи, следует разработать инструменты, которые могли бы выполнять такие операции, если это необходимо.
• Обсуждение также затрагивает вопрос о том, что именно является «врагом» в таких ситуациях: ограничения модели, их обучение или ожидания пользователей.

Разработчики часто сталкиваются с необходимостью сравнения данных, будь то код, текст или произвольные последовательности. Существующие библиотеки для вычисления разниц (diff) часто ограничены: многие работают только с текстом, не предоставляют структурированный вывод или страдают от проблем с производительностью и читаемостью результата. Например, популярный алгоритм Майерса, хотя и даёт минимальные различия, в худшем случае имеет квадратичную сложность, что делает его непригодным для больших или сильно отличающихся данных.

Новая библиотека на Go предлагает решение: поддержку любых срезов, а не только текста, структурированный вывод для гибкости представления и эвристики для улучшения читаемости. Она сочетает предобработку, оптимизации и постобработку, чтобы избежать типичных недостатков — например, избыточных изменений или неинтуитивных сравнений. Это делает её универсальным инструментом для задач, где важны и точность, и удобство восприятия.

• Обсуждение затрагивает различные типы diff-алгоритмов (одномерные, многомерные, древовидные) и их применение, включая сравнение кода, JSON-структур и даже схем баз данных.
• Участники делятся инструментами для просмотра diff (например, diff2html, meld, Beyond Compare) и отмечают проблемы существующих библиотек, такие как неожиданное экранирование текста.
• Поднимаются вопросы о важности минимальности diff, семантического понимания перемещений блоков и использования метаданных для улучшения алгоритмов.
• Обсуждаются практические применения diff-алгоритмов за пределами контроля версий: в тестировании, юридической сфере, сравнении расписаний и обновлении терминальных экранов.
• Упоминаются конкретные личности (например, Джин Майерс) и работы (статья Nugroho 2019 года), а также выражаются пожелания по улучшению алгоритмов, например, для работы с перемещенными данными.

• Обсуждение лицензирования: проект использует Elastic License 2.0, что вызывает споры о его статусе как открытого или исходного кода, несмотря на бесплатное использование в open-source проектах.
• Технические аспекты поиска: обсуждается эффективность brute-force подхода с оптимизацией через SIMD, сравнение с индексированными методами (например, HNSW) и вопросы производительности при больших объемах данных.
• Использование товарных знаков: критикуется использование домена sqlite.ai и бренда SQLite без явной связи с авторами SQLite, что может вводить в заблуждение.
• Практические применения: векторные базы данных полезны для поиска схожих элементов (например, через эмбеддинги) в машинном обучении, обработке текстов и изображений.
• Альтернативы и сравнения: упоминаются другие решения, такие как sqlite-vec (с открытой лицензией) и Turso, а также обсуждаются их преимущества и недостатки.

RFC 9839 и плохой Unicode

Unicode хорош, но не все его символы. Часто приходится исключать «проблемные». Чтобы формализовать это, мы с Полом Хоффманом написали черновик, и теперь он стал RFC 9839 — всего 10 страниц, читайте, если проектируете текстовые поля.

Пример боли: JSON-поле username может содержать:

• U+0000 — нулевой байт, ломает языки;
• U+0089 — устаревший C1-контрол «HTJ»;
• U+DEAD — несвязанный суррогат, запрещён в UTF-8;
• U+7FFFF — «noncharacter», не должен передаваться.

RFC 9839 перечисляет такие категории и предлагает три готовых подмножества, которые можно просто запретить.

Не вините Дуга Крокфорда: JSON создавался раньше, когда Unicode был молод. Но теперь нужен способ явно сказать «эти символы не нужны».

PRECIS (RFC 8264, 2002) уже решал похожую задачу, но 43 страницы сложностей и привязка к конкретной версии Unicode мешают внедрению. RFC 9839 проще и тупее — и, возможно, именно поэтому пригодится.

• Участники спорят, нужно ли на уровне JSON/протокола запрещать «плохие» символы Unicode (управляющие, суррогаты, заломы направления и т. д.) или оставить это прикладной валидации.
• Одни считают, что жёсткие ограничения защищают от ошибок и атак (RTL-override, залого-текст, сломанные UTF-16-реализации).
• Другие указывают на полезные кейсы C0-символов (EOF, ESC, разделители) и опасаются, что «закрыть и забыть» приведёт к 20-летней несовместимости (эмодзи, старые файлы).
• Ссылаются на RFC 8264/9839 и PRECIS-фреймворк как готовый список «что разрешать», но подчёркивают: правило должно быть явным, а не «тихо удалять».

Top Secret — новая open-source библиотека от thoughtbot для удаления чувствительных данных из произвольного текста.

Проблема: регулярки не ловят всё (имена, адреса, карты). Решение: смесь regex и NER (распознавание именованных сущностей) через гем mitie-ruby.

Как работает:

1. TopSecret::Text.filter заменяет сущности на токены [PERSON_1], [LOCATION_1] и возвращает mapping.
2. После ответа LLM вызываем TopSecret::FilteredText.restore, чтобы вернуть реальные значения.

Пример:

input  = "Ralph lives in Boston."
filtered = TopSecret::Text.filter(input)
#=> "[PERSON_1] lives in [LOCATION_1]."
mapping  = { PERSON_1: "Ralph", LOCATION_1: "Boston" }

response = "Hi [PERSON_1]! How is the weather in [LOCATION_1]?"
TopSecret::FilteredText.restore(response, mapping: mapping)
#=> "Hi Ralph! How is the weather in Boston?"

Подходит для чат-ботов, где нужно скрыть персональные данные, но сохранить контекст.
Код и демо: GitHub и стрим.

• Обсуждают лёгкий NER-фильтр на базе MITIE для автоматического скрытия чувствительных данных в строках.
• US Marshalls уже заинтересовались такой «авто-редактурой».
• Участники предупреждают: NER не 100 % точен, модель старая (~10 лет) и плохо переносится на новые домены.
• Возникает вопрос, можно ли применять фильтр к стримингу/шерингу экрана: технически возможно через accessibility-API, но нужно определять координаты сущностей и бороться с ложными срабатываниями.
• Для продакшена с длинными диалогами 1 с на инференс может быть медленно; логировать через LLM-фильтр тоже рискует «убить» скорость.

abogen — консольный инструмент, превращающий EPUB, PDF и обычный текст в аудиокниги с синхронными субтитрами.

Возможности

• Форматы: EPUB, PDF, TXT.
• TTS-движки: Coqui TTS, OpenAI TTS, Edge TTS, Google TTS.
• Субтитры: SRT/VTT, привязанные к словам.
• Языки: 40+, включая русский.
• CLI: abogen book.epub --voice en-US-AriaNeural --output book.m4b.

Установка

pip install abogen

Использование

abogen mybook.pdf --voice ru-RU-SvetlanaNeural --format m4b

Ссылки

• GitHub
• PyPI

• Пользователи обсуждают Abogen — GUI-обёртку над Kokoro TTS для генерации аудиокниг из текста.
• Качество голоса признаётся «ровным», но без эмоций и актёрской игры; для художественных книг это критично.
• Отмечены проблемы: долгие предложения обрезаются, «Mr.» читается с лишней паузой, видео-демо без звука в Firefox.
• Кто-то хочет API и автоматический пайплайн Calibre-Web → Abogen → Audiobookshelf, другие — формат DAISY и «голос Моргана Фримена».
• Итог: инструмент годен для личного использования и доступности, но пока не дотягивает до коммерческих аудиокниг.