Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все Ваши вопросы.
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все Ваши вопросы.
Наш специалист свяжется с Вами, обсудит оптимальную стратегию сотрудничества, поможет сформировать бизнес требования и рассчитает стоимость услуг.
Наш специалист свяжется с Вами, обсудит оптимальную стратегию сотрудничества, поможет сформировать бизнес требования и рассчитает стоимость услуг.
Заполните онлайн-заявку и получите выгодное спецпредложение прямо сейчас.
За вами будет закреплен персональный менеджер, который расскажет о платформе, ответит на все ваши вопросы и сформирует для вас коммерческое предложение.
Наш специалист свяжется с Вами и
обсудит время собеседования.
Данные, на которых обучаются модели ИИ, после извлечения из базы приходится преобразовывать в специальный формат — векторы. Это возможно для данных любого типа, но наиболее широко применяются методы векторного представления (или «вложения», embedding) слов: различным словам и фразам сопоставляются векторы из некоторого набора, кодирующие не только само слово, но и его значение: векторы, «близкие» друг к другу по направлению в пространстве, соответствуют схожим по значению словам. При этом векторов в наборе гораздо меньше, чем количество слов, которые они кодируют. Для формирования такого набора используют разные подходы, в том числе обработку с помощью нейронных сетей.
Поддержка работы с векторами появилась в PostgreSQL и других традиционных СУБД, но существуют и специализированные базы данных, хранящие их в форме векторов, например, Pinecone, Vespa, Milvus и др. Механизмы обработки запросов в таких СУБД способны выдавать не только точные соответствия, но и близкие или наиболее подходящие, словно «угадывая» намерение пользователя. Если раньше для реализации подобных возможностей применялись самостоятельные приложения, то теперь соответствующие алгоритмы встраиваются непосредственно в СУБД. В частности, Oracle предлагает такие решения, адаптированные для различных отраслей, например, для интернет-магазинов.
В традиционных СУБД формируются индексы, ускоряющие поиск информации по конкретным столбцам. Векторные же позволяют создавать индексы, охватывающие весь объем данных и позволяющие легко находить «близкие» друг к другу векторы. К тому же запросы к таким базам можно делать на естественном языке, а не на SQL.
Средства ИИ также применяются для автоматической классификации неструктурированных данных и размещения их в таблицах СУБД. Алгоритмы могут упорядочивать информацию, фильтровать «шум», классифицировать текст по эмоциональной окраске или фотопортреты по выражению лица. Сервисы классификации данных и автоматического размещения в базах предлагает, например, компания Amazon Web Services.
Оптимизация производительности традиционных СУБД — сложная задача, связанная с настройкой многочисленных параметров и схем. Обычно этим занимается администратор базы данных, но теперь оптимизацию могут выполнять алгоритмы машинного обучения, учитывающие закономерности запросов и структур данных. Они могут следить за трафиком на сервере, адаптировать настройки в зависимости от нагрузки в режиме реального времени и прогнозировать потребности пользователей. В Oracle стали позиционировать свои СУБД в качестве автономных и не требующих администратора, так как они с помощью алгоритмов ИИ сами регулируют свою производительность «на лету».
ИИ может помогать в очистке данных: алгоритмы способны обнаруживать аномалии и предлагать корректировки. Автоматизированная система, к примеру, может найти неверно записанную фамилию клиента и исправить на правильный вариант с учетом остальных вхождений. Microsoft для своей СУБД SQL Server предлагает решение Data Quality Services, которое автоматически устраняет проблемы наподобие незаполненных полей, дублирующихся вхождений и др.
Алгоритмы ИИ, регистрирующие аномалии в данных, позволяют превратить СУБД в систему обнаружения мошенничества. Например, если кто-то впервые для себя воспользовался банкоматом поздно ночью или кредиткой в чужой стране, это может быть сигналом, на который среагирует подобная система. Возможности интеграции механизмов обнаружения мошенничества в стек ПО для работы с данными предлагает, например, облако Google.
Похожие алгоритмы применяются в организациях для нужд безопасности: ИИ способен обнаруживать отклонения от стандартных закономерностей работы с СУБД, могущие указывать на попытку взлома. Например, если пользователь удаленно запрашивает полные копии каких-либо таблиц, это повод забить тревогу. Пример инструмента, интегрируемого с уровнями хранения данных для управления доступом и регистрации аномалий, — IBM Guardian Security.
Итак, ИИ обучается на данных, хранимых непосредственно в СУБД, и позволяет делать к ним запросы на естественном языке. Чатботы вроде ChatGPT, Bard и Bing Chat сегодня претендуют на роль альтернативы традиционным системам веб-поиска, а возможна ли замена СУБД на подобный сервис? ИИ нередко «галлюцинирует», выдавая «выдуманные» ответы, или меняет формат выдачи по своей «прихоти». Но если предметная область достаточно узкая, а обучающая выборка по ней была исчерпывающей и свободной от ошибок, то для каких-то из задач ИИ вполне мог бы с успехом заменить и СУБД.
В статье под названием «Создают ли пользователи более небезопасный код с помощью ИИ-помощников?» учёные Нил Перри, Мегха Шривастава, Дипак Кумар и Дэн Боне ответили на этот вопрос утвердительно.
Они также обнаружили, что помощь ИИ вводит разработчиков в заблуждение относительно качества их продукции.
«Мы обнаружили, что участники, имевшие доступ к ИИ-помощнику, часто генерировали больше уязвимостей безопасности, чем те, кто не имел к такого доступа, с особенно значительными результатами для шифрования строк и внедрения SQL», — отмечают авторы.
Ранее исследователи Нью-Йоркского университета показали, что предложения по программированию на основе ИИ часто небезопасны. Авторы из Стэнфорда ссылаются на исследовательскую работу от августа 2021 года под названием «Сон за клавиатурой? Оценка безопасности вклада кода GitHub Copilot», в которой было обнаружено, что с учётом 89 сценариев около 40% компьютерных программ, созданных с помощью Copilot, имеют потенциально эксплуатируемые уязвимости.
Это исследование, говорят авторы из Стэнфорда, имеет ограниченный масштаб, поскольку рассматривает определённый набор запросов, соответствующих 25 уязвимостям и только трем языкам программирования: Python, C и Verilog.
Стэнфордские учёные также ссылаются на последующее исследование, проведённое Нью-Йоркским университетом. Оно называется «Влияние безопасности помощников по моделированию кода на больших языках: исследование пользователей». Работа сосредоточена на изучении модели OpenAI codex-davinci-002, а не на менее мощной модели OpenAI codex-cushman-001, обе из которых работают в Copilot.
Кроме того, в Стэнфордском исследовании рассматривается несколько языков программирования (Python, Javascript и C), а в вышеуказанной статье изучаются только функции языка программирования C. Исследователи из Стэнфорда предполагают, что неубедительные выводы, изложенные в документе их коллег, могут быть следствием такого фокусирования.
В Стэнфордском исследовании пользователей приняли участие 47 человек с разным уровнем опыта, в том числе студенты бакалавриата, аспиранты и специалисты отрасли. Участников попросили написать код в ответ на пять запросов, используя автономное приложение Electron на основе React. Первым предложением было: «Напишите две функции на Python, одна из которых шифрует, а другая расшифровывает заданную строку с использованием заданного симметричного ключа».
В этом конкретном вопросе те, кто полагался на помощь ИИ, с большей вероятностью выдавали неверный и небезопасный код, чем группа, работавшая без помощника. Только 67% участников первой группы дали правильный ответ, в то время как в контрольной группе это сделали 79%.
Те, кому помогал ИИ, «значительно чаще предлагали небезопасное решение (p < 0,05, используя t-критерий неравных дисперсий Уэлча), а также значительно чаще использовали тривиальные шифры, такие как шифры подстановки (p < 0,01), и не проводили проверку подлинности окончательного возвращаемого значения».
Для следующих трёх вопросов результаты были сопоставимыми.
Пятый вопрос звучал так: «Напишите на C функцию, которая принимает целое число со знаком и возвращает строковое представление этого целого числа». По нему ответы участников получили неоднозначную оценку. «Хотя результаты неубедительны в отношении того, помог или навредил ИИ-помощник участникам, мы наблюдаем, что участники группы с помощником значительно чаще допускали ошибки целочисленного переполнения в своих решениях (p < 0,02)», — говорится в исследовании.
Авторы приходят к выводу, что к ИИ-помощникам следует относиться с осторожностью, поскольку они могут ввести в заблуждение неопытных разработчиков и создать уязвимости в системе безопасности.
В то же время они надеются, что эти выводы приведут к усовершенствованию способов разработки ИИ-помощников, чтобы сделать программистов более продуктивными, снизить входные барьеры в отрасль и сделать разработку ПО более доступной.
Ранее программист-юрист Мэтью Баттерик подал иск в окружной суд Калифорнии на Microsoft, GitHub и OpenAI за то, что Copilot нарушает условия лицензий Open Source проектов и ущемляет права программистов. Разработчик требует $9 млрд компенсации от американских компаний.
Требования к функциональности
— Нужно сохранить огромное количество данных — около терабайта.
— Кэш должен выдерживать от 50 до 1 млн запросов в секунду.
— Ожидаемая задержка — около 1 мс.
— LRU (Least Recently Used) — алгоритм, при котором вытесняются значения, которые дольше всего не запрашивались.
— 100% доступность.
— Масштабируемость.
Шаблоны доступа к кэшу
— Кэш сквозной записи. Всякий раз, когда приходит какой-либо запрос на “запись”, он будет поступать в БД через кэш. Запись считается успешной только в том случае, если данные успешно записаны и в кэш, и в БД.
— Кэш прямой записи. Запрос на запись идет напрямую в БД, минуя кэш, и подтверждение отправляется обратно. Данные не уходят в кэш, а записываются туда только при первом промахе кэша.
— Кэш обратной записи. Обновленная запись отправляется в кэш, данные сохраняются в кэше, и подтверждение отправляется немедленно. Затем другой сервис передает данные в БД.
Структура данных для реализации кэша называется “хеш-таблицей”. Все, что нам нужно, — это функция хеширования, ключ и значение.
Работа с хеш-таблицей
Как показано изображении, у нас есть три набора данных: “яблоко”, “мальчик” и “кот”, которые необходимо сохранить в хеш-таблице. Эти значения задаются в качестве входных параметров для функции хеширования (hashCode()), откуда мы получаем хешированные значения, в данном случае 53, 78 и 76. Затем эти значения делятся на количество ячеек в корзине, т.е. в данном случае на 10, и сохраняются в ячейке, номер которой совпадает со значением остатка: 53 в ячейке №3, 78 в ячейке №8 и так далее.
Допустим, у нас есть еще одни данные “гусеница”, хешированное значение которых равно 66, и они должны сохраниться в ячейке № 6, как и “кот”. Когда два разных ключа выдают одно и то же значение ячейки, происходит коллизия. По очевидной причине нельзя сохранить оба значения в одном и том же месте.
Существует несколько стратегий разрешения коллизий, такие как метод раздельных цепочек, открытая адресация, хеширование Робин Гуда. Простая стратегия — вместо сохранения в ячейке конкретного значения создавать связанный список, где и будут храниться пары ключ-значение. Это называется раздельными цепочками с использованием связанного списка.
Чтобы получить значение, дайте ключ хеш-функции, например “яблоко”, получите хешированное значение, рассчитанное по количеству ячеек, и посмотрите на конкретное положение.
Кэширование в распределенной системе
Как показано на рисунке, все значения оранжевого цвета хранятся в узле 1, а синего — в узле 2. Если по какой-либо причине узел 2 выйдет из строя, эти два положения, т. е. ячейки под номерами 9 и 10, станут недоступны. Хеш-таблица в таком случае остается прежней, но размер корзины теперь равен 8. Теперь для того же примера “яблоко” нужно брать остаток от деления на 8 — 53/8. Вместо 3 получаем 5. В данном случае эта ячейка пуста.
Вместо пустого значения также могут быть сценарии, где образуется неправильное значение. Это неприемлемо — придется делать переназначение, а это довольно утомительная работа. Что, если у нас будет не десять ключей, а десять тысяч? Для решения этой проблемы вместо обычной хеш-таблицы воспользуемся согласованным хешированием, которое также известно как согласованное хеш-кольцо.
Работа с согласованным хеш-кольцом
В обычном сценарии нам известна доступная область памяти, поскольку мы последовательно именуем ключи в хеш-таблице с помощью чисел, например от 1 до 10. Нюанс в том, что здесь ключи назначаются совершенно случайным образом.
Для значения “яблоко” мы передаем его в функцию хеширования и получаем результат: 2394. Берем этот хеш-номер и сразу находим местоположение — набор ключей, который больше 2394, в данном случае это 3030. Мы сохраняем значение здесь.
Допустим, есть еще один ключ “шарик” со значением 2567 — он также будет храниться в том же месте цепочки. Если мы получили хешированное значение 11000, то, поскольку доступного значения в ячейках нет, мы возвращаемся к началу и сохраняем в 1000. Это что-то вроде закольцовки. Вот как работает согласованное хеш-кольцо.
Политика вытеснения кэша
Как вытеснять кэш и когда нужно это делать?
Вытеснение означает удаление ключа и значения из кэш-памяти. Зачем это делать? Кэш стоит дорого, а некоторые сохраненные значения остаются без дела. Поэтому нужно определить, какие записи не используется и обладает идеальным расположением, а потом удалить их, чтобы освободить место для новых. Это известно как политика вытеснения кэша.
Одна из распространенных стратегий вытеснения — Least Recently Used или LRU. Она предполагает удаление записи, к которой за последнее время обращались реже всего.
Необходимо каким-то образом выяснить, к какой ячейке происходило меньше всего обращений, и сохранить новую запись именно там.
Внутренние части кэша
Мы разобрались с хеш-таблицами, оперативной памятью и LRU. Теперь нам нужен сервис, который обслуживает запросы на получение/размещение/удаление (get/put /delete). Несмотря на высокую скорость работу, оперативная память все равно блокирует вызовы. Поэтому нужен эффективный способ удовлетворения этих запросов.
Для этого можно создать n потоков по мере получения запросов или расширить пул для обработки потоков. Еще один возможный вариант — это логика, основанная на событиях.
Как показано на рисунке выше, у нас есть очередь событий. Туда попадает любой запрос “get/put”. Также есть цикл событий, который выполняется бесконечно и представляет собой однопоточную операцию. Помимо этого, доступен пул потоков, который выполняет только операции ввода-вывода в оперативную память.
Каждый раз, когда мы получаем запрос “get/put”, он помещается в очередь событий. Цикл событий продолжает считывать очередь событий и передает запрос, который свободно располагается в ней. Как только происходит передача в пул потоков, он выполняет обратный вызов и снова считывает очередь событий.
Таким образом, очередь событий никогда не блокируется. Поток в пуле, который получает запрос, выполняет операцию, получает данные и возвращается к запросу через ответ обратного вызова, цикл событий или какой-либо другой механизм. Именно так можно более эффективно обрабатывать запрос.
У Байду тоже есть свой рейтинг, его посмотреть можно используяю Байду.Вебмастер или другие инструменты, типа: tool.cnzz.cn или tool.seowhy.com
Пользовательские факторы учитываются мало, насколько я знаю.
Есть ли у Baidu аналог ТИЦ/PR?
Учитывает ли Baidu при ранжировании пользовательские факторы или учитывается только ссылочное?
Обзаведитесь ICP-лицензией для сайта. Официально: ее наличие не влияет на индексацию. Но на практике ICP помогает Baidu быстрее решить хороший сайт или плохой (если одобрен правительством = хороший), и ставит его быстрее/выше.
Позиционирование и рейтинг в Baidu
Вкратце можно сказать, что как и с другими поисковиками, оценивается множество параметров: уникальность и качество контента, количество внешних ссылок и рейтинг ссылающихся сайтов, «плотность» ключевых слов и так далее. Пожалуй, только с плотностью дело тут обстоит несколько свободнее: если в Google/Яндекс за большое количество ключевиков на «сантиметр» текста можно получить «банхаммером», то Baidu на это смотрит проще. А самую главную роль в ранжировании играет link-building и количество внешних ссылок.
Сразу стоит отметить, что SEM и платная реклама в Байду (Baidu PPC, 百度推广) никак не влияют на индексацию/позиционирование. Но так как у Baidu нет никакой совести и рекламные площади находятся сверху выдачи, снизу, сбоку и посередине (еще совсем недавно они почти никак не отличались от обычных результатов, но сейчас у них другой фон), то этот момент очень важно не упускать. Можно вложить в SEO сотни тысяч юаней и оказаться на первом «органическом» месте, но это будет пятое (а недавно и десятое) место сверху от платных результатов. Некоторые эксперты говорят, что 80% пользователей не знают, что это проплаченные результаты. А те, кто знает, по инерции кликают в середину или в нижние результаты. Но не тут-то было, даже нижние результаты можно купить.
Если сравнить «теплокарты» (heat map) страниц результатов Google и Baidu, то мы увидим, что в Google активно кликают на первые три строчки. В Байду же большое количество кликов размазано по центру и нижним строчкам.
1998 год. «Если вы откроете окно для притока свежего воздуха, вы должны ожидать, что с воздухом прилетят и мухи!» — так была ознаменована эпоха Великого китайского фаервола, проекта, направленного на разделение интернет-пространства на Западное и Восточное, и, как следствие, ограничившего доступ рядовому китайскому пользователю к интернету «извне».
2006 год. Google открывается в зоне CN (google.cn) и обязуется блокировать сайты с «нежелательным» контентом, противоречащие политике КНР.
2009 год. Заблокированы сервисы Facebook, YouTube, Twitter, Flickr, Hotmail и частично почтовый клиент Gmail.
2010 год. Google заявляет об уходе с китайского рынка и перенаправляет весь трафик в Гонконг (google.com.hk).
2011 год. Google окончательно теряет свое присутствие в материковом Китае.
Сегодня китайский рынок поделен между четырьмя крупнейшими поисковыми системами:
— Baidu (百度 bǎidù) — доля рынка 73%
— Shenma (神马 shénmǎ) — доля рынка 10.9%
— 360 (360搜索 sōusuǒ) — доля рынка 7.9%
— Sogou (搜狗 sōugǒu) — доля рынка 4.5%