Чтобы понять сложность задачи, нужно вспомнить, что товарные предложения в разных магазинах описываются очень по-разному — где полно, где-то одной фразой.
Основной мотив — не тратить много времени на стадии прототипа. На этой стадии ведь главное идею проверить; подправить (возможно кардинально) реализацию, если что; инвестору показать «крутящиеся шестеренки», обеспечивающие прохождение всего сценария от начала до конца.
А вот когда случится переход от этой стадии к другой, тут мы сядем и, видимо, напишем заново эту часть с учетом полученного опыта. Ну и скорее всего это будет делаться уже на деньги найденного инвестора и под понятные коммерческие перспективы.
Да, думали. Но скорее как дополнение к «ручному» описанию, нежели его полной замене.
Например, после обработки большого статистически значимого объема информации можно будет автоматом делать вывод о наличии определённых, но еще не прописанных в описании, связей между существующими понятиями предметной области.
Да, вручную. Аналитик садится и фиксирует описание области на разработанном для Beegoo языке.
Затем интерпретатор использует это описание при индексировании товарных предложений и парсинге запроса пользователя.
Отвечу здесь сразу на все комментарии, описывающие проблему неадекватности некоторой части результатов запросов.
Проблема есть. У нас разработан некоторый язык описания знаний предметной области и движок, интерпретирующий страницы и запросы в соответствии с этим описанием. Вопрос улучшения качества поиска напрямую связан с развитием самого языка и описания. Все найденные «выбросы» поиска мы обязательно анализируем после каждого сканирования магазинов и процесс постепенного улучшения описания и движка не останавливается. Правда, иногда не так быстро как хотелось бы в связи с тем, что мы находимся в условиях стартапа и сталкиваемся с постоянным дефицитом ресурсов.
Данные по предложениям товаров хранятся преимущественно в файлах. Для индексов и некоторых данных сайчас используется PostgreSQL. Есть планы миграции в БД типа «ключ-значение», вроде redis. Займемся переходом, когда нагрузка вырастет до «промышленных» значений. Пока что текущей архитектуры хватает.
Запросы пользователей сейчас в конечном счете преобразуются в SQL, который выполняется над PostgreSQL.
Отвечу на этот комментарий и заодно на еще один чуть выше от Alexx_ps
Отличие Beegoo.ru от Яндекс.Маркет не в умении систематизировать информацию и организовывать релевантный поиск (по этому критерию Яндекс имеет существенную фору перед нами). Основное отличие — это в подходе формирования информационной базы.
В Яндекс.Маркет попадают предложения только от тех интернет-магазинов, которые готовы платить за переходы. Если продавец не заплатил — в Яндекс.Маркет он не попал.
Beegoo.ru сканирует те магазины, которые интересны с точки зрения контента. То есть при наборе объема информационной базы нет такого входного порога — как согласие от продавца платить. Мы сами выбираем магазины и сканируем их «полки».
То есть мы претендуем на то, что у нас в итоге должна получиться более интересная для покупателя база.
Тут, наверное, уместен такой гипотетический пример. Представьте себе, если бы в Google попадали страницы только тех сайтов, которые бы платили Google. Какой бы поисковик мы с вами имели? И захотели бы мы пользоваться этим инструментом?
В статье, действительно, забыл об этом сказать. На первых порах мы сознательно заузили аудиторию географией. Это было сделано вот для чего:
— чтобы иметь возможность не очень болезненно для аудитории круто что-то менять. При больших аудиториях велик риск потерь части этой аудитории при таких изменениях
— Нам на первых этапах развития проекта нужно установить как можно более теплые отношения с интернете магазинами. Понять чем они дышат, каковы рекламные бюджеты и вообще что они думают про нашу идею, сервис, бизнес модель и т.д. Этот обмен информацией чаще всего происходит при личных встречах. Так как мы сами живем в Екатеринбурге, то на первых порах дешевле работать с местными магазинами.
Ну а расширение — это наши ближайшие планы. Параллельно с наращиванием товарных ниш проводить географическую экспансию.
Странный опрос. Он подразумевает, что основной мотив у программиста — это ЗП. Все успешные команды, которые я видел были мотивированы далеко не ЗП. У программиста работа творческая, и ее хорошо выполняют люди, которые в первую очередь стремятся творчески самореализоваться.
Если рассматривать задачку построения бизнес процессов, то важно отличать то, что можно менять в этих процессах, а что должно быть неизменно. Чаще всего то, что менять нельзя — это некий «результат» работы, который поступит на вход другим.
В примере с яичницой — важно получить яицницу. Она является результатом работы. Это условие задачи и его поменять нельзя. А как уж ее получить — процесс творческий. И этот процесс можно менять, выбирая оптимальную комбинацию ресурсов, времени и прочих характеристик. Как вариант — можно ее вообще не готовить, а покупать в соседнем магазине.
К чему я это? При автоматизации чаще всего на предприятии старые процессы демонтируют и строят новые, либо существенно модернизируют существующие бизнес процессы. То есть в подавляющем большинстве случаев перед сотрудниками стоит задача подумать: «А как перестроить существующую работу с использованием внедряемой программы, чтобы 'яичница' все также готовилась, и при этом процесс стал более оптимальным?» И начинать эту работу правильнее и понятнее с поиска тех самых яичниц в своей работе. То есть того, что является результатом, которого ждут соседние сотрудники (отделы, предприятия, и т.д.) или конечный клиент. Осознав эти «яичницы» сотрудникам, по-моему, станет понятнее что делать дальше.
С тем, чтобы последовательности выбранных в пользовательском интерфейсе подсказок всегда приводили к ненулевому результату, сейчас боремся.
Я отвечу на другой вопрос: «Какой запрос пользователя может обработать Beegoo.ru, так чтобы продемонстрировать свои конкурентные преимущества?»
Ответ: например, этот Игрушка из дерева возраст от 1 до 2 лет от 300 до 500 рублей
Чтобы понять сложность задачи, нужно вспомнить, что товарные предложения в разных магазинах описываются очень по-разному — где полно, где-то одной фразой.
А вот когда случится переход от этой стадии к другой, тут мы сядем и, видимо, напишем заново эту часть с учетом полученного опыта. Ну и скорее всего это будет делаться уже на деньги найденного инвестора и под понятные коммерческие перспективы.
Например, после обработки большого статистически значимого объема информации можно будет автоматом делать вывод о наличии определённых, но еще не прописанных в описании, связей между существующими понятиями предметной области.
Затем интерпретатор использует это описание при индексировании товарных предложений и парсинге запроса пользователя.
Проблема есть. У нас разработан некоторый язык описания знаний предметной области и движок, интерпретирующий страницы и запросы в соответствии с этим описанием. Вопрос улучшения качества поиска напрямую связан с развитием самого языка и описания. Все найденные «выбросы» поиска мы обязательно анализируем после каждого сканирования магазинов и процесс постепенного улучшения описания и движка не останавливается. Правда, иногда не так быстро как хотелось бы в связи с тем, что мы находимся в условиях стартапа и сталкиваемся с постоянным дефицитом ресурсов.
Спасибо!
Запросы пользователей сейчас в конечном счете преобразуются в SQL, который выполняется над PostgreSQL.
Отличие Beegoo.ru от Яндекс.Маркет не в умении систематизировать информацию и организовывать релевантный поиск (по этому критерию Яндекс имеет существенную фору перед нами). Основное отличие — это в подходе формирования информационной базы.
В Яндекс.Маркет попадают предложения только от тех интернет-магазинов, которые готовы платить за переходы. Если продавец не заплатил — в Яндекс.Маркет он не попал.
Beegoo.ru сканирует те магазины, которые интересны с точки зрения контента. То есть при наборе объема информационной базы нет такого входного порога — как согласие от продавца платить. Мы сами выбираем магазины и сканируем их «полки».
То есть мы претендуем на то, что у нас в итоге должна получиться более интересная для покупателя база.
Тут, наверное, уместен такой гипотетический пример. Представьте себе, если бы в Google попадали страницы только тех сайтов, которые бы платили Google. Какой бы поисковик мы с вами имели? И захотели бы мы пользоваться этим инструментом?
По логам сегодняшнего дня попытаемся диагностировать проблему и полечить.
Спасибо!
В статье, действительно, забыл об этом сказать. На первых порах мы сознательно заузили аудиторию географией. Это было сделано вот для чего:
— чтобы иметь возможность не очень болезненно для аудитории круто что-то менять. При больших аудиториях велик риск потерь части этой аудитории при таких изменениях
— Нам на первых этапах развития проекта нужно установить как можно более теплые отношения с интернете магазинами. Понять чем они дышат, каковы рекламные бюджеты и вообще что они думают про нашу идею, сервис, бизнес модель и т.д. Этот обмен информацией чаще всего происходит при личных встречах. Так как мы сами живем в Екатеринбурге, то на первых порах дешевле работать с местными магазинами.
Ну а расширение — это наши ближайшие планы. Параллельно с наращиванием товарных ниш проводить географическую экспансию.
В примере с яичницой — важно получить яицницу. Она является результатом работы. Это условие задачи и его поменять нельзя. А как уж ее получить — процесс творческий. И этот процесс можно менять, выбирая оптимальную комбинацию ресурсов, времени и прочих характеристик. Как вариант — можно ее вообще не готовить, а покупать в соседнем магазине.
К чему я это? При автоматизации чаще всего на предприятии старые процессы демонтируют и строят новые, либо существенно модернизируют существующие бизнес процессы. То есть в подавляющем большинстве случаев перед сотрудниками стоит задача подумать: «А как перестроить существующую работу с использованием внедряемой программы, чтобы 'яичница' все также готовилась, и при этом процесс стал более оптимальным?» И начинать эту работу правильнее и понятнее с поиска тех самых яичниц в своей работе. То есть того, что является результатом, которого ждут соседние сотрудники (отделы, предприятия, и т.д.) или конечный клиент. Осознав эти «яичницы» сотрудникам, по-моему, станет понятнее что делать дальше.