Абсолютно всё можно переложить на Copilot, Amazon Q или Cursor. Только потом на собес приходят такие вот "курсорные" ребята, с набором сертификатов и кейсов из презентаций, а на базовый вопрос по реальному опыту – тишина. Кнопки нажимали, да, но зачем и как оно под капотом – не в курсе (это из реального опыта проведения собесов). А сертификаты эти "иховы"… ну, максимум, стену в туалете оклеить. Красивое ;)
P.S. Если реально можно всё закрыть за 20 минут и оно в проде не падает, то кинь ссылку, с интересом посмотрел бы.
звучит вполне логично… до тех пор, пока не начнёшь разбирать тот самый JSON, который возвращает Textract.
Сам по себе Textract – мощный инструмент. Но вы когда-нибудь пытались вытащить из него, скажем, список товаров из счёта, а потом логично всё это связать между Blocks, Relationships, Geometry, Text и всей этой прелестью? Надеюсь, у вас было свободное утро и запас валерьянки ;)
Textract – это про данные. Точнее, про структуру данных. Bedrock (Nova, Claude, Titan, Mistral и пр.) – это про смысл.
Надо просто вытащить сумму счёта – Textract. Хотите понять, зачем пришёл счёт, что в нём важного и как его классифицировать – LLM.
И ещё момент: пока вы будете собирать пайплайн, который парсит Textract-ответ, разбирает таблицы, формы и лепит из всего этого что-то, пригодное для UX – конкурент уже выкатил MVP на LLM, протестировал флоу на клиентах и ушёл дальше. Time-to-market не ждёт. Особенно, когда Claude просто "читает" документ и сразу выдаёт: это инвойс, вот сумма, вот заказчик, а вот причина отказа – и всё это без 200 строк кастомной логики.
Так что вопрос тут не "Textract или Bedrock", а "что вы хотите получить":
P.S. Почему-то многие в своих расчётах упираются в стоимость ресурса, но напрочь забывают про стоимость времени и человеческого труда. Если Bedrock решает задачу за час и стоит условные $1000 – я выберу его. Потому что Textract, хоть и "обойдётся" в $50, может легко съесть весь спринт, который обойдется вам, как минимум, двухнедельной зарплатой. И не забываем про TCO.
Good catch! Перед тем, как передать pdf в Claude Sonnet мы проверяем, если PDF это набор изображений, то просто передаем изображения в Bedrock. Если это текст, то он просто извлекается из PDF и далее по флоу. Мы тоже столкнулись с такой проблемой, и это решение пришло немного позже. Вот тут хорошо описано: https://tarkalabs.com/blogs/extracting-structured-data/
Так было. Потому что, кто-то когда-то наверху решил сэкономить и обойтись минимумом сильных инженеров. Но когда мы показали сколько стоит выкатить фичу, сколько времени уходит на поддержку и как страдают сроки и качество, картина быстро поменялась.
Сейчас у нас вполне адекватный баланс по уровням – сеньоры, мидлы, джуны. Более того, мы выбили learning-бюджет с тремя нулями для всех разработчиков (курсы, митапы, конференции, ...) и немножко геймифицировали обучение – за активность выдаём фирменный мерч, билеты на матчи и прочую атрибутику. Работает удивительно хорошо. Если тема интересная и не все могут посетить мероприятие, то иногда организовываем что-то типа "Conf:recap", чтобы и остальные были в теме.
Бывает путь через грабли, но если есть цифры и аргументы, то наверху обычно слышат.
Проблема не в том, что кто-то «слишком умный», а в том, что критичные знания держатся в голове одного человека.
Пример из жизни (упрощенный, но реальный): у компании старая база на Informix, к которой за 15 лет никто толком не прикасался, кроме одного senior’а. Он знает, где что лежит, как запускается бэкап, какие индексы нельзя трогать и почему триггер в триггере — это «ок, но только тут». Он уехал в отпуск. Через два дня отвалилась отчётность, поднять бэкап не смогли, бизнес встал.
Это и есть «накопление риска». Не в том, что человек умный — а в том, что всё держится только на нём.
Да, разобраться можно — вопрос времени и бюджета. Вот только бизнесу обычно нужно «вчера», а не через 2 месяца после увольнения ключевого разработчика.
Вы абсолютно правы: допускать завязку на одного человека — управленческая ошибка. Именно об этом и статья: не про то, что «одиночки плохие», а про то, что их нельзя превращать в критическую точку отказа.
Если сеньор – единственный, кто знает, как всё работает, то остальная пирамида не «присосалась», а пытается как-то удержать знания внутри компании, чтобы бизнес не зависел от одного мозга.
Да, документацию может писать кто угодно. Но если код понимает только автор – это уже не код, а квест без подсказок. И увольнять всех, кто не "зарабатывает в час", – стратегия классная до первого отпуска или больничного этого самого сеньора.
А по поводу розовых кед – да, тренды бывают странные, но надёжность и командная передача знаний пока что вне моды не выходят.
Согласен, реальность – это когда тебе за $150 в час приносят switch(true) в проде и any через всю архитектуру.
Но это не отменяет закономерности: если платить мало и без разбора, то вероятность нарваться на катастрофу стремится к единице. Так что да, цена не всегда про качество. Но вот низкая цена и отсутствие отбора – это почти всегда про боль.
Ага, приехал, развернул monorepo без доков, закоммитил всё в main и уехал, оставив нас жить с его наследием. Теперь каждый раз, когда кто-то открывает этот код, рождается новый джун с ПТСР и вопросом: "А можно я лучше тесты писать буду?".
Так что да – пони бывают, но техдолг за ними – как навоз. Много и воняет.
Классика жанра: "сам создаю пожары, сам же геройски тушу". Такие псевдо-герои часто получают ордена за продуктивность, пока не посчитать, сколько стоит "спасённый" ими проект.
DynamoDB просто как пример упомянул – не агитирую :) У нас чаще в бою крутится связка Lambda + MSK + EventBridge Pipes + ещё кучка специй по вкусу включая DDB – всё это обрабьатывает матчевые события в реальном времени, считает алерты, метрики и прочую аналитику на лету.
По поводу "кратковременные задачи – редкость"... Ну, возможно, у вас архитектурный дзен и всё стабильно как в банке. У нас же 90 минут футбола, 50Hz трекинг, тысячи событий, всё летит и обрабатывается в real-time. Lambda тут вообще как швейцарский нож.
Но если задачи реально тяжёлые и по времени/ресурсам не влазят в рамки Lambda – никто не запрещает смотреть в сторону ECS Fargate. Тоже serverless, только для тех, кому надо "пожирнее", но без заботы о серверах.
Если у вас всё внутри периметра и всё работает – замечательно. Главное, чтобы потом не оказалось, что «периметр» – это коробка, в которой тушат пожары (из практики) :)
Denial of Wallet – это не баг, это фича для тех, кто лепит serverless как попало. Тут не AWS виноват, что у тебя Lambda по таймеру крутится каждые 5 секунд и лупит по DynamoDB без всякого смысла.
Большинство таких "заоблачных счетов" – результат архитектурной импотенции и «нагуглил, как сделать». А при нормальном подходе serverless летает, как реактивный дрон, и стоит копейки.
Мы гоняем аналитику футбольных матчей – десятки тысяч событий, миллионы трекинг данных, real-time алерты, snapshot'ы – и это обходится дешевле кофе из автомата. Не шучу. Мы не "крутим" сервисы 24х7, а "поднимаем" их только на время матча – причем, теми же Lambda-ми ;)
Просто надо не “функции писать”, а архитектуру думать.
Вы правы – это должно быть закреплено сверху. Но в международной практике менторство и обмен знаниями давно входят в обязанности senior-инженера. Это не «допнагрузка», а часть роли. Без этого – это просто быстрый middle, а не senior.
Идея здравая, но на практике "единый подход" часто размывается: задачи разноплановые, требования меняются, люди уходят. Даже лучший подход не спасёт, если знания о нём знает один человек. Важно не только что делать, но и как делиться знаниями по ходу.
Абсолютно всё можно переложить на Copilot, Amazon Q или Cursor. Только потом на собес приходят такие вот "курсорные" ребята, с набором сертификатов и кейсов из презентаций, а на базовый вопрос по реальному опыту – тишина. Кнопки нажимали, да, но зачем и как оно под капотом – не в курсе (это из реального опыта проведения собесов). А сертификаты эти "иховы"… ну, максимум, стену в туалете оклеить. Красивое ;)
P.S. Если реально можно всё закрыть за 20 минут и оно в проде не падает, то кинь ссылку, с интересом посмотрел бы.
звучит вполне логично… до тех пор, пока не начнёшь разбирать тот самый JSON, который возвращает Textract.
Сам по себе Textract – мощный инструмент. Но вы когда-нибудь пытались вытащить из него, скажем, список товаров из счёта, а потом логично всё это связать между
Blocks,Relationships,Geometry,Textи всей этой прелестью? Надеюсь, у вас было свободное утро и запас валерьянки ;)Textract – это про данные. Точнее, про структуру данных. Bedrock (Nova, Claude, Titan, Mistral и пр.) – это про смысл.
Надо просто вытащить сумму счёта – Textract. Хотите понять, зачем пришёл счёт, что в нём важного и как его классифицировать – LLM.
И ещё момент: пока вы будете собирать пайплайн, который парсит Textract-ответ, разбирает таблицы, формы и лепит из всего этого что-то, пригодное для UX – конкурент уже выкатил MVP на LLM, протестировал флоу на клиентах и ушёл дальше. Time-to-market не ждёт. Особенно, когда Claude просто "читает" документ и сразу выдаёт: это инвойс, вот сумма, вот заказчик, а вот причина отказа – и всё это без 200 строк кастомной логики.
Так что вопрос тут не "Textract или Bedrock", а "что вы хотите получить":
Просто текст и структура – Textract.
Понимание, смысл, действия – LLM.
Хотите и то, и другое – комбинируем. Так, кстати, и сам AWS рекомендует.
P.S. Почему-то многие в своих расчётах упираются в стоимость ресурса, но напрочь забывают про стоимость времени и человеческого труда. Если Bedrock решает задачу за час и стоит условные $1000 – я выберу его. Потому что Textract, хоть и "обойдётся" в $50, может легко съесть весь спринт, который обойдется вам, как минимум, двухнедельной зарплатой. И не забываем про TCO.
Good catch! Перед тем, как передать pdf в Claude Sonnet мы проверяем, если PDF это набор изображений, то просто передаем изображения в Bedrock. Если это текст, то он просто извлекается из PDF и далее по флоу. Мы тоже столкнулись с такой проблемой, и это решение пришло немного позже. Вот тут хорошо описано: https://tarkalabs.com/blogs/extracting-structured-data/
Пробовали. Более того, поменяли в целом подход. И это работает. Но, статья про тот случай, когда у вас один ;)
Так было. Потому что, кто-то когда-то наверху решил сэкономить и обойтись минимумом сильных инженеров. Но когда мы показали сколько стоит выкатить фичу, сколько времени уходит на поддержку и как страдают сроки и качество, картина быстро поменялась.
Сейчас у нас вполне адекватный баланс по уровням – сеньоры, мидлы, джуны. Более того, мы выбили learning-бюджет с тремя нулями для всех разработчиков (курсы, митапы, конференции, ...) и немножко геймифицировали обучение – за активность выдаём фирменный мерч, билеты на матчи и прочую атрибутику. Работает удивительно хорошо. Если тема интересная и не все могут посетить мероприятие, то иногда организовываем что-то типа "Conf:recap", чтобы и остальные были в теме.
Бывает путь через грабли, но если есть цифры и аргументы, то наверху обычно слышат.
Проблема не в том, что кто-то «слишком умный», а в том, что критичные знания держатся в голове одного человека.
Пример из жизни (упрощенный, но реальный): у компании старая база на Informix, к которой за 15 лет никто толком не прикасался, кроме одного senior’а. Он знает, где что лежит, как запускается бэкап, какие индексы нельзя трогать и почему триггер в триггере — это «ок, но только тут». Он уехал в отпуск. Через два дня отвалилась отчётность, поднять бэкап не смогли, бизнес встал.
Это и есть «накопление риска». Не в том, что человек умный — а в том, что всё держится только на нём.
Да, разобраться можно — вопрос времени и бюджета. Вот только бизнесу обычно нужно «вчера», а не через 2 месяца после увольнения ключевого разработчика.
Вы абсолютно правы: допускать завязку на одного человека — управленческая ошибка. Именно об этом и статья: не про то, что «одиночки плохие», а про то, что их нельзя превращать в критическую точку отказа.
Интересная арифметика, но есть нюанс :)
Если сеньор – единственный, кто знает, как всё работает, то остальная пирамида не «присосалась», а пытается как-то удержать знания внутри компании, чтобы бизнес не зависел от одного мозга.
Да, документацию может писать кто угодно. Но если код понимает только автор – это уже не код, а квест без подсказок. И увольнять всех, кто не "зарабатывает в час", – стратегия классная до первого отпуска или больничного этого самого сеньора.
А по поводу розовых кед – да, тренды бывают странные, но надёжность и командная передача знаний пока что вне моды не выходят.
Вот поэтому цена – не показатель, а фильтр минимумов. Как по мне, так дальше работает только одно: жёсткий найм + ревью + культура.
Тяп-ляп – норм стратегия "срубить -> свалить". Но скейлить и мэйнтейнить бардак стоит дороже, чем строить нормально сразу.
В наше время, если текст без воды и по делу – значит, точно ИИ. Человеку ведь положено лить воду и путаться в мыслях. ;)
Кстати, это перевод.
В любой реальности можно кричать: «Почему так долго?!». Особенно когда ТЗ – это голосовое в Telegram, а бюджет – это «ну, вы там как-нибудь…».
И да, даже с сеньорами фичи "медленно". Потому что они сначала думают, а не стреляют себе в ногу, как дешёвый ковбой из фриланса.
Согласен, реальность – это когда тебе за $150 в час приносят
switch(true)в проде иanyчерез всю архитектуру.Но это не отменяет закономерности: если платить мало и без разбора, то вероятность нарваться на катастрофу стремится к единице. Так что да, цена не всегда про качество. Но вот низкая цена и отсутствие отбора – это почти всегда про боль.
Ага, приехал, развернул monorepo без доков, закоммитил всё в main и уехал, оставив нас жить с его наследием. Теперь каждый раз, когда кто-то открывает этот код, рождается новый джун с ПТСР и вопросом: "А можно я лучше тесты писать буду?".
Так что да – пони бывают, но техдолг за ними – как навоз. Много и воняет.
Классика жанра: "сам создаю пожары, сам же геройски тушу". Такие псевдо-герои часто получают ордена за продуктивность, пока не посчитать, сколько стоит "спасённый" ими проект.
DynamoDB просто как пример упомянул – не агитирую :) У нас чаще в бою крутится связка Lambda + MSK + EventBridge Pipes + ещё кучка специй по вкусу включая DDB – всё это обрабьатывает матчевые события в реальном времени, считает алерты, метрики и прочую аналитику на лету.
По поводу "кратковременные задачи – редкость"... Ну, возможно, у вас архитектурный дзен и всё стабильно как в банке. У нас же 90 минут футбола, 50Hz трекинг, тысячи событий, всё летит и обрабатывается в real-time. Lambda тут вообще как швейцарский нож.
Но если задачи реально тяжёлые и по времени/ресурсам не влазят в рамки Lambda – никто не запрещает смотреть в сторону ECS Fargate. Тоже serverless, только для тех, кому надо "пожирнее", но без заботы о серверах.
Если у вас всё внутри периметра и всё работает – замечательно. Главное, чтобы потом не оказалось, что «периметр» – это коробка, в которой тушат пожары (из практики) :)
Denial of Wallet – это не баг, это фича для тех, кто лепит serverless как попало. Тут не AWS виноват, что у тебя Lambda по таймеру крутится каждые 5 секунд и лупит по DynamoDB без всякого смысла.
Большинство таких "заоблачных счетов" – результат архитектурной импотенции и «нагуглил, как сделать». А при нормальном подходе serverless летает, как реактивный дрон, и стоит копейки.
Мы гоняем аналитику футбольных матчей – десятки тысяч событий, миллионы трекинг данных, real-time алерты, snapshot'ы – и это обходится дешевле кофе из автомата. Не шучу. Мы не "крутим" сервисы 24х7, а "поднимаем" их только на время матча – причем, теми же Lambda-ми ;)
Просто надо не “функции писать”, а архитектуру думать.
Вы правы – это должно быть закреплено сверху. Но в международной практике менторство и обмен знаниями давно входят в обязанности senior-инженера. Это не «допнагрузка», а часть роли. Без этого – это просто быстрый middle, а не senior.
Идея здравая, но на практике "единый подход" часто размывается: задачи разноплановые, требования меняются, люди уходят. Даже лучший подход не спасёт, если знания о нём знает один человек. Важно не только что делать, но и как делиться знаниями по ходу.
Не у меня одного создалось такое впечатление