Интересно, а существует такой агент, который получает на вход таблицу (эксель), по размерам значительно превосходящую контекстное окно, и начинает ее документировать по сути. Вот есть несколько вкладок. Вот есть на вкладке 5 табличка в миллион строк и пять столбцов. Столбцы такие-то. Берем случайные данные из таблички, так, там вроде числа, а там — фамилии. Делаем предположение, что числа там везде — пишем код, который проверяет это предположение и заодно вычисляет мин/макс и набор уникальных значений. Так, значений немного, всего пять. Запишем. Проверяем теперь фамилии. Да, это просто строки, новый сэмплинг показал, что там фамилии правда. Тут формула. Смотрим куда она указывает. И т.д. А вот эта колонка — неясного назначения. Смотрим на данные — это какие-то числа от 0 до 1. Померяем среднее и разброс. Спросим у пользователя — может, даст какие комменты. Дал. Окалось это выданный kpi этого юзера из внешней системы. Запишем. И так далее. Получается документация. Дальше, когда есть документация, можно просить сделать какие-то операции со всем этим, поскольку LLM уже понимает плюс-минус назначение данных, и их связь, и может строить какие-то гипотезы на выявление outliers и их проверять.
Метка: AI
Зачем вашему проекту надсмотрщик за качеством данных? | 2026-05-06T16:07:42
Почти в каждом проекте разработки есть выделенная команда автоматизации функционального тестирования, однако на удивление редко встречается аналогичный акцент на Data Quality. Неважно, идут ли данные из внешних интеграций, от пользователей или генерируются самой системой, часто они остаются без должного контроля просто потому, что почему-то никто не считает это важным, а потом борятся с последствиями — они накапливаются как снежный ком. Чем дольше длятся такие проблемы, тем труднее их устранить, что в итоге приводит к ситуации, когда народ просто смиряется с «непоправимым» состоянием базы. Уж насколько лучше выявлять эти проблемы в момент их возникновения, пока технический долг не стал непреодолимым, чем потом решать, как сделать так, чтобы из-за них ничего не падало;
По сути, надо внедрять постоянного «надсмотрщика» над базами данных всех типов, использующихся системой (реляционных, NoSQL, поисковых индексов или графовых БД) — по сути, это слой проверки качества данных поверх процессов. Конечно, должны быть четкие правила — что именно проверять и какими флагами отмечать конкретные аномалии.
Должен быть ответственный за процесс (кожаный мешок, не AI), который будет интегрировать эти отчеты в рабочие процессы разработки и поддержки. Многие проблемы целостности данных невозможно решить просто через интерфейс — они требуют от инженерной команды разработки скриптов для массового исправления и очистки данных.
Тут кстати еще переходит все в область детектирования аномалий (outlier detection). Машинное обучение и LLM для выявления тонких «плохих» паттернов, которые традиционные системы на основе правил могут пропустить.
Что вы об этом думаете? Внедрены ли подобные механизмы в ваши процессы?
Преобразование чата в семантический поиск вопрос-ответ | 2026-04-30T04:05:37
За вечер сделал простую утилитку, которая вытаскивает чат Natural Language Processing за полтора года — там 65 тысяч сообщений, и переводит его в пары вопрос-ответ, по которым есть семантический поиск. При клике на результат поиска (слева) открывается диалог в чате. Подсвечиваются те сообщения, которые являются ответами на вопрос. Ну и сверху подсвечивается вопрос а оригинальной формулировке.
Как работает: система предполагает, что люди в основном делают reply to на сообщения, находящиеся относительно близко в прошлом. Если на одно сообщение делается несколько reply-to, то наверняка оно полезное, и зацепило в чате других. Система берет сообщения, начиная с того, на которое многие отвечали, и заканчивая последним в цепочке reply-to — и среди таких берет те, которые имеют минимум 3 reply-to к оригинальному вопросу. То есть, по сути, она вырезает из чата кусок, начинающийся популярным вопросом так, что после нижнего отреза скорее всего уже идет нерелевантное. Такие блоки могут накладываться друг на друга — например, если кто-то спросил, пока другие отвечали на что-то еще.
То есть, если пользователь А спросил какая погода, и ему ответили «хорошая», «плохая», «дождь», и еще было пять сообщений без reply-to, а потом кто-то ответил на «дождь» вопросом «почему дождь», и на этот вопрос ответили еще пятеро, то в систему попадет первый вопрос про погоду — кусок будет заканчиваться 13 сообщениями.
Дальше эти куски суммаризуются в вопрос-ответ.
Получается прикольно.
П. С. На скриншоте поисковый запрос не имеет отношения к результату поиска, потому что я сдуру сделал скриншот, когда запрос ещё поменял, а отправить ещё не нажал
Не та раскладка: когда gremlin стал похуистом | 2026-04-28T20:33:08
Это я набрал слово gremlin, не переключив раскладку. Собрался блин почитать про язык запросов графовых баз данных, по работе надо. Удивляет гугл, удивляет
Тесла роботы выходят на улицу | 2026-04-25T05:37:13
Роботов Тесла потихоньку выпинывает на улицу. Сегодня на велике проезжал мимо. Жаль не включают
Шиба-ину на удаленке: учимся вместе с питомцем | 2026-04-23T01:49:18
Чем занять собаку
Противоестественная интуиция высоких размерностей | 2026-04-13T23:17:35
Я сейчас много работаю с векторами большой размерности, и некоторые штуки, которые раньше не осознавал до конца, начинают реально щекотать мозг. Наша 3D-интуиция там не просто не работает — она врет.
Оказывается, любые два случайных вектора в пространстве высокой размерности с огромной вероятностью будут почти перпендикулярны друг другу. Почти всё пространство — это один сплошной «экватор».
Собственно, на этом во многом и построено машинное обучение. Если ваши эмбеддинги внезапно показывают высокую косинусную близость (например, 0.8 — это не статистическая погрешность, а мощнейший сигнал. В 1000-мерном мире «случайно» так сойтись почти невозможно.
В таких пространствах почти вся масса данных сосредоточена в экстремально тонком поверхностном слое. «Внутренности» объектов математически пусты.
Это легко проверить на таком воображаемом примере. Возьмем «кожуру» многомерного шара толщиной всего в 1% от радиуса. Объем шара пропорционален радиусу в степени размерности.
• В трехмерном пространстве мякоть (0.99 радиуса) занимает 97% объема, возводите 0.99 в куб.
• В 1000D мякоть занимает всего 0.000043%.
Можно ещё по другому понять. Чтобы точка оказалась ближе к началу координат, нужно, чтобы по всем осям координаты были близко к началу координат. Стоит одной оси иметь большое значение, и все, точка улетела. Если брать точки случайно, то просто вероятность того, что они все разом будут ниже любого значения падает с ростом размерности, причём падает быстро.
Всё «мясо» данных всегда оказывается в кожуре. Любая выборка в High-D — это, по сути, набор граничных значений.
Для белого шума в высокой размерности расстояние между самым близким и самым дальним соседом становится почти одинаковым. Понятие «близости» просто деградирует.
Сравнение производительности CPU и GPU на примере создания эмбеддингов | 2026-04-11T18:08:07
Когда работаешь с определенными задачами, насколько велика разница между CPU и GPU просто поражаешься. Например, мне вот нужно создавать много (миллионы) эмбеддингов, модель BGE M3. При запуске на моем совсем не слабеньком 24-ядерном процессоре Intel Core Ultra 9 285K создание 500 эмбеддингов занимает 45.85 секунд, а при использовании GPU NVIDIA 5090 точно такая же работа выполняется за 0.36 секунды. Это настолько быстро, что я специально писал этот бенчмарк, чтобы понять, а у меня вообще GPU привлекается или нет. Просто та программа, которая шлет в TEI запросы, делает это в тестовом режиме недостаточно активно (условно пару раз в секунду), и графики GPU просто около нуля показывают загрузку.
— Testing http://localhost:8080/embed — <— CPU version
Requests completed: 500
Total time: 45.85 sec
Throughput: 10.90 req/sec
Average latency (Avg Latency): 4386.11 ms
P95 latency: 5021.88 ms
— Testing http://localhost:8090/embed — <— GPU version (NVIDIA 5090)
Requests completed: 500
Total time: 0.36 sec
Throughput: 1398.69 req/sec
Average latency (Avg Latency): 31.38 ms
P95 latency: 53.18 ms
========================================
RESULT: is 99.22% faster
Smartfolio.me: Революция в организации знаний | 2026-03-19T04:01:04
Мое творение — инструмент для организации знаний Smartfolio.me — обросло новыми фичами. Прилагаю видос пятиминутный с обзором.
Это как гугл докс, но документы можно вкладывать друг в друга, создавая целую сеть связанных знаний, и такими документами могут быть и PDF, и обычные тексты.
Закидываешь PDF, программа превращает её в картинки, и можно прямо на страницах выделять любые куски, чтобы оставить коммент или задать вопрос.
Если в тексте что-то непонятно, выделяешь область и жмешь «elaborate» — LLM распишет всё подробно, учитывая контекст всего документа, и объяснение останется ссылкой к выделенному фрагменту.
Можно просто вырезать кусок из PDF, а LLM вытащит оттуда чистый текст или готовую формулу.
В окне с PDF теперь есть своя панелька — там сразу видны все комментарии и разъяснения, так что можно быстро прыгать по нужным местам.
Можно вырезать схему или график из PDF, скопировать как картинку и вставить в свой текст. Она сама обрежется «на лету» и сохранится в базу, но не как копия, а как ссылка на страницу с параметрами кропа.
Если удалил ссылку на страницу в тексте, она не пропадет совсем, а попадет в специальный список, откуда её можно привязать в другое место или удалить окончательно. Один и тот же документ можно вставить в несколько мест. Если добавил в него коммент, он обновится везде, где этот документ прилинкован.
Математика поддерживается полностью — формулы на LaTeX можно не только смотреть, но и кликнуть, чтобы подправить их в редакторе.
Можно генерировать формулы по описанию. Просто пишешь словами, что за формула тебе нужна (например, «биномиальное распределение»), и система сама выдает готовый код формулы.
Теперь есть система плагинов — по сути это изолированные от главной программы экспериментальные функции. Например, есть плагин, который рекурсивно собирает все-все дочерние странички в один длинный документ — удобно, если надо всё сразу прочитать или распечатать.
Или вот плагин «Чистка транскриптов YouTube». Если есть грязный текст лекции с YouTube, плагин сам расставит знаки препинания, параграфы и сделает красивые заголовки.
Если вставишь ссылку на сайт, он откроется в колонке рядом — можно читать источник и одновременно делать свои заметки. При этом некоторые сайты не разрешают себя встраивать в чужие страницы. Система такие сайты опознает, и они открываются в новой вкладке.
Левую панель со списком страниц можно скрывать или менять её размер мышкой, чтобы она не отъедала место на экране.
Можно просто скопипастить изображение или скриншот, и он не просто вставится, а еще и зааплоадится в базу данных.
Поддерживается работа с мобильного телефона. На телефоне интерфейс переключается в режим одной колонки, чтобы было удобно читать и комментировать на ходу.
Поддерживаются несколько баз данных — можно переключаться. Можно подключать разные базы данных и разные LLM и переключаться между ними.
Эффективное изучение языка с электронным словарем Набокова | 2026-03-15T23:20:05
Блин, реально ж удобно. Сижу читаю.
Паттерн использования такой: держу телефон в руках. Там в apple books эта и книжка. Видишь незнакомое слово — оно с большой вероятностью будет в списке слов главы. Определение учитывает перевод самого Набокова. Дальше смотришь на пару слов вперёд, убираешь телефон, продолжаешь читать. Встречаешь те слова, и они ещё в кратковременной памяти, и ура, понимаешь. В паузу загружаешь в мозг следующие пару слов. В руках надо держать телефон и перелистывать, каждая страница содержит 4-5 определений.
Сейчас каждое слово имеет определения на английском (толкование), французском, и немецком. Соответственно, я могу издать четыре книжки.
В целом, мой уровень английского совпадает с предположениями моей программки о том , какие слова будут вызывать сложность. Но когда-нибудь мне надо такое для французского, и там понадобится для и каждого слова некоторую оценку уровня сложности, потому что мне будут непонятны и некоторые базовые слова тоже. Не уверен, что книжка с базовыми словами будет удобна. С редкими — точно удобна.
Being in America 