ЧатГПТ в WeChat

Потрібно внести невелику правку в програму, яка формує замовлення для друку. Завдання: Ми додали в асортиментм'яке скло з принтом. У замовленнях назва принта буде виділена символами#...# для коректного розпізнавання. Приклад: Мяке скло, #Абстракція біла# 2.0mm, Форма: Прямокутник... Необхідно: якщо в тексті замовлення присутній фрагмент між символами#...#, програма повинна розпізнати його як замовлення з принтом; при формуванні PDF або аркуша для друку таке замовлення потрібновиділити окремим кольором (будь-яким помітним, узгодимо під час виконання); решта логіки роботи програми має залишитися без змін. Приклад замовлення додаю нижче для тестування.

Проект: Ми запускаємо B2B-сервіс наскрізної аналітики та управління рекламними кампаніями для таргетологів і медіабайерів. Продукт працюватиме з офіційним Meta API. Головна технічна складність і фокус проекту — віртуозна робота з лімітами Facebook, маршрутизація трафіку між пулом наших додатків і жорстка система захисту інфраструктури від блокувань сірих рекламних акаунтів. У нас вже є детальне технічне завдання, описана архітектура баз даних, логіка балансувальника та вимоги до інтерфейсів. Шукаємо виконавця, який візьме це в реалізацію під ключ (бекенд + фронтенд дашбордів). Що потрібно зробити (Ключові завдання): Інтеграція з Meta API: Налаштувати авторизацію користувачів та регулярний асинхронний парсинг статистики рекламних кабінетів. Запити повинні надсилатися виключно пакетами для економії лімітів. Система авто-відізвання кабінетів: Написати модуль, який безперервно моніторить статуси рекламних акаунтів. Якщо кабінет потрапляє в бан, система повинна автоматично відкликати токен доступу протягом 60 секунд, щоб захистити наше додаток від санкцій Meta. Інфраструктура проксі: Реалізувати тунелювання всіх запитів до API через пул SOCKS5. Обов'язкова жорстка прив'язка конкретного токена користувача до статичного IP-адреси. Розумна маршрутизація: Створити алгоритм, який буде розподіляти прив'язані рекламні кабінети між кількома нашими додатками Facebook у заданих пропорціях для зниження ризиків. Розробка інтерфейсів: Створити клієнтський дашборд зі зведеною таблицею статистики та просунуту адмін-панель для ручного управління лімітами користувачів, прив'язками до додатків і пулом проксі. Очікуваний стек технологій: Бекенд: Python, FastAPI. Асинхронні задачі: Celery, Redis. Бази даних: PostgreSQL (або ClickHouse для статистики, на ваш розсуд). Фронтенд: Vue.js або React (можна використовувати готові UI-бібліотеки та шаблони дашбордів, акцент на функціональність, а не складний дизайн). Вимоги до виконавця: Упевнений досвід роботи з Meta Graph API та Marketing API. Ви повинні розуміти, як працюють ковзаючі ліміти, як читати заголовки завантаженості та як працювати з токенами. Розуміння специфіки арбітражу трафіку. Слова «білінг», «бан рекламного кабінету», «бізнес-менеджер» і «фарм» не повинні викликати у вас запитань. Досвід побудови асинхронних парсерів і роботи з проксі-серверами на рівні мережевих запитів. Готовність працювати за чітким технічним завданням і здавати проект поетапно. Умови: Формат співпраці: Проектна робота Бюджет: Обговорюється індивідуально на основі вашої оцінки технічного завдання. Оплата: Поетапна, прив'язана до контрольних точок. Як відгукнутися: У супровідному листі обов'язково вкажіть ваш досвід роботи з Meta API, прикріпіть посилання на схожі проекти (або опишіть їх функціонал, якщо вони під NDA) і напишіть орієнтовну вилку цін і термінів на розробку подібної системи з нуля. Відгуки без опису релевантного досвіду роботи з Facebook API розглядатися не будуть.

