Comments 8
claude sonnet не поддерживает обработку pdf только images. Каким образом вы это реализовали?
Good catch! Перед тем, как передать pdf в Claude Sonnet мы проверяем, если PDF это набор изображений, то просто передаем изображения в Bedrock. Если это текст, то он просто извлекается из PDF и далее по флоу. Мы тоже столкнулись с такой проблемой, и это решение пришло немного позже. Вот тут хорошо описано: https://tarkalabs.com/blogs/extracting-structured-data/
такое решение выглядит непонятным так как pdf по сути уже структурированный файл который будет намного легче обработать используя Amazon Textract, который в разы дешевле чем гонять генеративную модель.
звучит вполне логично… до тех пор, пока не начнёшь разбирать тот самый 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.
предполагаю вопрос скорости можно решить если использовать Amazon Q, или (Cursor || Windsurf). они уже знают как убрать тягомотину и решить ее за 20 минут.
Абсолютно всё можно переложить на Copilot, Amazon Q или Cursor. Только потом на собес приходят такие вот "курсорные" ребята, с набором сертификатов и кейсов из презентаций, а на базовый вопрос по реальному опыту – тишина. Кнопки нажимали, да, но зачем и как оно под капотом – не в курсе (это из реального опыта проведения собесов). А сертификаты эти "иховы"… ну, максимум, стену в туалете оклеить. Красивое ;)
P.S. Если реально можно всё закрыть за 20 минут и оно в проде не падает, то кинь ссылку, с интересом посмотрел бы.
я лишь предположил. :) Про курсорных ребят, техника в руках индейца - куча металлолома. Все новые магические штуки не панацея, а помогаторы (правда очень мощные). В любом случае спасибо за статью, было интересно построить. Кстати мне его Amazon Q построил без серверно реально за 20-40 минут. Настроив всё в экосистеме AWS (не Textract версию). И я юзнул GO как язык
такое решение выглядит непонятным так как pdf по сути уже структурированный файл который будет намного легче обработать используя Amazon Textract, который в разы дешевле чем гонять генеративную модель.
Как я построил serverless OCR-сервис на AWS Lambda и Amazon Bedrock