Интересно, а существует такой агент, который получает на вход таблицу (эксель), по размерам значительно превосходящую контекстное окно, и начинает ее документировать по сути. Вот есть несколько вкладок. Вот есть на вкладке 5 табличка в миллион строк и пять столбцов. Столбцы такие-то. Берем случайные данные из таблички, так, там вроде числа, а там — фамилии. Делаем предположение, что числа там везде — пишем код, который проверяет это предположение и заодно вычисляет мин/макс и набор уникальных значений. Так, значений немного, всего пять. Запишем. Проверяем теперь фамилии. Да, это просто строки, новый сэмплинг показал, что там фамилии правда. Тут формула. Смотрим куда она указывает. И т.д. А вот эта колонка — неясного назначения. Смотрим на данные — это какие-то числа от 0 до 1. Померяем среднее и разброс. Спросим у пользователя — может, даст какие комменты. Дал. Окалось это выданный kpi этого юзера из внешней системы. Запишем. И так далее. Получается документация. Дальше, когда есть документация, можно просить сделать какие-то операции со всем этим, поскольку LLM уже понимает плюс-минус назначение данных, и их связь, и может строить какие-то гипотезы на выявление outliers и их проверять.
Рубрика: Programming
Зачем вашему проекту надсмотрщик за качеством данных? | 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, не переключив раскладку. Собрался блин почитать про язык запросов графовых баз данных, по работе надо. Удивляет гугл, удивляет
Сравнение производительности 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
Диплом с отличием: путь программиста Рауфа Велиевича | 2026-03-21T13:54:58
Мама прислала. Это мне с окончанием школы выдали. Хорошее школьное образование было по крайней мере в то время. Часть занятий по точным наукам шла в институте
Словарь Набокова: Мультиязычное путешествие по текстам писателя | 2026-03-15T18:30:39
Читаю Набокова и решил отвлечься и сделать удобную программку «Словарь Набокова» и подумываю продавать его на Амазоне как книгу. По сути, выглядит это так (см скриншот) — определения сложных слов на английском, русском, немецком и французском, идущих в том же порядке, в каком они идут в оригинальной книге.
Вы бы купили такую книжку?
Для того, чтобы корректно сделать их определения, я также написал aligner — программу, которая сопоставляет предложения и абзацы на английском с их переводами (набоковским) на русский. И когда создается определение слова, используется не только знание LLM, но и перевод на русский автора. Отдельно стоит рассказать, как работает алгоритм (я его сам придумал, потому что все, что нашел в сети, не работало как мне надо). Он находит сначала длинные предложения, и находит для самых длинных предложений их пару через косинусное сходство embedding-векторов, созданных через модель multilingual e5. Эти предложения становятся якорями. Затем, предполагая, что для длинных предложений ошибка почти исключена, находится самое длинное предложение уже между якорями, и все повторяется заново рекурсивно. Там много ситуаций, когда у предложения на русском нет аналога на английском и наоборот, когда предложение разбито на два, или наоборот два слиты в одно. Алгоритм как может это обрабатывает. Результат — очень неплохое качество выравнивания. До такой степени, что ошибки выравнивания уже не получается находить (но наверняка они есть). Так или иначе, оно нужно только для контекста для перевода слов, даже если там и есть редкие ошибки, то не страшно.
Вы бы купили такую книжку?
С турбо паскаля до CAD для мебели: история Bazis Soft | 2026-03-06T17:43:22
Моя первая работа, программистом, с офисом в Коломне и за деньги. 1993 год, а может еще годом раньше. 10-11 классы школы. И эта компания до сих пор существует, и ребята, с которыми я работал, до сих пор там! Наталья Бакулина, Павел Бунаков, Николай Каскевич. Прикиньте. Причем они вообще начали в 1986 году, то есть 40 лет назад уже! Я с трудом вспомню еще коммерческие компании такого возраста в России. Когда я пришел к ним работать, был MS DOS, писали на Turbo Pascal, но они начинали за много лет до меня еще на ЭВМ СМ-1420, правда, тогда компания была не совсем коммерческой. На момент моего прихода система была конкурентом AutoCAD на рынке, локально еще конкурировали с «Компас». Я делал установщик с дискет 5.25″ и 3.5″ — это чтобы почувствовать дух эпохи. Дальше они перешли на Delphi и Windows. Дальше они сузили тему, и из CAD для машиностроения перешли к CAD для мебели, где до сих пор у них очень неплохие позиции.
Инновационный веб-блокнот с AI и PDF: переосмысление работы с информацией | 2026-02-19T16:19:37
Еще доработал новый тул для себя для работы с информацией и её организации. Основная идея — это веб-блокнот для исследований, изучения темы, работой над ней, интегрированный с AI и поддержкой PDF.
Главная проблема обычных PDF-ридеров и заметок заключается в том, что контекст теряется, как только вы переключаетесь на новую вкладку. В моем инструменте каждый фрагмент текста или PDF становится узлом в «живом» гипертекстовом дереве, к которому я могу доступиться с нескольких компов в любое время.
Процесс работы:
— Контекстный AI. Я могу просить AI разъяснить сложные пассажи прямо внутри документа. Объяснение остается именно там, где был задан вопрос. При этом оно является отдельным документом, привязанным к конкретному месту в источнике. При клике вы видите на экране одновременно и оригинал, и пояснение.
— Панели вместо окон. Если само объяснение требует уточнений, справа открывается новая панель. Это позволяет выстраивать бесконечную цепочку запросов, ни разу не теряя места в исходном тексте. То есть, вы видите сразу несколько панелей, ненужные можно закрыть.
— Поддержка PDF. Я могу загрузить PDF, выделить область на странице (например, сложную диаграмму или список авторов), и LLM мгновенно извлечет данные, дополнит или объяснит их. Объяснение прицепится к месту, где его просили, как и в случае не-PDF.
— Вложенные аннотации. Мои комментарии — это не просто статичный текст. Они могут содержать собственные PDF, ссылки и дальнейшие подзадачи для AI, поддерживая глубину вложенности, которая отражает то, как мы мыслим на самом деле.
Это не просто система хранения файлов, а «движок» для построения знаний.
Инструмент отлично подходит мне лично, но, возможно, он решает только мои специфические задачи. Как вы думаете, будет ли нечто подобное полезно другим? Было бы это полезно вам? Стоит ли развивать проект до полноценного продукта и давать его на тест другим пользователям?
Интерактивные врезки для понимания текста: новый инструмент объяснений | 2026-02-12T16:11:10
Запилил буквально за час такую штуку. Как думаете, она кому-то кроме меня нужна?
Идея такая. Берем любой текст — статья, например, википедии. Выделяем любой фрагмент, например, что непонятно. LLM нам дает объяснение, и тут же в текст втыкает врезку. На которую можно кликнуть, и откроется объяснение. В этом объяснении может быть тоже что-то непонятно. Выделяем мышью уже из этого, и там тоже появляется врезка. И так, пока не разберемся. Все врезки остаются в тексте, так что всегда можно к ним вернуться. Как бы идея, раз мне тут было непонятно, может и другим не будет, и тогда им очень кстати будет готовая ссылка с разъяснениями. Результат можно зашарить с коллегами.
Для разъяснения конечно используется не только фрагмент, но и контекст. Например, иначе бы выделенное слово Terrier выдавало бы текст про собак, а не про про поисковую систему.
Being in America 