Шукаємо спеціаліста з LLM, RAG та prompt engineering для аудиту й удосконалення вже створеного ШІ-асистента операторів контакт-центру мережі медичних центрів. Це не розробка з нуля. Наразі асистент працює в середовищі ChatGPT та використовує: власну навичку з інструкціями SKILL.md; базу знань у Project Sources; структуровані Markdown-файли, автоматично сформовані з CSV-вивантажень медичної інформаційної системи; окремі індекси цін, виконавців, підрозділів, пакетів, обладнання та рекомендованих комбінацій послуг. База містить приблизно: 2 700+ медичних послуг; 90+ пакетів і комплексів; 300+ рекомендованих комбінацій; 600+ хірургічних втручань; ціни за різними підрозділами; виконавців, адреси, підготовку, обладнання та іншу довідкову інформацію.Що має робити асистент За запитом оператора асистент повинен швидко надавати перевірену відповідь: чи надається потрібна послуга; точний код, назву та ціну; у яких підрозділах вона доступна; хто з лікарів або інших спеціалістів її виконує; як підготуватися; який пакет або комплекс вигідніше запропонувати; які супутні послуги доцільно запропонувати; яка послідовність комплексного запису; які є дешевші або альтернативні варіанти; для операцій — окремо базову ціну та орієнтовну загальну вартість випадку хірургічного лікування. Асистент не повинен вигадувати ціни, виконавців, підготовку, медичні показання або переносити інформацію між схожими послугами.Наявні проблеми Система вже працює, але потребує підвищення стабільності пошуку та якості відповідей. Зокрема: модель інколи знаходить основну послугу, але пропускає рекомендовані комбінації; не завжди витягує окремі поля з великих Markdown-файлів; може знаходити базову ціну операції, але пропускати загальну вартість хірургічного випадку; результати залежать від структури та розміру файлів у Project Sources; потрібно оптимізувати індекси, маршрутизацію джерел і правила пошуку; потрібно забезпечити однаково якісні відповіді на короткі, неточні та розмовні запити операторів. Наприклад, простий запит «холецистектомія» повинен одразу повернути доступні варіанти операції, коди, базові ціни, загальну вартість лікування, підрозділи, виконавців та пов’язані послуги.Завдання спеціаліста Провести аудит чинного SKILL.md, структури бази знань і логіки пошуку. Проаналізувати причини пропуску даних під час retrieval. Запропонувати оптимальну архітектуру бази знань для ChatGPT. Удосконалити або переписати SKILL.md. Оптимізувати структуру Markdown-файлів та компактних індексів. Налаштувати обов’язковий пошук: пакетів і комплексів; рекомендованих комбінацій; цін за підрозділами; виконавців; вартості випадку хірургічного лікування. Перевірити генератор бази знань із CSV-вивантажень та за потреби вдосконалити Python-скрипти. Створити набір контрольних запитів і критеріїв оцінювання відповідей. Провести тестування на реальних сценаріях контакт-центру. Надати фінальну документацію для подальшого оновлення та підтримки системи.Очікуваний результат Маємо отримати стабільного асистента, який: відповідає українською мовою; не пропускає критично важливі дані; повертає лише інформацію, підтверджену базою знань; правильно розрізняє послуги, пакети та рекомендовані комбінації; показує код, назву, ціну, підрозділ і виконавця; для операцій розділяє базову ціну та повну вартість лікування; пропонує оператору конкретний сценарій подальшого запису пацієнта; стабільно працює після наступних оновлень CSV-вивантажень; працює відносно швидко.Вимоги до виконавця Потрібен спеціаліст із практичним досвідом: ChatGPT Projects, Custom GPT або ChatGPT Skills; LLM, RAG, retrieval та семантичного пошуку; prompt engineering; проєктування баз знань для мовних моделей; Markdown, CSV, JSON/JSONL; Python для обробки та перетворення даних; тестування якості відповідей LLM. Буде перевагою досвід із медичними інформаційними системами, контакт-центрами або великими каталогами послуг. Ми шукаємо не лише автора промтів, а спеціаліста, який розуміє обмеження пошуку у великих джерелах, фрагментацію контексту та способи побудови надійних індексів.Що надати у пропозиції Просимо коротко зазначити: Ваш досвід із ChatGPT, RAG або корпоративними базами знань. Приклади схожих реалізованих проєктів. Як би ви підійшли до діагностики пропуску окремих полів у великих файлах. Орієнтовні строки та вартість аудиту й доопрацювання. Чи готові ви підписати угоду про конфіденційність. Персональні дані пацієнтів у межах цього проєкту не передаватимуться. Остаточна вартість робіт буде узгоджена після уточнення Технічного Завдання між Замовником та Виконавцем.

