Здравствуйте уважаемые читатели.
Рад сообщить, что открылся новый новостной канал содержащий тренды и тенденции в развитии современных технологий (страничка канала и ее версия в формате atom).
Архитектура самой системы бесхитростная и основывается на сервисах Google Reader & rss4me поэтому не буду вдаваться в нудные детали. Главную идею можно передать одной картинкой.
Здесь (слева на право) поступает множество новостей из различных источников. Далее они фильтруются в rss4me но некоторые поступают в Google reader как не фильтрованные. В последнем, каждому сообщению присваивается соответствующая метка и мы получаем результирующий канал.
Знания, не рожденные опытом - матерью всякой достоверности - бесплодны и полны ошибок.
(с) Леонардо да Винчи
Мозг и когнитивные функции
понедельник, 6 сентября 2010 г.
понедельник, 30 августа 2010 г.
Рекомендационная система, финальный раунд (R.I.P.)
Как я писал ранее "Индивидуальность и рекомендации", раунд 3, раунд 2, раунд 1, медленно и верно (стараниями всех заинтересованных лиц) мы пришли к сабжу проекта.
В начале, когда только начинались активности в этом направлении, мы много говорили о том какими должны быть идеальные рекомендации и о том, что коллаборативная фильтрация и методы оценки её эффективности не есть мера "идеальности" хорошей рекомендательной машины.
Поясню на примере.
У нас есть набор образцов: A, B, C, D, E, F.
Пользователю предлагались для оценки образцы A, D, F и он их оценил соответственно на 2, 3, 5. Мерой "идеальности" считается ответ от рекомендационной машины F=5 если ей скормить A=2 и D=3. Если ответ будет F=3 - это плохая машина. Однако, если ответом будет В=5 и C=5 - это мерой "идеальности" тоже оценивается как плохой ответ! Хотя никому не известно, какие бы оценки выставил пользователь для элементов B и C, по той простой причине, что ему эти элементы даже и не предлагали оценить :)
Так же получилось и в моем случае. На старте проекта, много разговаривая про "тривиальные" рекомендации и прочее я спрашивал у заказчика - вам нужен очередной алгоритм коллаборативной фильтрации (коих как грязи и в open source и в википедии) или ...? Ответ был однозначный - нужно ИЛИ!
Так и появилась система ОРАКУЛ. Которую, однако, оценивали методом идеальности с коллаборативной фильтрацией. В результате, то самое свойство системы "ИЛИ" сыграло злую шутку и результаты выдачи корректировались этой "ИЛИ" составляющей. Данное поведение отлично видно на диаграмме.
С первого по 50 запросы ОРАКУЛ показывал "холодный старт", в то время как коллаборативная фильтрация (фиолетовый график) накапливала статистику. Затем, с 50 по 90 запросы поведение систем идентично. После 90 запроса включилась "ИЛИ" составляющая и ОРАКУЛ начал портить результаты "идеального ответа". Т.е. попросту показывать вместо F=5, B и C.
Из чего, при "правильной" интерпретации, были сделаны соответствующие выводы не в пользу ОРАКУЛ. А нужно было, оказывается, убрать а не добавить (как просили) эту "ИЛИ" составляющую, что бы пройти сравнительное тестирование! :)
Итого, финал - ОРАКУЛ похоронен.
Благодарю всех кто следил за этой историей и принимал в ней участие.
Появилась возможность вернуться к любимому ПИПС'у.
В начале, когда только начинались активности в этом направлении, мы много говорили о том какими должны быть идеальные рекомендации и о том, что коллаборативная фильтрация и методы оценки её эффективности не есть мера "идеальности" хорошей рекомендательной машины.
Поясню на примере.
У нас есть набор образцов: A, B, C, D, E, F.
Пользователю предлагались для оценки образцы A, D, F и он их оценил соответственно на 2, 3, 5. Мерой "идеальности" считается ответ от рекомендационной машины F=5 если ей скормить A=2 и D=3. Если ответ будет F=3 - это плохая машина. Однако, если ответом будет В=5 и C=5 - это мерой "идеальности" тоже оценивается как плохой ответ! Хотя никому не известно, какие бы оценки выставил пользователь для элементов B и C, по той простой причине, что ему эти элементы даже и не предлагали оценить :)
Так же получилось и в моем случае. На старте проекта, много разговаривая про "тривиальные" рекомендации и прочее я спрашивал у заказчика - вам нужен очередной алгоритм коллаборативной фильтрации (коих как грязи и в open source и в википедии) или ...? Ответ был однозначный - нужно ИЛИ!
Так и появилась система ОРАКУЛ. Которую, однако, оценивали методом идеальности с коллаборативной фильтрацией. В результате, то самое свойство системы "ИЛИ" сыграло злую шутку и результаты выдачи корректировались этой "ИЛИ" составляющей. Данное поведение отлично видно на диаграмме.
![]() |
| From ПИПС |
С первого по 50 запросы ОРАКУЛ показывал "холодный старт", в то время как коллаборативная фильтрация (фиолетовый график) накапливала статистику. Затем, с 50 по 90 запросы поведение систем идентично. После 90 запроса включилась "ИЛИ" составляющая и ОРАКУЛ начал портить результаты "идеального ответа". Т.е. попросту показывать вместо F=5, B и C.
Из чего, при "правильной" интерпретации, были сделаны соответствующие выводы не в пользу ОРАКУЛ. А нужно было, оказывается, убрать а не добавить (как просили) эту "ИЛИ" составляющую, что бы пройти сравнительное тестирование! :)
Итого, финал - ОРАКУЛ похоронен.
Благодарю всех кто следил за этой историей и принимал в ней участие.
Появилась возможность вернуться к любимому ПИПС'у.
воскресенье, 1 августа 2010 г.
Словотворчество
С развитием мозга у ребенка обновляется словарный запас и в значительной мере изменяется процесс словотворчества. Из собственных наблюдений (в порядке убывания возраста):
# Канял Бубля - Тарас Бульба
# миссис поптень - Мэри Попенс
# разброненосить - защекотать
# крот взошел - вылез из норы
# белакрысая - белобрысая
# авосики - волосы
# мухарат - мошки (комары)
# ка - кошка, собака, ...
# дить - ребенок (постарше, который уже умеет ходить)
# буп - ребенок (обиженный)
# бактись! - победный кличь
# сесек - ребенок
# кутя пысь - самоидентификаци (я)
# Канял Бубля - Тарас Бульба
# миссис поптень - Мэри Попенс
# разброненосить - защекотать
# крот взошел - вылез из норы
# белакрысая - белобрысая
# авосики - волосы
# мухарат - мошки (комары)
# ка - кошка, собака, ...
# дить - ребенок (постарше, который уже умеет ходить)
# буп - ребенок (обиженный)
# бактись! - победный кличь
# сесек - ребенок
# кутя пысь - самоидентификаци (я)
среда, 16 июня 2010 г.
Мысли вслух

