Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

NP чанкер и прототип шаблонизатора ответов для чатбота

В наборе NLP модулей для чатбота добавился очередной - NP chunker. Его прототип я уже кратко описывал тут. Для удобства использования в разных проектах чанкер именных групп выделен в отдельный модуль ruchunker.

В чатботе он позволяет делать следующее. Допустим, пользователь вводит вопрос:
Collapse )

Профили в чатботе

В новом релизе чатбота я добавил "профили" - текстовые файлы (json), в которых указываются пути к файлам с фактами и правилами. С их помощью, думаю, будет проще создавать разные "характеры". В этих же профилях в будущем будут доступны тонкие настройки характера бота (ну не прямо как тут, конечно, хотя...). Сейчас сделан базовый отладочный профиль, который позволяет чатботу отвечать на десяток простых вопросов о самом себе, примерно так:
Collapse )

Генеративная грамматика для проактивного чатбота

Для реплики собеседника генеративная грамматика создает целый набор вопросов и просто реплик. В некоторых случаях одна только N-граммная языковая модель позволяет неплохо отсеять откровенную бессмыслицу и оставить более-менее разумные фразы:
Collapse )

Старина DLL hell вернулся

Он вернулся и поселился в экосистеме питона, где под него даже запилили костыледержалку virtualenv.
Особенно часто я встречаю его при работе с tensorflow и вообще ML. Вот давеча прочесывал SO "Why my tensorflow-gpu runs only on cpu?".

Тест на многопоточность для поисковых команд

В SDK поисковой системы добавил тест на многопоточность для поиска в текстовых файлах без использования индекса.

Запускаются несколько (проверялось до 10) потоков, каждый из которых выполняет поиск заданных ключевых слов в наборе текстовых файлов в одном и том же каталоге.

Важный момент - все ядра процессора при этом загружаются по максимуму, то есть, допустим, на 2-х ядерном CPU получаем полную загрузку обоих ядер. Это косвенно подтверждает, что в поисковом движке скорее всего нет участков, вызывающих сериализацию команд. Архитектура там изначально разработана для обслуживания многих потоков параллельно без взаимной блокировки, но подтвердить это тестом не лишне.

В API внесено еще несколько изменений, все они войдут в ближайшее обновление.

Пересчет частотной иноформации для русского лексикона

Текстовый корпус - 62 тысячи plain text файлов в кодировке utf-8, общим объемом ~22 Гб.

Частотная обработка 64-битной программой Empirika на Windowns Vista заняла 14200 секунд, то есть примерно 1.5 миллиона байт в секунду. Пиковое потребление памяти - около 1 Гб. Любопытно, что максимальная тепловая нагрузка на процессор, судя по логу термодатчика, пришлась на финальный этап сортировки 5 миллионов лексем.

Общий результат - текущий лексикон покрыл примерно 96% слов в этом корпусе.

Ленивая загрузка словарных статей

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

В текущей версии такой режим активирован только в утилите Lexicon. Если запустить ее, войти в режим морфологического анализа (выбрать [1] в первом меню), то можно заметить, что поиск каждого вводимого слова вызывает как обращение к диску, так и рост потребляемой памяти. Но если ввести уже обработанное ранее слово - реакция программы будет мгновенной, так как соответствующая словарная статья уже подгружена в кэш.

Режим отложенной загрузки словарных статей хорошо вписывается в интерактивный режим, когда скорость обработки не столь важна. В порядке эксперимента данных режим будет включен в поисковых утилитах - консольной, оконной и в dll поискового движка. На скорость индексирования и поиска это не окажет никакого влияния, так соответствующий модуль (лемматизатор) подгружается в память сразу в любом режиме.