- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
На данный момент опубликовано 150+ статей. Все - в индексе. Трафик идет на около 80% статей. Есть мертвые - да. Но это жить не мешает, потому что там еще автоматом внутренняя перелинковка стоит. Они или вес добавляют или пользователи по ним ползают и улучшают поведенческие и время на сайте.
Вот это интересно технически - как обрабатываешь данные из базы, что используешь?
Через API подтягиваются различные сегментации, аггрегации, и своя бизнес-логика, которая все раскладывает по полочкам. Anthropic ничего сам не анализирует, он получает конкретные цифры и на основании промта формирует текст, который к этим цифрам больше подходит. От "ничего такого" до "все пропало".
Вот у тебя есть какие то документы. Ты формируешь промпт, сформулировала вопрос. Как ты дальше подбираешь доки? именно техническая сторона. Как они у тебя хранятся, как выбираешь из тысяч похожие итп. Именно технически как реализовано. Или реально все чисто бизнес-логика? "Если вопрос Х то добавь документ У..."
Ну вот бизнес-логика меня интересует, наверное. Неважно, по апи ты там ходишь или внутри контейнеров. Что я имею ввиду:
Вот у тебя есть какие то документы. Ты формируешь промпт, сформулировала вопрос. Как ты дальше подбираешь доки? именно техническая сторона. Как они у тебя хранятся, как выбираешь из тысяч похожие итп. Именно технически как реализовано. Или реально все чисто бизнес-логика? "Если вопрос Х то добавь документ У..."
Пользователь используя сервис "формирует" НЧ. Он об этом не знает, я их нормализирую.
Мой вымученный первый промт выдает по НЧ факты. Но не в свободной форме, структурировано, отвечая на FAQ вопросы, которые я там в промте поставила. Эта информация (еще перед генерации статьи) сохраняется в базе в виде отдельных полей в обычной базе, никаких векторов. Т. е. условно:
Entity
- faq-question 1
- faq-question 2
- faq-question 3
....
Ответы В формате yes/no/conditional/unclear + пруфы, подверждающие ответ кратко и с источниками.
Если следующий пользователь используя сервис "формирует" уже готовый НЧ, то ответ берется из моей базы, никаких поисков. Просто маленький промптик, который читает ответ на вопрос из базы и делает из него человеческий текст. Если такого НЧ еще нет, только тогда запускается агент. Т. е. база растет по мере использования сервиса на автомате. Чем больше его используют, тем больше НЧ уже сохранены в базе, тем меньше мне приходится запускать агента, потому что ответы уже структурировано лежат в базе.
статьи пишутся делаются на основе ответов FAQ из базы, без поиска фактов уже.
И еще делается агрегация, т. е. по типу сколько Entity имеют ответ на faq_question1 = no, ну и дальше понятно. Сравнить с yes, сравнить с категорией. Аггрегировать и так далее. Это то, что в статью по API подтягивается.
Эта информация (еще перед генерации статьи) сохраняется в базе в виде отдельных полей в обычной базе, никаких векторов. Т. е. условно:
Дальше какой план? Масштабировать кол-во статей с надеждой укрупнения трафика?
Он сам маштабируется. Чем больше сервис используется, тем больше нч появляются. План простой - выход на всю Европу. Сейчас таи один язык, довольно нишевый, типа фламандского. 😃 Был сделан чисто для проверки интереса-конверсии. Интерес-конверсия есть. Теперь допиливание до ума и многоязычная версия.
каждый вопрос может иметь только один ответ? а может быть на 1 вопрос вариации ответов?
Это по моей логике или conditional, т. е. зависит от .. в пруфе стоит от чего конкретно зависит. Или unclear - это когда разные источники противоречат и это тоже в пруфе стоит. Т. е. да ответ всегда 1:1, но зависит от фактов.
Ну и бизнес-логика построена как раз вокруг yes/no/conditional/unclear.
Это по моей логике или conditional, т. е. зависит от .. в пруфе стоит от чего конкретно зависит. Или unclear - это когда разные источники противоречат и это тоже в пруфе стоит. Т. е. да ответ всегда 1:1, но зависит от фактов.
Не уверен, но при такой жесткой привязке должна резко снижаться вариативность текстов. Но это нужно глубже изучать. Я бы все таки луше ушел в RAG, но не просто векторный поиск а использовал бы гибрид embeddings+BM25+RRF.
эмбеддинг даст широкий охват но он может налажать при точном совпадении. Это лечит ВМ25 - (lexical/sparse search) У него уже все хорошо с полнотекстовым поиском. Ну и далее для улучшения - реранкинг.
Это вот сейчас классическая работа с своей базой
Не уверен, но при такой жесткой привязке должна резко снижаться вариативность текстов
А мне это как раз и нужно. В юридической тематике пользователи не платят за варитивность. Только за конкретные ответы с пруфами. Т. е. грубо говоря это узкая тематика, которая жёстко привязана к кокретной технике. Вот эта связка техника+юрисдикция создаёт НЧ. И пользователь получает из сервиса индивидуальную сборку ответов под свои нужды. Одним словом: он может сам несколько недель бесплатно поискать, сравнить, проверить. Или он получает это за плату прямо сразу. 😉