Некоторое время назад, мне приходилось заниматься архитектурной деятельность...
Причем, не опосредовано, как менеджер или исполнитель, а именно как системный архитектор/лидер группы/технический директор/играющий тренер. Не скажу, что это было что-то новое, это приходилось делать много и много раз до того. НО! тот раз был особый. И дело даже не в сложности задачи и не в фантастических и противоречивых бизнес требованиях, нет. Дело в обстановке, в которой приходилось это выполнять.
Вообще, системная архитектура - это всегда компромисс. Существует множество способов реализации и множество архитектурных решений поставленных бизнесом задач. Каждый способ имеет свои достоинства и недостатки. Сложность работы архитектора заключается в том, что бы правильно расставить весовые коэффициенты этим достоинствам и недостаткам. Иногда, мало значительный (для других) фактор архитектор оценивает как критический и делает выбор в пользу не популярного "в массах" решения. Однако, мало сделать выбор, необходимо еще за него и отвечать. Здесь степень ответственности такая же как у бизнеса. А допущенная архитектурная ошибка, и не правильно сделанный выбор (не верно расставлены веса) обязательно проявится потом. В виде невозможности расширения системы (из-за архитектурных ограничений) или выльется в большие затраты при переделке. Причем, чем раньше такие ошибки проявятся, тем они более дёшевы в исправлении. Отчасти, выявлению таких ошибок способствуют тестеры. Но что бы выявить такие ошибки тестеры должны быть ооочень профессиональными и иметь за плечами несколько таких самостоятельно построенных систем. Иначе, вероятность обнаружения архитектурных ошибок не высока, а количество "возможных проблем" поглотит даже здравый смысл (+ истерия).
Дак, что же делать, если такая ошибка, все же, была допущена? Именно случилась, а не искусственно создана. Что делать, если такая архитектурная ошибка была допущена и проявилась? Мое личное мнение - гнать такого "архитектора". В больших системах, стоимость допущенной ошибки соизмерима с ошибкой сапера на минном поле. Хотя, конечную стоимость ошибки определяет бизнес, но архитектор не имеет права на ошибку (так же как не имеет такого права директор). Однако, я встречал человека, который именовал себя по всякому и старался быть в каждой "дырке пробкой". Он, в частности, практиковал 2-ва принципа (думаю и сейчас практикует, такое не лечится): "лучше перебдеть, чем недобдеть" и "не бывает единственно правильного решения, и вы правы и вы правы". Для меня он стал примером абсолютной некомпетентности при колоссальной работоспособности. Никогда, а тем более в архитектуре сложных систем, не занимайте позицию "ни вашим ни нашим" или "и тем и другим". Правильная архитектура - это смесь пограничных решений, за которые и отвечает архитектор! Кстати, для того человека, стоимость его ошибки так и не была им воспринята адекватно (его просто выгнали из компании которую он же и основал).
К чему я расписываю такие банальности? Нет в этом ничего нового и необычного - факт. Необычной, для меня, была обстановка в которой приходилось заниматься своей профессиональной деятельностью. Дизайнить большую систему когда тебя подставляют, БЕЗ требований и в окружении блатных бездарей (пытающихся навязать вам который из протоколов или технологий следует использовать) - это сущая ерунда, если у вас есть вербальный канал получения информации от заказчика (бизнеса). Когда вы можете напрямую задать вопрос и получить на него ответ. А когда в голове уже сложилась мозаика того "что же хочет бизнес", остается рутина. Остается просто расписать это (если надо в сценариях, если надо в UML, если надо в коде). Но, когда ... лишают вас единственного (хоть и вербального) канала получения информации и "мозаика не сложена" - вы будете вынуждены изобретать абсолютно круглого коня в вакууме.
Конечно каждая ситуация уникальна и существует множество интерпретаций фактов (как и самих интерпретаторов), однако я пишу эти "мысли вслух" не для оправданий чьих-то действий и не для мотивации увольнения профессионалов, но покровительства дилетантов. Нет, единственная цель - это поделиться прошлым опытом и предостеречь вас от "слепого профессионализма" и недооценки "политического" фактора в вашей деятельности.
P.S.
Любые совпадения с реальными людьми, компаниями и проектами случайны и не имеют ничего общего с реальностью.
Подписаться на:
Сообщения (Atom)

