Comments 49
Уже не первый раз наблюдаю, что восторг от использования ИИ возникает у пользователей на ровном месте от того, что они не в курсе возможностей, которые давно существуют без всякого ИИ.
Открыл справку Acrobat - прекрасно он ищет по нескольким файлам одновременно, решая Вашу задачу (у меня не Acrobat, а PDF-XChange, там такое тоже, само собой, есть) Единственное в Вашем случае надо посмотреть, будет ли он гласные с ударениями искать по запросу, в котором эти же гласные без ударений (если нет - самым простым решением кажется создать копии словарей для поиска, в которых простым поиском-заменой все ударения убрать).
Ну а если уж кодить своё - PDFки там с текстовым слоем, загнать всё в одну БД элементарно, искать будет как угодно гибко и быстро. Но учитывая Ваши вопросы... лучше попросите кого-то помочь. ИИ нынче замечательно умел, но навык постановки корректного ТЗ никто не отменял.
Это задача на 15 минут для новичка.
Ну точно не на 15 минут. Словари толком не структурированы, кроме собственно словарной части ещё всякие введения/сокращения/пр., которые надо отбрасывать, причём в 4 разных словарях эта структура разная. Разбиение на словарные статьи делать придётся только по форматированию (PDF же), тоже 4 разных алгоритма. Есть статьи, где несколько вариантов слова в одной статье (в словаре "выставля́ть(ся)", надо чтобы находил по поисковой строке "выставляться", наверняка ещё и другие подобные нюансы найдутся) Ударения не проверял, но их обычно в кириллице делают двумя способами - правильным (два юникодных символа) и простым (один символ из латиницы, пишущийся аналогично), надо учитывать обе возможности. А ещё бы по всем словоформам потом искать... и обновлять как-то это всё, если словари на оф. сайте обновятся.
P.S. Повеселило в официально (!) опубликованном словаре 32 вхождения фразы "Error! Bookmark not defined". Делали в Ворде, публиковали не приходя в сознание... мда.
А Elasticsearch с asciifolding, не закроет эту задачу, при условии что поиск должен быть именно на сайте ?
Opensearch (в пень Elasticsearch с их новой лицензией...) закроет простой поиск, но если мы захотим отфильтровать именно термины, то тут уже надо парсить текст похитрее. А мы, наверное, захотим в итоге и функционал "проверить наличие несловарных слов в произвольном тексте" (ну напрашивается же), так что лучше сразу готовить нормальную БД.
Даже Elasticsearch может быть дорогим и избыточным. Есть прекрасный FTS в PostgreSQL и какой-нибудь Apache PDFBox для чтения и индексирования.
Для своего пет проекта я преобразовал около 500 PDF в текстовый формат, оттуда в векторную базу данных.
Питон ставится самой ллм за три минуты, дальше она же скачет какую-нибудь уже готовую библиотеку - и преобразование PDF в json займёт ещё пару минут.
Что дальше делать с текстом вопрос уже к автору, в каком виде ему нужно.
Но это реально задача на пару часов максимум, без знания кода вообще.
Главное не использовать какой-нибудь дипсик или композер, а потратить 20 баксов на подписку и пользоваться платной моделью (хотя на самом деле с такой простой задачей даже авто в курсоре справится).
Векторную базу? Зачем тут векторная, не поде́литесь?
В условии задачи — самое главное — показать ссылку на справочник (на страницу в печатном издании, оно же PDF) и текст оттуда. Как вы планируете из джейсона обратно в PDF прилинковываться?
В общем, камни в этой задаче ворочать — немного сложнее, чем языком чесать.
P.S. Всё уже написано до Вас :) Кэш и оверсайз успешно ищутся. Нет ссылок на страницы, правда.
Спасибо за ваше участие.
По этому решению - да, сделано, но работает криво. И видимо по тем причинам, как описано в статье и комментариях выше.
Попробуем найти слово «кэшбэк»
А слово есть в словаре
Видимо из-за используемых в файле символов скобок и ударений ищет только вариант кЕшбэк через Е, хотя в словаре есть два варианта слова - через Е и Э.
А вопрос в юридической плоскости означает - оштрафуют юрлицо на полмиллиона или нет? Переделывать вывески или оставить?
Хочется найти решение, чтобы поиск работал корректно.
В моем временном решении кэшбэк нашелся
Конкретно с кэшбэком я вижу ошибку в словаре. В именительном падеже Е, в родительном почему-то Э (второе Э после \\ относится в произношению, а не написанию, с ним всё ОК). Хотя во введении к словарю прямо написано, что через запятую до \\ указываются только словоформы, в которых ударение может падать по-разному, но никак не разные варианты написания.
Если бы я делал свой поиск - у меня бы кэшбэк через Э тоже не нашёлся by design.
P.S. Я особо не погружался в эту тему, но, насколько я понимаю, ответственность наступает за использование слов, отсутствующих в словарях, а не за написание имеющихся в словарях слов с орфографическими ошибками. Поэтому, даже если бы в словаре был везде только кешбэк через Е - за написание кэшбэк через Э ответственности нет. А отсюда вытекает ещё одно требование к ТЗ для поиска - неплохо бы находить не только буквальные вхождения искомых слов, но и все похожие слова...
Попробуйте вот еще этот словарь
а негуманитариям (технарям то есть) зачем вайбкодинг если они могут научится программировать? ну кроме каких то набросок кусков кода чтобы в стековерфлов не искать - типа примера поиска по pdf
Скажите, стоит мне дальше мучать ИИ и продолжать описывать свои мучения (подозреваю, что для специалистов может выглядеть смешно) или подросток, не верящий в силу интеллекта родителя и искусственных интеллектов был прав?
То что вы написали, это вовсе не смешно, а в некоторой степени даже грустно. К сожалению, это весьма распространённое сейчас заблуждение, то есть типичный современный пользователь думает так: "Это второй мозг, он даст мне экспертные ответы на мои вопросы" и т.п. Сейчас я работаю над книгой по теме продуктивного использования нейросетей, и в процессе сбора материала и интервью с пользователями, постоянно сталкиваюсь с таким крайне порочным и ошибочным мышлением. В реальности, продуктивное использование моделей сводится приблизительно к следующему: оператор-эксперт делает работу, модель помогает решать рутинные задачи, например быстро набрать материал для исследования, предложить структуру, черновик, версии... Эксперт анализирует полученную информацию и на основании своего (ключевое слово "своего") опыта и уровня, делает выводы и итоговое заключение. Если проще, то могу вам дать что-то типа "аксиомы", которую всегда стоит помнить при общении с любой моделью нейросети: "Мусор на входе=мусор на выходе". В профессиональной среде, это выражение используется несколько в другом контексте, но в этом ответе я использую его в самом широком смысле. Просто помните это и любая сессия работы с моделью будет проходить продуктивней. Конкретный ответ на Ваш вопрос: "ИИ имело бы смысл помучать в том случае, если бы у вас был технический бэкграунд для того, чтобы решить эту задачу вручную". Желаю Вам достигнуть своей цели. Лучший вариант для вас это привлечь специалиста (быстро), или самому "учить матчасть", как некоторые любят говорить (долго). По поводу того, что вы гуманитарий, можете нисколько не расстраиваться, из среды гуманитариев есть много прекрасных программистов и ИТ-инженеров. Вопрос только в желании.
Заинтриговали книгой. Где следить за релизом? Может черновик уже есть в доступе?
Честно говоря даже не знаю, как ответить на ваш вопрос. Думаю к лету закончить вычитку, "вылежку" и редактуру, а вот где и в каком виде выпускать - будет зависеть от того, что будет происходить в этой стране к тому времени. Думаю, вы понимаете о чём я. Изначально планировалась "цифра" для Amazon, а вот что будет теперь....вопрос даже для меня пока открытый.
К тому времени как книга выйдет она может и устареть. Слишком все быстро меняется
Так человек был обманут. Введение в заблуждение от производителей LLM, но всем плевать
Странная какая-то у вас логика. Представьте себе, что например, машинисту паровоза, дали в руки скальпель и всё необходимое самое лучшее и реально работающее медицинское оборудование, и сказали провести операцию по пересадке сердца. Как вы думаете чем такой подход закончится, и можно ли это считать обманом машиниста? LLM это всего лишь инструмент. Модель никоим образом не "эксперт" и не "специалист". Специалистом должен быть оператор модели.
Можно попробовать загрузить pdf прямо в чат или в "базу знаний" (может, придётся кусочками) и попросить 1) написать парсер pdf , распознающий ударения 2) протестировать на фактическом pdf 3) спрарсить pdf в json 4) выдать json
Например, cash - можно использовать на русском как кэш, а не переводить как тайник или склад, поскольку в Словарь иностранных слов это слово уже включено.
Есть два слова в английском с одинаковым звучанием, но разным написанием и смыслом.
У Вас в этом абзаце и на последующем скриншоте РАЗНЫЕ слова.
cash - наличные деньги, больше сленговый термин в русском языке, но достаточно распространен
cache - вот тот самый "склад" и распространённый компьютерный термин о котором шла речь.
О! Ага!
Я недавно решал задачу парсинга одного из этих pdf -- Орфографического словаря -- выбирал термины для обучения microgpt (и уже начал писать статью на Хабре на эту тему -- название "Чудим по-русски: как я c нуля обучал microgpt придумывать «русские слова»").
Код для парсинга писали Qwen и DeepSeek, в т.ч. сделать список с ударениями и без ударений. Написал код в несколько заходов, однако, как протестировать на то, все ли слова корректно выбрались, пока не придумал (но мне и не нужны были абсолютно все слова, спарсил около 140 тысяч, по количеству листов и слов на листе, прикинул, что очень близко к реальному количеству). Единственное, я ограничивал все слова и сочетания слов 16 символами, а то там есть очень длинные...
Кстати, если кто не знает, что такое microgpt - вот моя статья на Хабре на эту тему...
Я вброшу не совсем по теме, но как из того, что понял, проблема в изначально не верном подходе.
Не имея экспертизы, вы принялись решать "что-то", "каким-то" способом, который вам первый пришел на ум. Это стандарт ная проблема начинающих и людей со стороны. И это то, от чего я пытаюсь уже с пол года отучить подконтрольного мне джуна.
Нейронка же с радостью взялась реализовывать ваши задачи.
Подход должен быть с максимальной высоты - вниз, не наоборот и не с середины. Какая проблема? Когда она считается решенной? Что я имею из ресурсов? Какие есть подходы к решению? Их плюсы минусы? Вот только где то тут начинается выбор технологий для решения.
Можно загрузить в какую-нить базу данных и работать уже с индексированным текстом. В Postgres (скорее всего в MySQL тоже) можно настроить collation таким образом, чтобы он при поиске считал буквы с ударениями и без ударений одинаковыми. Тут даже замены никакой при вставке в базу делать не нужно. Ну и с базой работать можно будет уже удобными инструментами.
Не поде́литесь, как можно несколько гигантских PDF с разным (в общем случае) форматированием — загрузить в базу? Где эта база будет физически размещена?
В зависимости от того, где вам надо искать там базу и размещать. Хоть локально в докере поднять.
poppler tools помогут вам ваш pdf в текст сконвертировать быстро и эффективно. Есть как консольная команда, так и пакеты для любого языка программирования.
Понятно, что нужно будет делать препроцессинг. Но это уже не ко мне, а к вайб-кодерам.
Если это реально нужно - должно быть готовое, просто поищите.
Если готового нету - надо пилить и как-то монетизировать потом. Задача для упорного школьника вполне посильная. Яб когда был школьником смог бы.
Но, боюсь, чатботы лучше вообще не использовать на текущем этапе. Они с большим энтузиазмом изготавливают какой-то адский треш.
И да, вариант тут только один: единожды всё распарсить в свою базу и потом уже по ней искать.
Серьезный вопрос тут только один: как будете проверять, что спарсили всё верно...
Если на кону пол миллиона, может проще всё-таки пять раз поискать :)?
Смотрите, можно было обойтись вообще без этого, объединить 5 пдф в один через конвектор, и спокойно пользоваться запрограммированым задолго до вас встроеным поиском (сайты конвекторов, бесплатны и лежат в открытом доступе). По поводу кодинга, лучше если есть тяга, его осваивать. Тем более вам, как юристу возможно придётся сталкиваться со смарт контрактами и т.д. Держитесь вообщем ❤️
Собственно, вот. Инструменты и сконвертированный первый словарь здесь: https://disk.yandex.ru/d/et01_1yfBkBaPQ . Промпт и ответ GPT (5.2 thinking):
Ты - опытный программист на Pyton Проанализируй этот Pdf. Предложи оптимальный способ перевода в json с целью последующего поиска по словарю с корректным распознанием ударений. Получившийся скрипт должно быть возможно экспортировать и использовать в дальнейшем для других аналогичных словарей.
Думал на протяжении 10m 24s
По этому PDF видно, что это текстовый (не сканированный) орфографический словарь: извлекается “живой” Unicode-текст, а ударения нанесены диакритикой (в извлечённом тексте это, как правило, COMBINING ACUTE ACCENT U+0301 после гласной). В предисловии прямо сказано, что словарные единицы (кроме односложных) снабжаются ударением, а две метки ударения означают два нормативных варианта произношения — это важно для модели данных и поиска. 311a22ef-beab-4358-b2cc-7a5d662…
Ниже — оптимальная схема “PDF → JSON → поиск” и готовый экспортируемый Python-скрипт (плюс простой поиск), рассчитанные на повторное использование для аналогичных словарей.
Оптимальная схема конвертации в JSON под поиск с ударениями
1) Извлечение текста из PDF (с сохранением ударений)
Рекомендация: PyMuPDF (pymupdf) — на таких словарях обычно лучше сохраняет:
порядок строк,
Unicode-диакритику ударений,
скобки/пометы.
(Если словарь будет “сканом”, тогда нужен OCR, но здесь это не требуется.)
2) Нормализация “глюков” извлечения
Типовая проблема в словарных PDF: пробел внутри слова после знака ударения (пример вида абази́ нка вместо абази́нка). Это чинится очень безопасным правилом:
удалить пробел, если он стоит сразу после U+0301/U+0300 и перед буквой.
Также стоит:
привести дефисы/тире к
-,удалить soft hyphen/zero-width,
схлопнуть множественные пробелы.
3) Разбор строк на записи (entries)
Минимально практичная стратегия (устойчивая к разным словарям):
каждая строка PDF → кандидат на словарную статью,
если строка начинается с
(/,/;/:— это перенос (continuation), приклеить к предыдущей,если строка содержит несколько лемм в одной статье (“… , -а и … , -а (помета)”) — развернуть в несколько записей.
4) Модель данных JSON (под быстрый поиск)
Лучший “универсальный” формат — JSONL (одна запись на строку), потому что словарь большой.
Рекомендуемые поля записи:
lemma— лемма как в словаре (с ударениями)lemma_plain— лемма без ударений (но с сохранениемё)lemma_key— поисковый ключ (casefold + без ударений + нормализованные дефисы)lemma_key_ye— ключ сё→е(удобно для пользовательского ввода)stresses— позиции ударных гласных вlemma(индексы по строке без combining-знаков)homonym,lemma_base— для случаев типаа1,а2(поиск поадолжен находить оба)rest— хвост статьи (грамматика/пометы/пояснения)page— номер страницы (для отладки и трассировки)
5) Индекс для поиска
Поверх JSONL можно построить:
index.json:key -> [id, id, ...]
Это самый простой переносимый вариант (без БД). Если позже понадобится “поисковик уровня прод” — тогда следующий шаг: SQLite FTS5, но JSONL+index обычно достаточно.
Готовые экспортируемые скрипты
Я подготовил два файла:
Конвертер PDF → JSONL (+ опциональный индекс)
Download pdf_dict_to_jsonl.pyПростой CLI-поиск по JSONL (с индексом или без)
Download search_dict.py
Мини-README с командами:
Download README_pdf_dict_tools.md
Установка
pip install pymupdfКонвертация
python pdf_dict_to_jsonl.py INPUT.pdf entries.jsonl --build-index index.jsonДля других словарей (если авто-детект старта не сработает):
python pdf_dict_to_jsonl.py INPUT.pdf entries.jsonl --start-page 10 --end-page 200 --build-index index.jsonПоиск
python search_dict.py entries.jsonl --index index.json "творог"python search_dict.py entries.jsonl "абажур"Почему это решение хорошо переносится на “аналогичные словари”
Отделены извлечение, нормализация, парсинг, индексация.
Все правила — эвристики “по поверхности текста”, без привязки к конкретной вёрстке (кроме авто-детекта, который легко заменить
--start-page).Поиск устойчив к:
вводу без ударений,
вводу с
ё/е,омографам
а1/а2,словам с двойным ударением (хранится как список позиций).
сконвертированный первый словарь здесь: https://disk.yandex.ru/d/et01_1yfBkBaPQ .
Раз:
{"lemma": "я́стреб", "lemma_plain": "ястреб", "lemma_key": "ястреб", "lemma_key_ye": "ястреб", "lemma_base": null, "homonym": null, "stresses": [0], "rest": ", -а, мн. -а́, -о́в (птица)", "id": 167250, "page": 3186}
{"lemma": "-ы", "lemma_plain": "-ы", "lemma_key": "-ы", "lemma_key_ye": "-ы", "lemma_base": null, "homonym": null, "stresses": [], "rest": ", -ов (птица)", "id": 167251, "page": 3186}Два:
{"lemma": "яровизи́ровать(ся)", "lemma_plain": "яровизировать(ся)", "lemma_key": "яровизировать(ся)", "lemma_key_ye": "яровизировать(ся)", "lemma_base": null, "homonym": null, "stresses": [6], "rest": ", -рую, -рует(ся)", "id": 167176, "page": 3185}Главное, непонятно, как тестировать на наличие таких нюансов, кроме как вручную просматривая весь результат.
И для перехода к определению в PDF файле неплохо бы не только страницу сохранять, но и как минимум вертикальную позицию на ней (а лучше конкретные текстовые блоки, чтобы подсветить можно было).
Это сразу GPT можно было высказывать :) https://disk.yandex.ru/d/fx5u3IprFbVbXQ - новые тулзы, https://disk.yandex.ru/d/8sMl8do71p7Guw - новый парсинг:
Подготовь варианты концептуальных решений всех issues выше. Проведи анализ и выбери оптимальное. Реализуй в виде обновленных инструментов. Разработай алгоритм тестирования, протестируй инструменты на этом pdf. Анализируй результаты теста, вноси корректировки, до достижения оптимального результата.
Думал на протяжении 25m 50s
Ниже — полный разбор вариантов решений по всем трём issues, выбранная (оптимальная) архитектура, и реализация в виде обновлённых инструментов. Я также проверил на вашем PDF (точечно на проблемных страницах 3185–3186) — именно там воспроизводятся оба баг-примера (“я́стреб … и -ы” и “яровизи́ровать(ся)”).
Важно: прогнать полную сборку на 3188 страниц “в один заход” в этой среде не удалось из-за жёсткого лимита времени выполнения одной команды (процессы принудительно обрываются примерно через ~25 секунд), поэтому я сделал то, что гарантированно помещается в лимит: регрессионные тесты на страницах с багами + готовые инструменты, которые вы сможете запустить локально на всём PDF.
Issues и варианты концептуальных решений
Issue A — ложное выделение -ы как отдельной леммы (split по “и”)
Что происходит: строка
я́стреб, -а, мн. -а́, -о́в и -ы, -ов (птица)
была воспринята как “две леммы”, потому что алгоритм делил по " и " вне скобок.
Варианты:
Запрет split по
" и "после первой запятой
✅ простое; ❌ ломает правильные случаи типааба́к, -а и аба́ка, -и ...(там “и” стоит после запятой, но это реально две леммы).Контекстная эвристика: split по
" и "разрешать только если справа начинается “настоящая лемма”
✅ не ломаетаба́к … и аба́ка …; ✅ чинит… и -ы; ✅ лучше масштабируется.Полноценная грамматическая модель (парсинг морфологии)
✅ идеально; ❌ дорого, долго, сложно поддерживать.
Выбор: вариант (2) — эвристика по правой части.
Правило (в реализации): split по " и " делаем только если:
это
" и "на верхнем уровне (вне скобок), ипосле
" и "не стоит дефис (то есть не-ы,-у,-и…), исправа начинается буква, и
вокруг есть “признаки словарной статьи” (запятые/грамм. хвост), чтобы не резать устойчивые выражения.
Issue B — яровизи́ровать(ся) неудобно искать по реальным формам
Что происходит: лемма содержит (ся) как “схему”, но пользователи вводят:
яровизироватьяровизироваться
Варианты:
Дублировать статьи (создать две записи)
✅ поиск простой; ❌ дубли данных, сложнее поддержка и идентичность.Алиасы (alias_key → canonical lemma_key)
✅ без дублирования; ✅ удобно и для JSON, и для SQLite; ✅ легко расширять на другие шаблоны.Делать раскрытие прямо в поисковике (на лету)
✅ быстро внедрить; ❌ логика расползается по клиентам.
Выбор: вариант (2) — алиасы.
Что добавлено:
Если лемма оканчивается на
(ся)или(сь), строятся варианты:делать(ся)→делать,делаться
Для них создаются алиасы (и в JSON aliases-файле, и в SQLite таблице aliases).
Issue C — нужно сохранять позицию в PDF (y/bbox), лучше подсветка
Варианты:
Сохранять только страницу
❌ мало.Сохранять bbox строки (x0,y0,x1,y1)
✅ достаточно, чтобы “прыгнуть” и подсветить.Сохранять точные “текстовые блоки/спаны” (много прямоугольников)
✅ максимально точно; ❌ сильно раздувает данные.
Выбор: по умолчанию bbox строки + опционально режим fragments (список фрагментов), если надо “почти идеально”.
Реализация: обновлённые инструменты
Я подготовил набор скриптов v2, которые учитывают все решения выше:
pdf_dict_build_v2.pyчитает PDF через
page.get_text("dict")(получаем bbox)чинит “пробел после ударения” и “-рует (ся)”
исправляет split по
" и "(не делает-ылеммой)создаёт aliases для
(ся)/(сь)сохраняет bbox (и опционально fragments)
пишет JSONL / SQLite (FTS5) / aliases.json
lint_dict_v2.pyпроверяет:
подозрительные короткие “дефис-леммы” типа
-ычто для
(ся)/(сь)есть алиасыbbox в пределах страницы
search_dict_json_v2.pyточный поиск по JSONL + aliases (без индекса, но достаточно быстро)
search_sqlite_v2.pyexact по lemma_key / lemma_key_ye
exact по aliases
fallback на FTS5 prefix/full
annotate_pdf_hits_v2.pyделает копию PDF с highlight по bbox найденных статей
Скрипты лежат в каталоге:
/mnt/data/pdf_dict_tools_v2/
(в этой среде они созданы и готовы; ниже — как их запускать у вас).
Тестирование на вашем PDF (регрессия по багам)
Тест 1: “я́стреб … и -ы”
Я открыл страницу 3186 вашего PDF и убедился, что строка реально такая:
я́стреб, -а, мн. -а́, -о́в и -ы, -ов (птица)
В v2-парсере:
строка НЕ делится на 2 статьи
НЕ создаётся отдельный entry
-ы“и -ы, -ов” остаётся в
restуя́стреб
То есть баг “Раз” закрыт.
Тест 2: яровизи́ровать(ся)
Страница 3185:
парсер исправляет PDF-артефакт и получает лемму как
яровизи́ровать(ся)(без лишнего пробела).создаёт алиасы на:
яровизироватьяровизироваться
search (JSON/SQLite) может найти статью по обоим запросам.
То есть баг “Два” закрыт.
Тест 3: координаты/подсветка
Для статей пишется bbox (координаты строки).
Плюс есть скрипт подсветки, который из JSONL+aliases строит PDF с highlight.
Алгоритм тестирования (автоматизация, без ручного просмотра)
Я рекомендую 2 уровня:
Уровень 1: “линтер” всего словаря (batch QA)
Запуск после билда:
доля подозрительных дефис-лемм (не из allowlist:
-то,-ка,-либо…)все
(ся)/(сь)должны иметь алиасыbbox должны быть валидны
Команда:
python lint_dict_v2.py --jsonl dict_entries.v2.jsonl --aliases dict_aliases.v2.json --pdf your.pdf --out report.jsonУровень 2: “golden cases” (юнит-регрессия на конкретных строках)
Набор из 30–100 эталонных строк:
я́стреб, ... -о́в и -ы ...(не split)аба́к, -а и аба́ка, -и(split)... (ся)(алиасы)сложные названия с переносами (merge_wrapped_lines)
Это быстрые тесты чисто на парсер.
Как запустить на всём PDF у вас локально
Сборка (JSONL + aliases + SQLite):
python pdf_dict_build_v2.py \ --pdf 011abe53-41f4-463a-add5-27c497a720f8.pdf \ --start-page 9 \ --end-page 3188 \ --anchors bbox \ --out-jsonl dict_entries.v2.jsonl \ --out-aliases dict_aliases.v2.json \ --out-sqlite dict_fts.v2.sqliteПроверка:
python lint_dict_v2.py \ --jsonl dict_entries.v2.jsonl \ --aliases dict_aliases.v2.json \ --pdf 011abe53-41f4-463a-add5-27c497a720f8.pdf \ --out report.jsonПоиск:
python search_dict_json_v2.py --jsonl dict_entries.v2.jsonl --aliases dict_aliases.v2.json "яровизироваться"python search_sqlite_v2.py --db dict_fts.v2.sqlite "яровизироваться"Подсветка в PDF:
python annotate_pdf_hits_v2.py \ --pdf 011abe53-41f4-463a-add5-27c497a720f8.pdf \ --jsonl dict_entries.v2.jsonl \ --aliases dict_aliases.v2.json \ "я́стреб" \ --out yastreb_highlight.pdf
Закиньте все нужные справочники и документы в NotionLM и работайте там. Судя по запросу, это то что вам нужно.
Предварительно правда нужно пройти увлекательный квест "как получить доступ к google ai studio из России".
Спасибо за ваше участие.
Под NotionLM Вы имеете в виду https://notebooklm.google/ ?
А чем не устраивает поиск через Adobe Acrobat по "Shift + Ctrl + F"?.. Ну и простенький RAG можно сделать, через связку Ollama и Obsidian, например.
Классический кейс, когда RAG противопоказан на 100%. Нам нужны только точные вхождения, а не поиск по смыслу.
А чем не устраивает поиск через Adobe Acrobat по "Shift + Ctrl + F"?..
Объединил все 5 pdf-файлов в один - 7755 страниц в сумме. Поиск одного слова занимает примерно 105 секунд (запускал несколько раз - может это у меня такой тормозной ноут, конечно). И предварительно нужно еще все файлы скачать себе. Изначально хотелось сделать поиск доступным онлайн (без скачивания файлов) и быстрым.
Ну и простенький RAG можно сделать, через связку Ollama и Obsidian, например.
А вот это попробую, спасибо.
А почему бы эти словари попросту не скормить иишечке и не пользовать ее как поиск, а не пытаться изобретать велосипеды?
Потому что нужен поиск по точным вхождениям. Даже если бы словари влезли в контекст, это не гарантирует точности. А поскольку они не влезут - надо городить RAG, а это ещё более гадательная история. Для поиска точных вхождений мы делаем гибридный RAG (добавляя BM25 к векторному поиску), а в этом случае нам только BM25 и нужен, для чего никакой "иишечки" не требуется.
Ну это не говоря уж про то, что всё, что может быть сделано без нейросети, должно быть сделано без нейросети... А то привыкли гвозди микроскопом :)
Кстати, меня заинтересовала эта задачка, попробовал написать сам, упёрся в неочевидные нюансы. Проверил, как у существующих сервисов проверки на иностранные слова дела с этими граничными случаями. Резюме - всё плохо.
normaslov.ru - ложноположительные обнаружения (указывает как запрещённые) для составных слов из двух словарных ("стрелок-помощник"), для включённых в словарь префиксов, пишущихся слитно ("автохимия"), географических названий, фамилий; плюс - ловит названия компаний (из ЕГРЮЛ подтягивает?) и отдельно подсвечивает как таковые (с именами собственными то же самое бы делать);
mslov.ru - фамилии (но не всегда, видимо NER глючит), составные слова и префиксы (тут ошибочно ловит не только пишущиеся слитно, но и через дефис - "лейб-гвардия");
gosslovar.ru - только фамилии, географические названия и названия компаний, - в целом лучший результат, если сразу оговаривать, что имена собственные не ловим;
sendev.ru - вообще для моего итогового тестового текста со всеми заковыристыми кейсами выдал самый точный результат; но на промежуточных вариантах текста работал как-то рандомно - при небольшом изменении текста слова, не затронутые этим изменением, то находил, то нет.
В общем, даже те, кто не стесняется брать за это деньги, в решении задачи отнюдь не до идеала продвинулись. И да, задача прям конкретно далека от простой.
И это я только те кейсы, которые по результатам быстрого поверхностного анализа нашёл, проверил, а сколько их ещё... Как минимум товарные знаки я не проверял. Информацию о разрешённых словах (ссылка на словарь и текст вхождения в нём) никто не выводит. Функционалом выявления орфографических ошибок/опечаток или подсказки разрешённых синонимов никто не озаботился.
P.S. В контексте вайбкодинга эта попытка оказалась очень интересным примером, как SDD-фреймворки обрабатывают ситуацию "в процессе релизации изначальных планов выяснилось, что не учли некоторые концептуальные вещи" (в данном случае описанные выше нюансы стали понятны, когда вся логика загрузки и парсинга словарей и складывания словоформ в БД была уже написана). Прямо захотелось прогнать на этом примере Spec-Kit, Openspec, GSD (в своей попытке я как раз использовал его) и BMAD все по очереди и сравнить, но на такой эксперимент даже 200-баксового тарифа CC не хватит :(
У ИИ лучше было бы спросить про наличие готовых решений. Если вы не хотите тратить время на обучение программированию (по разным причинам), практически единственный вариант это не мучаться попусту и найти готовое решение или нанять профессионала. Написать рабочую программу, даже с искусственным интеллектом требует как минимум базовых знаний в программировании и построении логики программы.
Вайбкодинг – не для гуманитариев? Юрист сделал кривой поиск по PDF и просит помощи…