Инструмент оценки цитируемости для ИИ-поиска поставил нашему сайту 31 из 100 и F почти всем блокам. Переписали рубрику под русский язык, не трогая веса и логику измерений: получили 42,5. Разрыв в 11,2 пункта собран из трёх регулярных выражений.
Считал долю пальмового масла в детском питании, получил 10%, обрадовался сенсации. Потом открыл выборку глазами - и всё поехало. Разбор ложных срабатываний поиска по ключевому слову на базе составов: пальмитат, медь, мускатный орех и другие ловушки.
У меня в проде работает ИИ-консультант на сайте. У него есть два правила, которые нарушать нельзя вообще: не называть цены и не называть клиентов, которые под NDA. Оба правила были написаны в системном промпте капслоком, с объяснением почему.
Я замерил, как они соблюдаются. Получилось так:
Задача звучала просто: посчитать, у скольких товаров в базе есть в составе хоть одна Е-добавка. Я думал, это работа на полчаса. Работа заняла вечер, и большая часть вечера ушла на одну букву.
Нам понадобились свои данные о том, как устроены страницы, продающие франшизы. Не мнение, не подборка скриншотов, а числа, которые можно пересчитать через полгода и сравнить. Готовых датасетов по этой нише нет, поэтому мы написали скрипт: он забирает шестнадцать страниц, ищет на них набор признаков и складывает результат в JSON.
Первая выгрузка выглядела убедительно. Потом мы открыли страницы глазами и обнаружили, что по одному признаку скрипт ошибся больше чем вдвое. Эта статья про то, где именно регулярное выражение находит слово, но не находит смысл, и что с этим делать, если полностью уйти от регулярок нельзя.
Всем привет!) Напомню: в первой статье я показал дебаунс на Redis, который склеивает дробные сообщения клиента. Во второй — модуль привязки «чат = сделка» и то, почему вебхуки стоит держать в изолированных ключах. Обе части заканчиваются примерно одинаково: «...и текст уходит ИИ‑агенту». Это, пожалуй, тот финал, на котором обычно ставят точку и заливают демо на GitHub... Но не в данном случае!)
Для создания подсветки синтаксиса мне требовалось регулярное выражение, которое может подсветить разные фрагменты пути. При этом оно должно следовать условию "только путь в кавычках" и обходить мимо переменные, продолжная парсинг пути.
В этой статье мы разберем, каким образом написать такое выражение, как работает рекурсия в RegEx, как добавить условие выхода из нее. Посмотрим, как пропускать целые фрагменты текста.
Регулярные выражение обладают возможностями отслеживания пройденного пути и рефлексией. Разберемся, как использовать эти возможности для захвата фрагментов текста, как применить к ним цвет и вывести в консоль с помощью AutoHotkey.
Задача широко знакома в узких кругах: наш каталог товаров встречается с каталогом контрагента — по сути одни и те же позиции, но названы по-разному. Надо найти совпадения и предоставить коллегам список подходящих наших артикулов для каждой их позиции.
В разобранном ниже случае это картриджи: 22 тысячи записей у контрагента против сотен тысяч наших номенклатур. Для такой задачи матерый программист берёт Elasticsearch, алгоритмы нечёткого поиска и тратит много времени, иногда в меру матерясь. Здесь подбор ведется с помощью токенизации, запросами в стиле no-code и без ИИ.
Разаработанная фоновая утилита позволяет производить вставку сжатых логов с абсолютной прозрачностью для восприятия AI агентами. В статье описал свой путь к оптимизации сжатия до 80%.
В данной статье описывается процесс реализации песочницы для регулярных выражений с помощью платформы для контейнеризации Docker и утилит Linux. Цель - получить ограниченную среду, куда пользователь может подключиться по SSH и где у него будет минимум возможностей, чтобы он ничего не сломал, но мог свободно использовать регулярные выражения как со встроенными в среду txt заготовками, так и со своим произвольным пользовательским вводом.
Если обычный человек посмотрит на исходный код программы, написанный на популярных языках вроде JavaScript или Python, то по контексту и знакомым словам он сможет понять, что происходит. Но регулярные выражения со стороны похожи на случайный набор символов – будто кошка прошла по клавиатуре. В этом случае даже код на Ассемблере выглядит более читаемым.
Мы в «ЛАНИТ-Интеграции» не понаслышке знаем, как бывает сложно собрать воедино данные из нескольких источников, привести их к общему виду и создать на их основе единую таблицу с полным отчетом. Для решения этой задачи был создан плагин «Аналитика» для Р7-офис как инструмент автоматизации для выгрузки и обработки данных. В этой статье в блоге ЛАНИТ хочу рассказать вам о новых возможностях поиска данных в плагине в сочетании с функционалом RegExp (они же регулярные выражения или просто регулярки).
Парсинг HTML при помощи регулярных выражений — популярная ошибка и отличный пример использования неподходящего под задачу инструмента. Общепризнанно, что это плохая идея по множеству причин.
Существует знаменитый ответ на Stack Overflow о том, почему этого ни в коем случае не следует делать. На самом деле, этот ответ стал настолько популярным, что в определённых кругах используется, как копипаста. Каждый раз, когда я натыкаюсь на него, то думаю что он во многом справедлив... но в то же время, не могу согласиться с ним полностью...
Про find можно писать много и долго, а если еще перевести мануал и снабдить каждый параметр развернутыми примерами, то материала получится на целую книгу. Пока эту книгу никто не написал, я решил рассказать о некоторых особенностях работы утилиты с регулярками и другими функциями.
Регулярки освоить нетрудно. Буквально за пару часов можно получить почти средний уровень владения и научиться читать и писать выражения для поиска ip-адресов, e-mail, html-тегов, телефонных номеров, дат и прочих несложных конструкций. Я думаю, все это вам знакомо, но на всякий случай в конце статьи я добавил несколько ссылок для изучения.
Я уже прошел «курс молодого бойца» по регуляркам, написал свою, вставил в find, и она не сработала. Но пойдем по порядку.
Разработка парсер генератора ISPA: что реализовано и какие планы на будущее.Гибкий парсер нового поколения с теми функциями, которых давно не хватает существующим решениям.
Представьте: нужно проверить документ или веб-страницу и найти повторяющиеся слова, чтобы, скажем, заменить их. А если найти нужно не просто слова, а электронные адреса, которые бывают разными.
Решение этой задачи существенно упростит использование регулярных выражений.
Регулярные выражения или regex (от англ. regular expression) – это особый синтаксис для описания шаблонов поиска информации. С их помощью можно искать, заменять или извлекать данные из текста с высокой точностью. В основе регулярных выражений лежат символы, которые задают правила для поиска, например, всех цифр или слов, начинающихся на определенную букву. Регулярные выражения позволяют описать сложные условия поиска в простой и читаемой форме, что делает их незаменимыми для различных задач.
Регулярные выражения помогут в разных случаях – от валидации данных, например, при проверке форматов номера телефона до анализа текстов: получения ссылок или другой информации.
Посмотрим на синтаксис регулярных выражений. Дальше на примерах станет понятнее.
Меня с детства привлекала тема признаков делимости числа. Особенно удивительно было узнать про признаки делимости на 3 и на 9, когда путем простого сложения всех чисел и проверки результата можно было узнать делится ли изначальное число на эту цифру. Кроме того было интересно узнать, что существует регулярное выражение определяющее простоту числа. Но основной фокус там в том, что число записывается в унарном виде.
И вот пару лет назад я встретил еще одну интересную задачу по написанию регулярного выражения для определения делится ли искомое число на 7. Само число при этом написано в двоичном виде. Признаки делимости на 7 существуют и для двоичной и для десятичной записи, но как правило они требуют производить операции умножения, сложения и рекурсивно проверять делимость уже получившегося в итоге этих действий меньшего числа, что не очень подходит для написания регулярного выражения. Я предполагал, что каким то образом могут помочь сложные операторы: условное сопоставление (позиционные проверки), обратные ссылки итд, но не разобрался как их использовать конкретно для данной задачи. Гораздо больше я думал в сторону более простой регулярки с использованием только оператора ИЛИ, квантификаторов и скобок. Остановился на построении графа остатков от деления следуя, по которому можно получить остаток заданного числа, но уперся в то, что всякое выражение с использованием скобок, но без ссылок - это в итоге дерево и поэтому произвольный граф туда не ложится. Это как пытаться хранить произвольный граф в JSON или XML - можно, но нужно будет вводить идентификаторы узлов и поля ссылок, а в то же время хранение простого дерева этого не потребует.
Я хочу поделиться своим изобретением, которое позволяет вам использовать только одно регулярное выражение, которое будет искать подстроку в строке с определенным условием. Если хотите, называйте это циклом в RegEx, которого раньше не существовало!
Я поделюсь с вами не только разными полезными шаблонами, но и покажу различные примеры от простых до сложных.
Если я хочу посмотреть видео — разве для этого обязательно покидать vim?
Что ж, прямо в заголовке этого поста я пообещал вам продемонстрировать Bad Apple в vim, пользуясь только поисковыми запросами. Вот Bad Apple в vim, всё, что здесь меняется — только поисковый запрос:
