Чому потрібна автоматична генерація пов'язаних статей?
Уявіть: у блозі 500 статей, але читач відкриває одну й не бачить пропозицій перейти до схожого матеріалу. Відмова сягає 70%. Ручний підбір не масштабується — при сотнях публікацій необхідна автоматична система на основі тегів, категорій або семантичної близькості. Ми часто отримуємо такі запити й реалізуємо рішення під ключ, спираючись на багаторічний досвід інтеграції для великих блогів. Вартість впровадження визначається після аналізу, а економія від відмови від ручної перевірки може бути значною. Блок «Схожі статті» утримує користувача на сайті та знижує показник відмов.
Як автоматична генерація пов'язаних статей покращує SEO?
Система автоматично підбирає пов'язані статті на основі тегів, семантики та поведінки користувачів. За тегами та категоріями — швидко, не потребує ML, але поверхнево. За TF-IDF — статистична близькість на основі частоти термінів. За векторними ембедингами — семантична близькість, найкраща якість, потребує pgvector. У наших проектах embedding-based дає на 40% більше кліків, ніж простий tag-based. Ключова фраза "автоматична генерація пов'язаних статей" реалізується через ці підходи.
Які алгоритми підбору пов'язаних статей існують?
| Стратегія | Швидкість | Точність | Складність |
|---|---|---|---|
| Tag-based | висока | низька | низька |
| TF-IDF | середня | середня | середня |
| Embedding-based | низька | висока | висока |
| Метрика | До впровадження | Після впровадження |
|---|---|---|
| Середній час на сайті | 1:20 | 1:40 |
| Показник відмов | 65% | 55% |
| Кліки по пов'язаних | 0% | 12% |
Часта проблема — дублювання тегів: статті з однаковими тегами не обов'язково схожі за змістом. Наприклад, стаття про React-хуки та стаття про React-роутинг мають спільний тег React, але різну тематику. Tag-based підхід буде рекомендувати їх одна одній, що неефективно. Embedding-based підхід вирішує цю проблему. Вибір стратегії залежить від розміру блогу: для невеликих блогів (до 200 статей) достатньо tag-based; для великих (від 1000) embedding-based дає суттєвий приріст залученості.
Приклад розрахунку економії
При ручному підборі 1000 статей потрібно близько 50 годин роботи редактора. З автоматичною генерацією пов'язаних статей час скорочується до 2 годин, що економить значні кошти щомісяця.Що дає embedding-based підхід?
Embedding-based підхід з pgvector враховує семантичний зміст статті, а не лише спільні теги. В одному з кейсів з 1000+ статей впровадження дало зростання середнього часу на сайті на 25% і зменшення відмов на 15%. Статті, які раніше не перетиналися за тегами, стали рекомендуватися коректно. TF-IDF, навпаки, поступається за точністю на 30%, але працює в 2 рази швидше. Для блогів, де важлива швидкість, можна комбінувати: спочатку відфільтрувати за тегами, а потім ранжувати за ембедингами.
Ми використовуємо модель OpenAI text-embedding-3-small. Для кожної статті формується рядок із заголовка, витягу та перших 2000 символів контенту. Запит до API виконується у фоні через чергу. Готовий ембединг зберігається в стовпці типу vector(1536). Пошук найближчих сусідів виконується через оператор <=> (косинусна відстань) з використанням індексу IVFFlat.
Tag-based підхід — автоматична генерація пов'язаних
// RelatedArticleService
class RelatedArticleService
{
public function getRelated(Article $article, int $limit = 4): Collection
{
if ($article->tags->isEmpty()) {
// Фоллбек: статті з тієї ж категорії
return Article::published()
->where('category_id', $article->category_id)
->where('id', '!=', $article->id)
->latest()
->limit($limit)
->get();
}
$tagIds = $article->tags->pluck('id');
// Рахуємо кількість спільних тегів
return Article::published()
->where('id', '!=', $article->id)
->withCount(['tags as common_tags_count' => function ($q) use ($tagIds) {
$q->whereIn('tags.id', $tagIds);
}])
->having('common_tags_count', '>', 0)
->orderByDesc('common_tags_count')
->orderByDesc('published_at')
->limit($limit)
->get();
}
}
Embedding-based підхід з pgvector
// При створенні/оновленні статті
class ArticleObserver
{
public function saved(Article $article): void
{
GenerateArticleEmbedding::dispatch($article)->onQueue('low');
}
}
class GenerateArticleEmbedding implements ShouldQueue
{
public function handle(): void
{
$text = implode("\n", [
$this->article->title,
$this->article->excerpt,
strip_tags(substr($this->article->content, 0, 2000)),
]);
$embedding = OpenAI::embeddings()->create([
'model' => 'text-embedding-3-small',
'input' => $text,
])->embeddings[0]->embedding;
$this->article->update(['embedding' => '[' . implode(',', $embedding) . ']']);
// Перераховуємо кеш схожих для цієї статті
Cache::forget("related_articles_{$this->article->id}");
}
}
// Запит схожих через pgvector
public function getSemanticallyRelated(Article $article, int $limit = 4): Collection
{
$embedding = $article->embedding;
if (!$embedding) return collect();
return Cache::remember("related_articles_{$article->id}", 86400, function () use ($article, $embedding, $limit) {
return Article::published()
->where('id', '!=', $article->id)
->selectRaw('*, (embedding <=> ?) AS distance', [$embedding])
->whereNotNull('embedding')
->orderBy('distance')
->limit($limit)
->get();
});
}
React-компонент з lazy loading
// RelatedArticles.tsx
export function RelatedArticles({ articleId }: { articleId: number }) {
const ref = useRef<HTMLDivElement>(null);
const [inView, setInView] = useState(false);
// Завантажуємо тільки коли блок потрапляє у viewport
useEffect(() => {
const observer = new IntersectionObserver(
([entry]) => { if (entry.isIntersecting) setInView(true); },
{ rootMargin: '200px' }
);
if (ref.current) observer.observe(ref.current);
return () => observer.disconnect();
}, []);
const { data, isLoading } = useQuery({
queryKey: ['related', articleId],
queryFn: () => fetch(`/api/articles/${articleId}/related`).then(r => r.json()),
enabled: inView,
staleTime: 10 * 60 * 1000,
});
return (
<div ref={ref} className="mt-10">
<h3 className="text-xl font-bold mb-5">Читайте також</h3>
{isLoading ? (
<div className="grid grid-cols-2 gap-4">
{[...Array(4)].map((_, i) => (
<div key={i} className="h-32 bg-gray-100 rounded-lg animate-pulse" />
))}
</div>
) : (
<div className="grid grid-cols-1 sm:grid-cols-2 gap-4">
{data?.map((article: any) => (
<a key={article.id} href={article.url}
className="group flex gap-4 p-4 border rounded-xl hover:shadow-md transition-shadow">
{article.image && (
<img src={article.image} alt="" className="w-20 h-16 object-cover rounded-lg flex-shrink-0" />
)}
<div>
<p className="text-xs text-blue-600 mb-1">{article.category}</p>
<h4 className="text-sm font-medium group-hover:text-blue-600 transition-colors line-clamp-2">
{article.title}
</h4>
<p className="text-xs text-gray-400 mt-1">{article.reading_time} хв. читання</p>
</div>
</a>
))}
</div>
)}
</div>
);
}
Процес роботи
- Аналітика — оцінюємо обсяг блогу, поточну структуру, відвідуваність.
- Проєктування — обираємо стратегію (tag-based / TF-IDF / embedding-based) з урахуванням бюджету та цілей.
- Реалізація — пишемо сервіс, інтеграція з базою, фронтенд-компонент.
- Тестування — A/B тест на 20% трафіку: вимірюємо кліки по пов'язаних статтях, час на сайті, відмови.
- Деплой — викочуємо на продакшн, моніторимо метрики.
Терміни
Базова версія на тегах — 1-2 дні. З ембедингами та lazy loading — 3-4 робочих дні. Термін може варіюватися залежно від обсягу блогу та інфраструктури.
Що входить у роботу
- PHP-сервіс (Laravel) з tag-based та/або embedding-based підбором.
- Міграція для pgvector.
- React-компонент з lazy loading.
- Документація з кастомізації.
- Навчання одного розробника.
- 1 місяць підтримки після запуску.
Метрики та гарантії
Більше 50 впроваджень для блогів з відвідуваністю до 100 000 на місяць. Досвід роботи з highload-версіями. Гарантуємо, що система не вплине на Core Web Vitals та коректно працює при 500+ одночасних запитах.
Якщо ви хочете впровадити автоматичну генерацію пов'язаних статей, зв'яжіться з нами — ми підберемо оптимальне рішення. Отримайте консультацію щодо впровадження пов'язаних статей для вашого блогу. Замовте послугу — оцінимо проєкт безкоштовно.