Інженер з інтеграції LLM

Микита С.

Привіт,

У мене є практичний досвід створення бекенд-систем, які з'єднують структуровані дані з LLM для запитів природною мовою, з сильним акцентом на надійність, обмеження та готовність до виробництва.

Ваше завдання дуже чітке: це не просто "спілкування з даними", а контрольований робочий процес NL → структурований запит, де важливі точність, логіка резервування та підтримуваність. Це правильний підхід для даних бенчмаркінгу компенсацій, особливо з клієнтами у фінансових послугах.

Я можу допомогти з:

створенням бекенд-сервісу та SQL-даного шару поза Bubble
…
реалізацією безпечного отримання зі структурованих приватних даних

експонуванням чистих REST-інтерфейсів для Bubble

форматуванням виходу бенчмарків для використання клієнтами

додаванням логіки резервування для випадків з низькою впевненістю / відсутніми даними

підтриманням системи стабільною, налагоджуваною та готовою до виробництва

Я працював над робочими процесами бекенду з підтримкою LLM, інтеграціями API, обробкою структурованих даних та виробничою логікою, де галюцинації неприпустимі. Мені комфортно відповідати за доставку від архітектури до реалізації та ітерації, і я можу чітко комунікувати прогрес простими словами.

40 годин на тиждень за 35 євро/годину мені підходить.

Якщо буде корисно, я також можу поділитися, як я б структурував шар отримання та обмеження перед початком розробки.

З найкращими побажаннями
Проєкт 1
LLM-асистент для роботи з аналітичними даними.

Система дозволяла ставити запитання природною мовою до структурованої бази даних (PostgreSQL).
Я реалізував бекенд-сервіс на Python (FastAPI), який:

приймав запит користувача

передавав його в LLM

перетворював NL → SQL

виконував запит до БД

повертав структурований результат

Вивід формувався у вигляді таблиці або короткого звіту.
Для запобігання помилок використовувалася перевірка SQL-запитів перед виконанням.

Проєкт 2
Система пошуку по внутрішній документації.

LLM використовувався разом з RAG-підходом:
дані індексувалися у векторну базу (FAISS), після чого модель отримувала тільки релевантні фрагменти.

Я реалізував:

ingestion pipeline

retrieval logic

API для фронтенду

обробку запитів

2. Найбільш схожий проект (NL → база даних → звіт)

Я працював над системою, де користувач міг задавати запитання до структурованих даних.

Джерело даних: PostgreSQL
Підхід: NL → SQL

Потік роботи:

користувач вводить запит природною мовою

LLM генерує SQL-запит

система перевіряє його (schema validation)

виконує запит

формує структурований звіт

Вивід:

таблиця

коротке текстове пояснення

Якщо даних не вистачало, систе

Схожий виконаний проєкт: Доробка ТГ бота

Перед стартом фіксую логіку, ризики та результат. Роблю боти, парсери, автоматизацію і веб-системи так, щоб ними реально користувались, а не просто “було написано код”.

Показати оригінал

Перекласти

Dmytro Derev'iankin

✋ Привіт! Ми dZENcode, компанія з розробки програмного забезпечення.

Ми надамо бекенд-систему, яка з'єднує ваші структуровані дані про компенсацію з LLM через API, з надійним витягом даних SQL, REST-інтерфейсами, сумісними з Bubble, AI-орієнтованим парсингом транзакцій та PDF/структурованим виходом, спираючись на досвід, найкращі практики та внутрішні інструменти.

Чи є попередньо визначені відповідності категорій компенсацій?
Які моделі LLM або кінцеві точки є переважними для інтеграції: GPT-4, Claude чи інші?

Для довідки: Freelancehunt
Фінальна вартість підтверджується після узгодження обсягу та критеріїв приймання.
…
Давайте зберігати всю комунікацію та платежі на цій платформі, поки контракт не буде укладено.

___________________
З найкращими побажаннями,
dZENcode

Наші сильні сторони:
• 10+ років у доставці програмного забезпечення (аутсорсинг та аутстафінг)
• 90+ внутрішніх спеціалістів
• Розробка з нуля та довгострокова підтримка
• SLA + обслуговування після випуску
• Відповідальна доставка з юридичною особою
• 250+ публічних відгуків з 2015 року

Показати оригінал

Перекласти

Елизавета Молчанова

Доброго дня, є досвід з LLM, реалізували кілька рішень для різних доменів, для аугментації даних та агрегації з різних джерел (структуровані та неструктуровані) з підходом чорного ящика та HITL. Давайте обговоримо деталі та сформуємо повне ТЗ перед стартом розробки. Для всіх додаткових питань, пишіть особистим повідомленням. Будемо раді співпраці.

Показати оригінал

Перекласти

Владислав Петельський

Вітаю! Задача мені повністю зрозуміла. Для фінансової платформи компенсацій головним викликом є не просто підключення LLM, а мінімізація галюцинацій та забезпечення того, щоб кожен запит до вашої БД був математично точним і безпечним.
Я маю підтверджений досвід розробки RAG-систем та агентів NL-to-SQL, які працюють зі структурованими даними, і готовий розробити бекенд-шар, що ідеально інтегрується з вашим Bubble-фронтендом.
Мій підхід до реалізації вашого проєкту:
1. Архітектура NL → Structured Query:
• Замість прямої генерації SQL моделями LLM, я реалізую Intermediate Representation (IR) або сувору валідацію схем. Модель спочатку генерує логічний запит, який проходить через валідатор, перш ніж стати SQL-кодом. Це виключає некоректні вибірки.
• Використання LangGraph або LlamaIndex для створення агентів, які розуміють специфіку компенсацій (валюти, регіони, грейди).
2. Бекенд та API (Python/FastAPI):
• Створю кастомний бекенд на FastAPI, розгорнутий незалежно від Bubble.
• Відкрию захищені REST кінцеві точки, які Bubble буде викликати через API Connector.
… • Реалізую чітку структуру вихідних даних: JSON для відображення графіків/таблиць на екрані та інтегрований сервіс (наприклад, ReportLab або WeasyPrint) для генерації PDF-звітів.
3. Контроль точності та Hallucination Guardrails:
• Впровадження логіки "Data Privacy & Thresholds": якщо вибірка за запитом менша за статистичний поріг (наприклад,