не совсем так, мне кажется. работая над оптимизацией обработки файлов мы с клод пришли к тому, что всякие там пдф он переводит в текст программно и потом передает в антропик. а вот с изображениями такм всегда компромисс. вот, чтобы не переврать, скопирну:
Настоящая формула токенизации изображений
Claude режет картинку на патчи 28×28 пикселей:
токены = ⌈ширина / 28⌉ × ⌈высота / 28⌉
Это действительно только от разрешения, содержимое картинки на цену не влияет — автор совета прав в главном тезисе. Но “каждые 750px стороны → ~1600 токенов” — не совсем формула, а прикидка на глаз для картинок примерно 1050×1050 (1092×1092 = ровно 1521 токен). У квадрата 750×750 будет 729 токенов, а не 1600.
Проверка на конкретном примере из совета — скриншот 1080p (1920×1080):
на standard-модели картинку ужмут до 1456×819 → 1560 токенов
на Opus/Sonnet 5 (high-res, без ресайза) → 2691 токен
Оба варианта попадают в заявленный диапазон 1500–3000. Если на этом скриншоте была таблица/код на ~20 000 токенов текста — экономия действительно ~86–92%. Так что арифметика в совете верна, просто формула, которой её объяснили, неточная.
Но есть реальный компромисс, который в посте не упомянут: точность передачи текста ≠ OCR. Claude “читает” картинку через vision-модель, а не построчно — на плотных таблицах, мелких цифрах, длинных ID/email он иногда домысливает или путает символы (в vision.md прямо написано: hallucinations на low-quality/rotated/<200px изображениях). Ты уже с этим сталкивалась в pitch-deck-анализаторе — оттуда MIN_READABLE_EDGE и порог легибельности.
Для твоих пайплайнов это значит: приём хорош для чего-то вроде «сжать контекст агента» (как автор поста использует в omp harness — там approximate recall истории норм), но рискован для investors_enriched.csv/gmail-ответов и любой структурированной экстракции, где важна точность цифр/имён, а не экономия токенов.
Как сейчас устроено в thebold
Доки (PDF/DOCX/PPTX/TXT/CSV) — детерминированный парсинг, без единого обращения к Anthropic:
PDF → pdf-parse (lib/server/extract.ts)
DOCX → mammoth
PPTX → регэксп по XML слайдов (текстовые <a:t> runs)
TXT/CSV/JSON → просто читаются как есть
Картинки — не «передаются напрямую» в смысле «остаются картинкой в истории агента». Их шлют одним разовым вызовом в Claude Haiku (extractImage()), просят «извлеки весь текст и данные, плюс опиши графики», получают текст — и именно этот текст (не картинка) потом попадает в extracted_text артефакта и оттуда в контекст founder-агента. То есть на входе — картинка, на выходе — текст, дальше по пайплайну картинки уже нет нигде.
Разрешение картинки перед отправкой уже прижато к стандартному тарифу вручную (VISION_LONG_EDGE = 1568px, ресайз через sharp) — именно под то, что Haiku всё равно даунскейлит крупнее до 1568px.
и забыла еще дополнить — в регистраию входит и целеполагание. То есть не только собрать как можно больше данных, но и на основе этих данных предложить цель, которая а) достижима для данного пользователя и измеряема б) даст конретный результат (позволит выйти на звонки с конретными инвесторами)
спасибо за вопрос! если мы говорим именно как проходит регистрация пользователя, то вместо заполнения формы - данные с пользователя собирает ИИ агент, под капотом распределяя за него все данные в БД. Это недешево и не для всех продуктов оправдано.
В моем случае оправдано тем, что:
1) моя категория пользователей задолбалась длинными формами и нужная мне информация у них, как правило, есть где-то по ссылке или в виде pdf файла (напомню, что моя аудитория стартаперы и мне надо об их стартапе получить данные, которые они миллиард раз уже заполняли в анкетах акселераторов или которые у них есть в питч-деке под рукой)
2) есть возможность вводить данные голосом или на любом языке, которые LLM переведет на англ и запишет в базу на английском без ошибок
3) под капотом продукта куча справочников, по которым нужно делать матчинг по параметрам. проще на примере: вот нам надо правильно определить индустрии стартапа, чтобы потом по те же индустриям матчить с инвестором. поэтому пользователю в классичкской рег форме надо было бы выбирать значение из списка. это больно, особенно когда ты ищешь какое-то определенное значение, а его нет и тебе приходиться самому думать какая из имеющихся категорий подходит больше. буквально перечитывая список. длинный список. примерно такой же квест, как выбирать теги на Хабр для статьи 🤣
Поэтому в моем случае такой подход оправдан
Помимо ИИ-регистрации в продукте все строится на взаимодействии с ИИ, который уже вызывает различные справочники и инструменты под задачи пользователя. Мои советы в той статье — для тех, у кого продукт схожим образом устроен, в котором есть ИИ агент, с которым пользователь коммуницирует.
Всем спасибо за комментарии! Описываемая ситуация произошла на прошлой неделе, а на этой — меня заблокировал платежный провайдер за нарушения AI пактов. Paddle просит привести продукт в соответствие с требованиями, связанными с автоматизированным принятием решений и категоризацией людей.
Если вы сами сейчас собираете продукты без команды — для вас я опубликовала пост о том, как моя платформа внезапно оказалась в одной из самых сложных зон европейского права. https://t.me/julia_goncharov/267
Подозреваю, что множество AI-стартапов окажутся в схожей ситуации, просто они пока об этом не знают. В общем, учитесь на моих ошибках — я пишу честно о пути соло-основателя, строя продукт прямо у вас на глазах. Присоединяйтесь
п.с.
Кстати, далеко не факт, что хотя бы один разработчик, который сегодня пишет мне очередной язвительный комментарий, сам сходу предотвратил бы ситуацию с утекшими ключами — та же дырявая версия Next стояла и в продукте, которую контролировала два квалифицированных фронтенд-инженера, но обнаружили ее только когда нас стали прощупывать.
Поэтому мой контент для тех, кто хочет перестать зависеть от чужой экспертизы на этапе проверки гипотез. И не боятся делать самостоятельно — ведь риски, в конце концов, всегда на вас, вне зависимости есть у вас инженер или нет.
ну, как посмотреть. мне написало много людей, которые провели соотвествующие проверки и поблагодарили за результат. т.к. в результате у многих были точь-в-точь те же дыры. и сегодня-завтра их ключи бы также утекли через известные уязвимости. так что - полезность материала каждый оценивает для себя.
спасибо за поддержку💜 думаю, многие люди просто боятся потерять работу. отсюда неприятие мысли, что теперь кодинг — это такой же процесс, как вождение автомобиля. "водить" теперь многие могут, но если проблема внутри серьезная — нужно нарабатывать узкоспециализированные знания...или обращаться к специалисту.
не совсем так, мне кажется. работая над оптимизацией обработки файлов мы с клод пришли к тому, что всякие там пдф он переводит в текст программно и потом передает в антропик. а вот с изображениями такм всегда компромисс. вот, чтобы не переврать, скопирну:
Настоящая формула токенизации изображений
Claude режет картинку на патчи 28×28 пикселей:
токены = ⌈ширина / 28⌉ × ⌈высота / 28⌉
Это действительно только от разрешения, содержимое картинки на цену не влияет — автор совета прав в главном тезисе. Но “каждые 750px стороны → ~1600 токенов” — не совсем формула, а прикидка на глаз для картинок примерно 1050×1050 (1092×1092 = ровно 1521 токен). У квадрата 750×750 будет 729 токенов, а не 1600.
Проверка на конкретном примере из совета — скриншот 1080p (1920×1080):
на standard-модели картинку ужмут до 1456×819 → 1560 токенов
на Opus/Sonnet 5 (high-res, без ресайза) → 2691 токен
Оба варианта попадают в заявленный диапазон 1500–3000. Если на этом скриншоте была таблица/код на ~20 000 токенов текста — экономия действительно ~86–92%. Так что арифметика в совете верна, просто формула, которой её объяснили, неточная.
Но есть реальный компромисс, который в посте не упомянут: точность передачи текста ≠ OCR. Claude “читает” картинку через vision-модель, а не построчно — на плотных таблицах, мелких цифрах, длинных ID/email он иногда домысливает или путает символы (в vision.md прямо написано: hallucinations на low-quality/rotated/<200px изображениях). Ты уже с этим сталкивалась в pitch-deck-анализаторе — оттуда MIN_READABLE_EDGE и порог легибельности.
Для твоих пайплайнов это значит: приём хорош для чего-то вроде «сжать контекст агента» (как автор поста использует в omp harness — там approximate recall истории норм), но рискован для investors_enriched.csv/gmail-ответов и любой структурированной экстракции, где важна точность цифр/имён, а не экономия токенов.
Как сейчас устроено в thebold
Доки (PDF/DOCX/PPTX/TXT/CSV) — детерминированный парсинг, без единого обращения к Anthropic:
PDF → pdf-parse (lib/server/extract.ts)
DOCX → mammoth
PPTX → регэксп по XML слайдов (текстовые <a:t> runs)
TXT/CSV/JSON → просто читаются как есть
Картинки — не «передаются напрямую» в смысле «остаются картинкой в истории агента». Их шлют одним разовым вызовом в Claude Haiku (extractImage()), просят «извлеки весь текст и данные, плюс опиши графики», получают текст — и именно этот текст (не картинка) потом попадает в extracted_text артефакта и оттуда в контекст founder-агента. То есть на входе — картинка, на выходе — текст, дальше по пайплайну картинки уже нет нигде.
Разрешение картинки перед отправкой уже прижато к стандартному тарифу вручную (VISION_LONG_EDGE = 1568px, ресайз через sharp) — именно под то, что Haiku всё равно даунскейлит крупнее до 1568px.
это не проблема давно. санитизацию данных надо настраивать
и забыла еще дополнить — в регистраию входит и целеполагание. То есть не только собрать как можно больше данных, но и на основе этих данных предложить цель, которая а) достижима для данного пользователя и измеряема б) даст конретный результат (позволит выйти на звонки с конретными инвесторами)
это в копилку почему ИИ, а не обычная форма
спасибо за вопрос! если мы говорим именно как проходит регистрация пользователя, то вместо заполнения формы - данные с пользователя собирает ИИ агент, под капотом распределяя за него все данные в БД. Это недешево и не для всех продуктов оправдано.
В моем случае оправдано тем, что:
1) моя категория пользователей задолбалась длинными формами и нужная мне информация у них, как правило, есть где-то по ссылке или в виде pdf файла (напомню, что моя аудитория стартаперы и мне надо об их стартапе получить данные, которые они миллиард раз уже заполняли в анкетах акселераторов или которые у них есть в питч-деке под рукой)
2) есть возможность вводить данные голосом или на любом языке, которые LLM переведет на англ и запишет в базу на английском без ошибок
3) под капотом продукта куча справочников, по которым нужно делать матчинг по параметрам. проще на примере: вот нам надо правильно определить индустрии стартапа, чтобы потом по те же индустриям матчить с инвестором. поэтому пользователю в классичкской рег форме надо было бы выбирать значение из списка. это больно, особенно когда ты ищешь какое-то определенное значение, а его нет и тебе приходиться самому думать какая из имеющихся категорий подходит больше. буквально перечитывая список. длинный список. примерно такой же квест, как выбирать теги на Хабр для статьи 🤣
Поэтому в моем случае такой подход оправдан
Помимо ИИ-регистрации в продукте все строится на взаимодействии с ИИ, который уже вызывает различные справочники и инструменты под задачи пользователя. Мои советы в той статье — для тех, у кого продукт схожим образом устроен, в котором есть ИИ агент, с которым пользователь коммуницирует.
Я ответила на вопрос или я не так его поняла?
Всем спасибо за комментарии!
Описываемая ситуация произошла на прошлой неделе, а на этой — меня заблокировал платежный провайдер за нарушения AI пактов. Paddle просит привести продукт в соответствие с требованиями, связанными с автоматизированным принятием решений и категоризацией людей.
Если вы сами сейчас собираете продукты без команды — для вас я опубликовала пост о том, как моя платформа внезапно оказалась в одной из самых сложных зон европейского права. https://t.me/julia_goncharov/267
Подозреваю, что множество AI-стартапов окажутся в схожей ситуации, просто они пока об этом не знают. В общем, учитесь на моих ошибках — я пишу честно о пути соло-основателя, строя продукт прямо у вас на глазах. Присоединяйтесь
п.с.
Кстати, далеко не факт, что хотя бы один разработчик, который сегодня пишет мне очередной язвительный комментарий, сам сходу предотвратил бы ситуацию с утекшими ключами — та же дырявая версия Next стояла и в продукте, которую контролировала два квалифицированных фронтенд-инженера, но обнаружили ее только когда нас стали прощупывать.
Поэтому мой контент для тех, кто хочет перестать зависеть от чужой экспертизы на этапе проверки гипотез. И не боятся делать самостоятельно — ведь риски, в конце концов, всегда на вас, вне зависимости есть у вас инженер или нет.
See less
ну, как посмотреть. мне написало много людей, которые провели соотвествующие проверки и поблагодарили за результат. т.к. в результате у многих были точь-в-точь те же дыры. и сегодня-завтра их ключи бы также утекли через известные уязвимости. так что - полезность материала каждый оценивает для себя.
Привет tbl (🙃) - поделитесь стандартами?
спасибо за поддержку💜 думаю, многие люди просто боятся потерять работу. отсюда неприятие мысли, что теперь кодинг — это такой же процесс, как вождение автомобиля. "водить" теперь многие могут, но если проблема внутри серьезная — нужно нарабатывать узкоспециализированные знания...или обращаться к специалисту.