Практика Rails: Розумний семантичний пошук через PostgreSQL & ActiveRecord

#codica_advice

Чи бувало у вас таке: замовник приходить і каже: “Нам терміново потрібен AI-пошук у проекті!“, а ви вже уявляєте новий деплой, налаштування Pinecone або Qdrant, додатковий бюджет і головний біль з інфраструктурою?

Спокійно! Знайшли для вас елегантне рішення, яке дозволяє реалізувати семантичний векторний пошук без жодної нової бази даних — прямо у вашому звичному PostgreSQL.

Більшість продуктів зараз додають AI-фічі, але підключати окремі векторні бази даних (Pinecone/Qdrant) — це зайвий деплой, гроші та інфраструктура.

Якщо у вас вже є PostgreSQL, проблему вирішує розширення pgvector та гем pgvector-ruby

Як це працює на практиці за 4 кроки:

1️⃣ Додаємо гем та вмикаємо розширення:

# Gemfile
gem “pgvector”

Створюємо міграцію:
class EnablePgvector < ActiveRecord::Migration[7.1]
  def change
    enable_extension “vector”
  end
end

2️⃣ Додаємо векторну колонку до моделі:

class AddEmbeddingToProducts < ActiveRecord::Migration[7.1]
  def change
    # 1536 — розмірність для стандартних векторів OpenAI (text-embedding-3-small)
    add_column :products, :embedding, :vector, limit: 1536
  end
end

3️⃣ Підключаємо магію в ActiveRecord:

class Product < ApplicationRecord
  has_neighbors :embedding
end

4️⃣ Робимо семантичний пошук у коді:

# Отримуємо вектор від AI для пошукового запиту “теплий худі на зимову погоду”
user_vector = OpenAIClient.embed(“теплий худі на зимову погоду“)

# Шукаємо найближчі товари за косинусною відстаню прямо через SQL:
@nearest_products = Product.nearest_neighbors(:embedding, user_vector, distance: “cosine”).first(5)

🔥 Чому це круто:
• Жодних сторонніх сервісів — все всередині вашої Postgres.
• Повна підтримка стандартних з’єднань, scope та фільтрів ActiveRecord.
• Легко масштабується до мільйонів записів за допомогою HNSW індексів.

А ви вже пробували впроваджувати векторний пошук у своїх Rails-проектах чи поки використовуєте звичайний Full-Text Search? 👇

TikTok | Instagram | Telegram

🚨 ХТО ЗНОВУ ЗЛАМАВ СТЕЙДЖ? НОВИЙ IT-ДЕКТЕКТИВ! 🚨

Друзі, у нас в компанії черговий релізний форс-мажор. Чотири спеціалісти працювали над фічами, але хтось один завантажив сирий код і повністю поклав стейджинг-сервер 😱

Наш PM зібрав первинні логи та записав кілька фактів. Допоможіть знайти винуватця, визначивши для кожного: Роль, Мову/Інструмент та їхній єдиний головний факап.

📋 Команда та ресурси:
Андрій, Марія, Сергій, Олена.

Ролі:
Backend, Frontend, QA, PM.

Мови та Інструменти:
Python, JavaScript, Jira, Postman.

Факапи:
Поклав стейдж, Забув дедлайн, Видалив ліда з CRM, Створив 50 merge conflicts.

Відомо, що:
Андрій працює з Python.
Марія — QA.
QA працює в Postman і не ламала стейдж.
PM веде задачі в Jira і саме він забув дедлайн.
Олена — не Frontend і не QA.
Сергій — не Backend і не PM.
Frontend працює з JavaScript і саме він поклав стейдж.
Backend створив 50 merge conflicts.

🤔 Хто поклав стейдж? Яка у нього роль та інструмент?
Пишіть у коментарях ім’я винуватця 👇

TikTok | Instagram | Telegram