bid-triage — фільтр AI-шуму в заявках, під замовлення
Огляд
Індивідуальний engagement, не готовий продукт: система відбору заявок для клієнта на фриланс-платформі, якого заливає AI-згенерованими ставками. Замість спроб класифікувати “написано ШІ” — перегони, в яких генерація структурно виграє в детекції — рішення інвертує асиметрію витрат, через яку спам-ставки взагалі дешеві, і залишає невелику кількість заявників, здатних реально включитись у конкретну задачу.
Підхід: не детектувати авторство, а призначити йому ціну. Одне коротке, обмежене дедлайном технічне питання нічого не коштує пропустити генеричному пайплайну і коштує практику десять секунд відповісти — саме цей розрив і є фільтром.
Справжня складна задача
Згенерувати й надіслати 100 заявок коштує спамеру копійки й секунди; прочитати й відфільтрувати їх коштує замовнику годину й нерви. Саме ця асиметрія, а не “ШІ проти людини”, — справжня проблема: заявник, що використав LLM для чіткої, коректної, релевантної заявки, не має бути покараний за інструмент, а текстовий класифікатор все одно не здатен надійно розрізнити різницю (якість детекції структурно відстає від якості генерації). Ціль має бути нерелевантність, а не авторство: чи демонструє ця заявка реальне розуміння саме цієї задачі, чи це правдоподібний шаблон, який так само підійшов би під тисячу інших оголошень.
Як це працює
Два гейти, в порядку зростання вартості. Спершу детермінований прохід прибирає ритуальні фрази (“радий допомогти”, шаблонні перерахування досвіду) і оцінює щільність реального технічного змісту в решті — жодного виклику LLM на заявку, що переважно наповнювач. Те, що проходить цей поріг, отримує рівно одне канаркове питання: вузьке питання-компроміс, прив’язане до реальних обмежень задачі (“зовнішній API обмежений 2 rps — чергуватимете через чергу, чи тут достатньо пулу воркерів у процесі?”), з жорстким дедлайном на відповідь. Генеричний пайплайн відповість обережним есе, що покриває обидва варіанти; практик відповість одним рядком і займе позицію. Лише заявки, що пройшли обидва гейти, потрапляють у шортлист — фінальне рішення все одно за людиною, але на кількох кандидатах, а не на сотні.
Ключові рішення
| Рішення | Чому |
|---|---|
| Призначати ціну взаємодії, не авторству | Текстові класифікатори програють перегони за визначенням — якість генерації росте швидше за якість детекції. Обмежений дедлайном обмін переносить вартість назад на того, хто подає заявку — той самий принцип, що CAPTCHA, тільки застосований до короткого технічного обміну замість задачі сприйняття. |
| Детермінований фільтр до будь-якого виклику LLM | Більшість шуму — шаблонні фрази; прибрати їх і оцінити решту не потребує жодного виклику моделі, тож дорогий крок працює лише на заявках, які вже пройшли дешевий поріг. |
| Одне хірургічне питання, не допит | Багатораундова анкета відлякує перевантажених сильних кандидатів, які радше просто поговорять з людиною. Одне гостре, специфічне для задачі питання-компроміс фільтрує так само добре без цього тертя. |
| Працює всередині акаунту клієнта, свідомо стримано | Кожне надіслане повідомлення несе ризик саме для акаунту клієнта на платформі, не постачальника — тож engagement свідомо стриманий: мало ітерацій, починаючи з заявок з найвищим сигналом, без агресивної пози автоматизації. |
| Індивідуально під клієнта, не спільний SaaS | Валідовано на одному реальному акаунті й одній реальній задачі найму перед будь-якою думкою про узагальнення — і профіль ризику платформи, і форма “сигналу” залежать від конкретної задачі, тож універсальний продукт був би або занадто агресивним для одних клієнтів, або занадто слабким для інших. |
Де ця схема узагальнюється
Механіка не специфічна для фриланс-заявок. Вона тримається там, де одночасно виконуються чотири умови: подання коштує відправнику практично нічого; оцінка коштує отримувачу реальний шматок часу; існує одне вузьке, специфічне для домену питання, дешеве для справжнього експерта й дороге — або просто викривальне — для generate-and-forget пайплайна; і кожна взаємодія достатньо цінна, щоб виправдати індивідуальне питання. Два домени, де всі чотири умови виконуються, кожен зі своїм реальним застереженням:
- B2B-тендери й відповіді на RFP. Постачальника, що заявляє підтримку протоколу “з коробки”, можна попросити посилання на реальну публічну документацію ендпоінту. Розмите “ми можемо реалізувати будь-що під ваші потреби” самовідсіюється — так само, як обережна двоабзацна відповідь на канаркове питання в заявці.
- Тріаж розкриття вразливостей (bug bounty програми). Та сама механіка канаркового питання застосовна, але вартість помилки тут спрямована в протилежний бік порівняно з фільтром заявок: хибне відхилення означає, що реальну вразливість відмахнули, бо репортер не встиг надати proof-of-concept вчасно. Чесна версія цього гейта — де-пріоритизація, ніколи автозакриття — людина лишається в циклі на кожному відхиленні.
Де це найслабше: одноразове оголошення на маркетплейсі (оренда квартири, одне оголошення на OLX). Цінність будь-якої окремої взаємодії занадто низька, щоб виправдати індивідуальне питання, і сама платформа зазвичай поглинає цю потребу як вбудовану фічу (наперед заповнені поля доступності/критеріїв), а не лишає її третій стороні — та сама логіка, що й аргумент проти побудови цього як генеричного продукту від початку.
Що зазвичай включає доставлений engagement
- Фільтр очищення від шаблонних фраз і логіка канаркового питання, налаштовані під власні оголошення й планку найму клієнта
- Вигляд шортлиста — компактне резюме на кожного кандидата, що пройшов, а не стіна непрочитаного тексту заявок
- Стриманий бюджет взаємодії, узгоджений з клієнтом наперед, розмірений під власну anti-automation поставу його платформи
Стек
Go · парсинг структурованого виводу LLM · детермінована попередня фільтрація · сесійна браузерна автоматизація — конкретний набір залежить від цільової платформи.