У спільному воркшопі каналу AI Engineer Луї-Франсуа Бушар, Самріді Вайд та Пол Іуштін показують, як побудувати повноцінну систему для глибоких досліджень і технічного письма на базі LLM. Після гнучкого дослідницького агента, який збирає й структурує факти, у центрі уваги опиняється інша, набагато жорсткіша частина — конвеєр написання коротких технічних текстів на кшталт LinkedIn‑постів. Саме ця друга половина системи, разом із засобами спостереження, трасування та оцінки якості, визначає, чи перетвориться сирий артефакт дослідження на справді корисний контент, а не черговий шматок «AI‑slop».
Чому технічне письмо потребує іншої архітектури, ніж дослідження
У внутрішній продакшн‑системі Towards AI, яку згодом перетворили на відкритий навчальний проєкт, конвеєр свідомо розділили на дві сутності: гнучкого дослідницького агента та значно більш детермінований воркфлоу для письма. Обидві частини працюють з одними й тими самими моделями, але підпорядковуються різній логіці.
Дослідницький агент — це місце для автономії. Він планує стратегію, ходить у веб‑пошук, аналізує відео, фільтрує джерела за релевантністю та надійністю, а потім збирає все в структурований артефакт research.md. Тут корисні петлі зворотного зв’язку, можливість змінювати план, повертатися до попередніх кроків, додавати нові запити. Архітектура нагадує класичну агентну систему з інструментами, пам’яттю та гнучким плануванням.
Письмо — інша історія. Мета — не «досліджувати ще», а перетворити вже зібрані факти на чіткий, короткий, технічно коректний текст. Для цього потрібні:
- жорсткі обмеження на формат і обсяг;
- явні інструкції щодо стилю, структури, тону;
- контроль за тим, щоб модель не вигадувала того, чого немає в артефакті;
- можливість рецензії та доопрацювання.
Тому конвеєр письма будується як керований воркфлоу, а не як ще один агент. Він не має «свободи» шукати нові джерела чи змінювати завдання. Його завдання — дисципліновано спожити research.md і видати один конкретний продукт: короткий технічний пост, придатний, наприклад, для LinkedIn.
Це розділення архітектур — ключова ідея. Там, де дослідження виграє від автономії, письмо виграє від обмежень. Саме тому в системі існує «слайдер автономії»: дослідницький агент знаходиться ближче до «агентів», а письменницький конвеєр — ближче до жорстко прописаного воркфлоу.
Обмежений воркфлоу для LinkedIn‑рівня: як влаштований «писець»
Система письма в цьому проєкті свідомо оптимізована під короткий технічний контент — насамперед пости формату LinkedIn. Це не універсальний генератор статей, а вузькоспеціалізований інструмент, який працює в чітко окреслених рамках.
Перший принцип — повна залежність від артефакту дослідження. Вихід дослідницького агента — це Markdown‑файл research.md, де вже зібрані, структуровані та процитовані джерела. Саме цей файл стає головним (і по суті єдиним) вхідним контекстом для письменницького воркфлоу. Модель не ходить у веб, не викликає додаткових інструментів, не «домислює» відсутні факти. Вона працює з тим, що є.
Другий принцип — жорсткі інструкції. Воркфлоу задає:
- цільовий формат: короткий пост, а не довга стаття;
- орієнтацію на технічну аудиторію, а не на загальний маркетинговий текст;
- вимоги до структури: вступ, одна‑дві ключові ідеї, лаконічний висновок;
- заборону на розмиті формулювання, кліше й «AI‑слоп»;
- обов’язкову прив’язку до конкретних фактів із
research.md.
Третій принцип — контроль і рецензія. Письмо не обмежується одним викликом моделі. У воркфлоу закладені цикли перегляду, де вихід тексту може бути оцінений, відредагований або відхилений на основі явних критеріїв. Це може бути як автоматизований «рев’юер» на базі LLM, так і подальша ручна перевірка, але архітектурно система вже передбачає, що перша спроба — не обов’язково фінальна.
У підсумку виходить не «агент‑копірайтер», а дисциплінований конвеєр: на вхід — артефакт дослідження, на вихід — короткий, щільний технічний пост, який не виходить за межі зібраних фактів.
Проста послідовність замість важкої оркестрації
Попри те, що система складається з двох суттєво різних компонентів — дослідницького агента та воркфлоу письма, — їхня інтеграція реалізована максимально просто. Немає складного оркестратора, графів завдань чи важкої інфраструктури.
Дослідницький агент і письменницький воркфлоу запускаються послідовно через звичайний скрипт. Алгоритм виглядає прямолінійно: спочатку виконується глибоке дослідження, яке завершується формуванням research.md, потім цей файл передається в систему письма, яка генерує кінцевий текст.
Такий підхід має кілька наслідків.
По‑перше, зменшується інженерна складність. Розробникам не потрібно підтримувати окремий оркестраційний шар, налаштовувати складні DAG‑схеми чи інтегруватися з важкими workflow‑системами. Усе зводиться до керованого скрипта, який запускає два етапи один за одним.
По‑друге, чітко розділяються відповідальності. Дослідницький агент відповідає за повноту й якість фактів, письменницький воркфлоу — за форму й подачу. Якщо виникає проблема з точністю, дивляться на research.md. Якщо проблема зі стилем або структурою — на конвеєр письма.
По‑третє, спрощується налагодження. Оскільки між компонентами передається явний артефакт у вигляді Markdown‑файла, легко відтворити будь‑який запуск: достатньо зберегти research.md і прогнати його через актуальну версію письменницького воркфлоу.
Це рішення добре узгоджується з загальною філософією проєкту: не переінженерювати там, де можна обійтися простими засобами, і підвищувати автономію лише там, де вона справді дає виграш.
Як система бореться з «AI‑slop»: контроль, петлі рев’ю та LLM‑суддя
Окремий акцент у воркшопі зроблено на тому, як уникнути типових проблем AI‑контенту: галюцинацій, пустих кліше, розмитих формулювань. Власне, вся архітектура письменницького воркфлоу — це відповідь на цю проблему.
По‑перше, модель жорстко обмежена в джерелах. Вона не має права виходити за межі research.md. Це автоматично відсікає значну частину галюцинацій, які виникають, коли LLM намагається «додумати» те, чого не знає.
По‑друге, інструкції прямо забороняють типові «слоп‑фрази» — на кшталт «швидко змінюваний ландшафт», «це не про X, а про Y» та інші шаблонні конструкції, які часто з’являються в згенерованих текстах. Модель не просто просять «писати краще», їй задають конкретні негативні приклади того, чого слід уникати.
По‑третє, у систему вбудовано рецензування. Воркфлоу письма реалізує патерн «writer/reviewer»: один виклик моделі виступає як «автор», інший — як «рецензент», який оцінює текст за низкою критеріїв: точність, повнота, ясність, відповідність формату. Якщо рецензент виявляє проблеми, текст може бути доопрацьований у наступній ітерації.
Щоб зробити цю оцінку не лише якісною, а й кількісною, у воркшопі демонструють окремий компонент — LLM‑суддю. Це ще один LLM, який працює поверх датасетів еталонних відповідей і обчислює метрики на кшталт F1‑міри. Система порівнює згенерований текст із «золотим стандартом» і рахує, наскільки добре збігаються ключові факти чи пункти.
Такий LLM‑суддя дозволяє:
- автоматизувати регресійне тестування: при зміні промптів або моделей можна перевірити, чи не погіршилася якість;
- об’єктивізувати дискусії про «кращі» чи «гірші» версії тексту;
- будувати ітеративний цикл покращення, де метрики стають орієнтиром для змін у воркфлоу.
У результаті система письма перестає бути «чорною скринькою», яка іноді видає щось хороше, а іноді — ні. Вона стає вимірюваним компонентом, який можна системно вдосконалювати.
Спостережуваність і трасування: навіщо Opik у конвеєрі письма
Ще один важливий шар — спостережуваність. Щоб розуміти, як поводяться і дослідницький агент, і письменницький воркфлоу, у проєкт інтегровано Opik — платформу для трасування й аналізу LLM‑запусків.
Opik дозволяє:
- бачити повну історію викликів моделей: промпти, відповіді, використані інструменти;
- відстежувати, як змінюється поведінка системи при оновленні промптів, моделей чи коду;
- швидко знаходити й розбирати проблемні кейси, де, наприклад, текст вийшов некоректним або дослідження пропустило важливе джерело.
Для конвеєра письма це особливо важливо. Якщо LLM‑суддя показує падіння F1‑міри, а користувачі скаржаться на якість постів, без трасування складно зрозуміти, де саме все пішло не так: на етапі дослідження, при формуванні research.md чи вже в самому воркфлоу письма.
Opik дає можливість «розмотати» цей ланцюжок. Можна подивитися, який саме артефакт дослідження потрапив у систему письма, як виглядав промпт до моделі‑«писця», що повернув «рецензент», які рішення приймав LLM‑суддя. Це перетворює налагодження з інтуїтивного «підкручування промптів» на більш системну інженерію.
Крім того, спостережуваність важлива для освітнього аспекту проєкту. Оскільки система використовується для навчання студентів AI‑інженерії, можливість показати їм реальні трасування, розібрати помилки й покращення на конкретних прикладах стає частиною навчального контенту.
Витоки системи: автоматизація внутрішнього конвеєра Towards AI
Усе описане вище — не лабораторний експеримент, а еволюція реальної продакшн‑системи. Спочатку цей конвеєр будувався для внутрішніх потреб Towards AI, які регулярно випускають курси, відео та уроки з AI‑інженерії.
Традиційний процес створення такого контенту вимагає команди: AI‑інженерів, технічних авторів, редакторів. Вони разом проводять дослідження, структурують матеріал, пишуть тексти, правлять, адаптують під різні формати. Це дорого й повільно, особливо коли потрібно масштабуватися.
Мета системи — не повністю замінити людей, а автоматизувати повторювані частини: збір фактів, первинну структуру, чернетки коротких текстів. Люди залишаються там, де потрібні глибока експертиза, креативність і тонке відчуття аудиторії, але значна частина «важкої роботи» перекладається на конвеєр дослідження й письма.
Згодом цю внутрішню систему перетворили на навчальний воркшоп. Кодова база стала публічною: її можна знайти в GitHub‑репозиторії, посилання на який дають через QR‑код і README. Учасники воркшопу отримують не лише концепції, а й робочий код, який можна запускати, змінювати й адаптувати під власні задачі.
Цей перехід від внутрішнього інструмента до відкритого навчального проєкту важливий ще й тим, що дозволяє спільноті бачити реальні інженерні компроміси: чому обрали простий скрипт замість важкого оркестратора, чому розділили дослідження й письмо, як саме інтегрували оцінку й спостережуваність.
Інфраструктура під капотом: Python, uv і Gitingest для GitHub‑контенту
Хоча фокус воркшопу — на архітектурі та воркфлоу, технічна реалізація теж має значення. Увесь проєкт написано на Python, а для керування залежностями використовується uv. Це дозволяє відносно легко розгортати середовище, відтворювати його на машинах учасників воркшопу й уникати типових проблем із сумісністю пакетів.
Окремий компонент системи — робота з GitHub‑репозиторіями. Для цього використовується бібліотека Gitingest. Вона бере репозиторій і перетворює його в Markdown‑подання, яке вже зручно споживати LLM‑моделям. Важливий нюанс: Gitingest уміє працювати не лише з публічними, а й із приватними репозиторіями, якщо надати токен доступу. Це відкриває шлях до аналізу внутрішнього коду компаній у тому ж дослідницькому конвеєрі.
Markdown‑подання коду добре вписується в загальну архітектуру, де основним артефактом є research.md. Дослідницький агент може інкорпорувати фрагменти з GitHub‑репозиторіїв у свій артефакт, а письменницький воркфлоу — використовувати їх для створення технічних постів, які посилаються на реальний код.
Таким чином, навіть на рівні інфраструктури система залишається вірною своїй філософії: усе зводиться до текстових артефактів у Markdown, які легко зберігати, версіонувати, аналізувати й передавати між компонентами.
LLM‑суддя, датасети й F1: як вимірюють якість конвеєра
Щоб конвеєр письма не залишався суто евристичним, у воркшопі показують, як додати до нього кількісну оцінку. Для цього використовується LLM‑суддя, який працює поверх заздалегідь підготовлених датасетів.
Сценарій виглядає так: є набір завдань (наприклад, теми постів) і «золоті» еталонні відповіді, які вважаються правильними або бажаними. Система генерує свої відповіді, після чого LLM‑суддя порівнює їх із еталонами й обчислює F1‑міру — баланс між повнотою й точністю.
Цей підхід дозволяє:
- тестувати різні версії промптів для письменницького воркфлоу;
- порівнювати моделі між собою;
- відстежувати, як зміни в дослідницькому агенті впливають на кінцевий текст.
Важливо, що LLM‑суддя — це не «абсолютний арбітр істини», а інструмент для відносних порівнянь. Він добре підходить для того, щоб сказати: «ця версія системи в середньому краща за попередню», але не для того, щоб гарантувати ідеальну якість кожного окремого поста. Однак у поєднанні з трасуванням через Opik і ручним рев’ю це дає досить потужний набір інструментів для еволюції системи.
Висновок: технічне письмо як інженерна задача, а не побічний продукт LLM
Історія цього конвеєра — це, по суті, історія про те, як перестати сприймати LLM як «чарівну коробку», яка сама напише хороший текст. У продакшн‑контексті технічне письмо стає такою ж інженерною задачею, як побудова API чи налаштування пайплайна даних.
Розділення на гнучкий дослідницький агент і жорстко обмежений воркфлоу письма, послідовний запуск через простий скрипт, явний артефакт research.md, інтеграція спостережуваності через Opik, використання LLM‑судді й F1‑метрик, інфраструктура на Python з Gitingest для роботи з GitHub — усе це елементи однієї картини. Вони показують, що якісний AI‑контент — це результат продуманої архітектури, а не просто «кращої моделі».
Для інженерів, які хочуть будувати власні системи технічного письма, головний урок у тому, що варто розділяти завдання, обмежувати автономію там, де вона шкодить, і ставитися до тексту як до продукту, який можна вимірювати, трасувати й системно покращувати. Саме тоді AI перестає генерувати «слоп» і починає працювати як частина серйозного редакційного конвеєра.
Джерело
Full Workshop: Build Your Own Deep Research Agents – Louis-François Bouchard, Paul Iusztin, Samridhi