Коротко Потрібна програма на Python, яка запускається у мене на ПК (Windows) і робить faceless-відео формату «закадровий голос + змінюваний відеоряд з фото та кліпів» — як історичні документалки на YouTube (приклад прикріплю окремо). Я вводжу тему → програма пише сценарій, озвучує, підбирає під кожен шматок тексту відео/фото з безкоштовних архівів, склеює → видає готовий MP4. Тільки для мене. Без сайту, без користувачів, без продажу. Один користувач — я. Як працює (по кроках) 1. Введення. Відкривається просте вікно. Я вводжу тему ролика і вибираю голос озвучення зі списку (**список голосів підтягується автоматично з ElevenLabs по API** — доступні на моєму акаунті). Натискаю «Створити». (Другий режим: вставити готовий сценарій замість генерації.) 2. Сценарій. Програма через LLM API (OpenAI/Anthropic, ключ в налаштуваннях) пише сценарій за темою, заданої довжини. 3. Розбивка на сцени. LLM ділить сценарій на сцени і для кожної повертає: текст сцени; тип візуалу: відео або фото; пошуковий запит (розгорнута фраза, що повинно бути в кадрі); позначку «highlight» + оцінку важливості 1-10 (для інтро, див. нижче). 4. Озвучення. Текст відправляється в ElevenLabs API обраним голосом → аудіо. Під довжину аудіо кожної сцени обрізається відеоряд. 5. Підбір відео/фото — з безкоштовних джерел по API (див. список нижче). Під кожне джерело запит формується по-своєму (для точності). Якщо в одному не знайшлося — пробує наступний. 6. Перевірка (максимум 3 кроки на сцену). Крок 1: програма бере перший знайдений варіант (відео/фото) за запитом. Крок 2: відправляє кадр в LLM — «підходить під сцену?». Підходить → стоп. Крок 3 (якщо не підходить): програма переключається на пошук фото (по точному запиту фото знайти простіше, ніж відео, — так гарантовано потрапляємо по сенсу) і бере його з посиленим рухом (зум + панорама). Більше 3 кроків на одну сцену не робити — це економить бюджет LLM і гарантує, що кадр в тему. 7. Збірка через ffmpeg/moviepy: кліпи і фото під таймінг озвучення, фото оживляються зумом (ефект Кена Бернса), голос поверх, прості переходи. Вихід: MP4 1920×1080. Правила відеоряду (важливо — за це відповідає програма) Перші 60 секунд — інтро-тизер: нарізка найефектніших кліпів з усього ролика (беруться сцени з вищою оцінкою важливості, де є відео) під окремий текст-вступлення від LLM («в цьому відео ви дізнаєтеся…»), кадри без пояснень, як інтрига. Потім перехід і основна частина. Чередування: відео-вставка мінімум кожні ~6 секунд, не можна багато фото підряд. Доля відео: не менше ~40% часу — живі кліпи, решта — фото з зумом. Довжина кадру: 4-6 секунд (і фото, і відео). Не мельтешити, не тримати статику довго. Для чисто історичних тем, де відео немає — фото з посиленим рухом (зум + панорама). Джерела (всі безкоштовні, з API) Сучасне відео+фото: Pexels, Pixabay. Історичне / архівне (public domain): Wikimedia Commons, Archive.org,Library of Congress, Europeana, NASA, Smithsonian Open Access,Flickr Commons, openverse. Кожне джерело — окремий модуль, легко додати новий. Використовувати тільки public domain / вільні ліцензії з правом комерційного використання. Жодного парсингу чужих YouTube/сайтів, шматків фільмів, картинок «з гугла».Унікальність підбору Щоб відео не співпадали з чужими: брати випадковий кліп з топ-видачі (не перший), вести базу вже використаних (не повторювати), опціонально — легка обробка кліпа (кроп/дзеркало/ швидкість). Опції (вкл/викл в налаштуваннях) Тільки фото — якщо включено, відео збирається ЧИСТО з фото, без відео-кліпів. Кожне фото ОБОВ'ЯЗКОВО з рухом (зум і/або панорама, ефект Кена Бернса) — навіть в цьому режимі не повинно бути статичних «мертвих» кадрів, мінімальна динаміка завжди. Якщо вимкнено — стандартний режим (фото + відео-кліпи з чергуванням, як в правилах відеоряду). Без озвучення — якщо включено, відео збирається по тексту БЕЗ генерації голосу: код НЕ звертається до ElevenLabs і не накладає озвучення (відеоряд підбирається по тексту сцен, таймінг кадрів — по правилам/параметрам, без прив'язки до аудіо). Якщо вимкнено — автоматично робить озвучення по тексту через ElevenLabs, як зазвичай. Атмосферний оверлей — якщо включено, поверх всього відеоряду накладається напівпрозорий шар з плаваючими частинками / пилом / світними боке / легким туманом (particle / dust / bokeh / fog overlay, режим накладення screen/add), щоб кадри виглядали живими і кінематографічними. При установці програми кладеться набір з 5-8 популярних оверлеїв (частинки, пил,copyбоке, туман, легке кінематографічне «зерно») в локальну папку — я вибираю потрібний зі списку. Регульована прозорість/яскравість оверлея (повзунок 0-100%), щоб ефект не був ніcopyзанадто тьмяним, ні занадто вираженим — я сам налаштовую силу. Бажано, щоб оверлей можна було накладати і на ВЖЕ готове відео окремоcopy(постобробка: взяти готовий MP4 → вибрати оверлей → задати прозорість → зберегти), а не тільки при зборці. Звідки взяти оверлеї для комплектації (вільна ліцензія): Pexels, Pixabay (запитиcopy«particle overlay», «bokeh overlay», «dust overlay», «light leaks», «film grain»), Mixkit, Videezy. Виконавець підбирає 5-8 штук і кладе в папку програми. Субтитри (вшити або окремим .srt). Обробка кліпів для унікальності. Роздільна здатність/формат, довжина відео, доля відео, глибина пошуку.Технічні вимоги Python. Модульна структура (джерела і LLM — через змінні модулі, щоб легко замінити або додати). Всі API-ключі — в файлі налаштувань, не в коді. Просте вікно (GUI на вибір виконавця — Tkinter/PyQt), запуск подвійним кліком. README з інструкцією, зрозумілі логи, коментарі в коді.Що даю я API-ключі (ElevenLabs, LLM, де потрібна реєстрація — оформлю). Платне оплачую сам. Приклади відео-референсів (прикріплю) і приклади тем для тестів.Приймання (готово, якщо) Запускаю → вікно → ввожу тему, вибираю голос → «Створити» → отримую готовий MP4. Відеоряд по сенсу тексту, чергування відео/фото, інтро-тизер 60 сек, озвучення поверх. Працює мінімум з 6 безкоштовними джерелами, з fallback між ними. Перевірка кадрів через LLM: макс. 3 кроки на сцену (знайшли → LLM перевірив → якщо немає, фото з рухом як вірняк). Унікальність: рандомізація + база використаного. Тільки легальні джерела. Є README, запускається з нуля.Передача результату Весь вихідний код — в відкритому вигляді (всі файли), без обфускації + зібрана робоча версія. Я можу сам запустити з вихідників за інструкцією (README: установка, ключі, запуск). Код повинен бути чистим, прокоментованим і зрозумілим, щоб **будь-який інший програміст міг продовжити роботу** над ним, якщо знадобиться (не прив'язка до автора). **Вся повсякденна робота — через інтерфейс (кнопки, поля, повзунки, випадаючі списки), БЕЗ необхідності торкатися коду.** Усі налаштування (тема, голос, опції, оверлей, папки, довжина, формати) змінюються у вікні програми, а не редагуванням файлів. Код на руках — тільки як моя власність і страховка, а не як спосіб управління програмою. Усі права на код після оплати — мої.Управління місцем на диску (важливо) Програма не повинна забивати диск. Реалізувати: Після зборки відео всі проміжні файли (завантажені кліпи, тимчасові шматки, аудіо-нарізки) автоматично видаляються — на диску залишається тільки готовий MP4. Ліміт на кеш (параметр в налаштуваннях, напр. 5 ГБ): при перевищенні старі завантажені файли видаляються автоматично (спочатку найстаріші). Папку для готових відео і для тимчасових файлів я задаю в налаштуваннях. Показувати, скільки місця зайнято, і кнопка «очистити кеш» вручну.Прошу вказати в відгуку Приклади схожих робіт (ffmpeg/moviepy, робота зі стоковими/архівними API, ElevenLabs/LLM). Пропозиція по GUI. Використовує чи рішення базу даних (яку і навіщо) — або вистачає локальних файлів. Термін і вартість.

Розробляємо real-time інтеграцію з зовнішнім сервісом Тренер. Відправляємо структуровані знімки стану, отримуємо рекомендації і показуємо їх спливаючим вікном. Завдання — стабільна і повна передача даних для коректної роботи Тренера. Шукаємо розробника для ланцюга: обробка даних → HTTP-комунікація → overlay. Потрібні люди з такими навичками Python добре, Java база, API HTTP/JSON-APIs Проект готовий на 90%, але є деякі несоответствия