Built Technologies создала AI-систему интеллектуальной обработки документов на AWS для агентов в сфере недвижимости

Обработка документов в сфере недвижимости сложна и во многом до сих пор выполняется вручную, а значит напрямую влияет на критически важные бизнес-решения в больших масштабах. Built Technologies, поставщик ПО для финансирования недвижимости, обрабатывает проекты на сумму более $500 млрд. Компания развернула AI-движок для обработки документов на Amazon Bedrock и AWS Intelligent Document Processing (IDP) Accelerator. Теперь этот движок служит основой для agentic-продуктов по всему жизненному циклу объектов недвижимости. В этой статье мы разбираем, зачем в real estate finance нужен AI-powered document intelligence и как он устроен архитектурно.

Финансирование недвижимости живет на документах: draw packages, кредитных соглашениях, инвойсах, страховых сертификатах, отчетах об инспекциях и десятках других типов. В каждом из них содержится информация, которую кредиторы и другие участники рынка должны проверить, верифицировать и использовать для действий. Такие документы часто длинные, непоследовательные, доменно-специфичные и плохо поддаются традиционной автоматизации.

Для Built document intelligence — это не просто back-office-инструмент. Это горизонтальная AI-возможность, лежащая в основе нового поколения agentic-продуктов, которые запускаются по всему жизненному циклу real estate finance. Будь то агент, который проверяет строительный draw, анализирует кредитное соглашение, валидирует страховое покрытие, суммирует offering memorandum или ищет исключения в портфеле, ему нужна одна и та же базовая способность: понимать документы с контекстом, точностью и трассируемостью.

Чтобы создать такую основу, Built вместе с AWS Generative AI Innovation Center (GenAIIC), AWS Partner AND Digital и командами AWS account teams разработала масштабируемый AI-движок для обработки документов.

Результатом стало переиспользуемое решение document intelligence, которое умеет классифицировать, разделять, извлекать, оценивать и анализировать сложные документы по финансированию недвижимости. Оно сокращает процессы, занимавшие дни, до минут, поддерживает сотни типов документов и дает техническим командам и отраслевым экспертам общую среду для создания и улучшения процессоров документов.

Почему финансированию недвижимости нужен AI-powered document intelligence

Финансирование недвижимости — это массив документов, фрагментированный и сильно зависящий от контекста. Одна сделка или один актив могут включать сотни или тысячи страниц документации, подготовленной разными сторонами, в разных форматах и на разных этапах жизненного цикла актива.

Часть документов стандартизирована, например сертификаты ACORD 25 или государственные формы. Другие сильно варьируются: offering memorandums, кредитные соглашения, оценки, Excel-based финансовые модели, а также планы и спецификации. Во многих есть вложенные таблицы, сканы, встроенные изображения, непоследовательные подписи, юридический язык, рукописные пометки и терминология, специфичная для заемщика или кредитора.

Существующие возможности Built по обработке документов помогли компании перейти от ручной работы к автоматическому извлечению данных из множества типов документов. Команда создала 26 процессоров для extraction, splitting и classification с использованием optical character recognition (OCR) и традиционного machine learning (ML). Этот подход работал для более узких сценариев, где поля были явными, а макеты — предсказуемыми.

Но по мере расширения AI-дорожной карты Built на весь real estate lifecycle команде понадобилось решение более гибкое и более интеллектуальное. Требовалась система, способная поддерживать более 250 типов документов, обрабатывать миллионы документов и обеспечивать работу агентов, которые умеют не просто извлекать текст, а рассуждать о документах.

Built столкнулась с несколькими проблемами:

• Объем и разнообразие документов: Built обрабатывает более 250 типов документов в строительном кредитовании, финансировании недвижимости, asset management, compliance и portfolio workflows и других направлениях. Отдельные документы могут превышать 500 страниц.
• Сложные и непоследовательные структуры: Во многих документах есть вложенные таблицы, встроенные изображения, сканы, пользовательские макеты и нестандартная терминология.
• Извлечение, зависящее от контекста: Важная информация часто подразумевается, распределена по нескольким разделам или выражена на языке отрасли, а не в виде четко подписанного поля.
• Высокие требования к уверенности: Built требовалась уверенность выше 95 процентов в workflows классификации и извлечения для production-использования в финансовых и compliance-sensitive процессах.
• Масштаб и расширяемость: Built нужен был не один рабочий сценарий, а множество agentic AI-продуктов, которые запускаются в течение года.

Цель состояла в том, чтобы сделать document understanding переиспользуемой AI-возможностью во всей продуктовой экосистеме Built.

От извлечения на базе OCR к agentic document understanding

Традиционное извлечение документов с помощью OCR и ML обычно работает так: система находит текст и сопоставляет его с ожидаемыми полями, метками, макетами или ранее известными шаблонами. Это эффективно для структурированных документов, но ограничено там, где нужны суждение, контекст или доменное reasoning. Например, найти сумму кредита, номер инвойса или дату окончания полиса — относительно простая задача извлечения. Поле обычно явно обозначено и находится рядом с предсказуемым текстом. Но поиск covenants в кредитном соглашении — совсем другая задача.

Covenants часто не представлены в виде простой таблицы с заголовком «Covenants». Они могут быть разбросаны по нескольким разделам длинного договора. Они могут быть встроены в юридический язык, определяться через ссылки на другие разделы или выражаться как обязательства заемщика, ограничения, требования к отчетности, финансовые пороги, триггеры дефолта или remedies. Поиск по слову «covenant» может не уловить суть. Традиционная модель извлечения может найти слово, но не понять обязательство.

Agentic document workflow подходит к задаче иначе. Вместо того чтобы только извлекать поля из текста, система интерпретирует документ в контексте. Она может определить релевантные разделы, рассуждать о определениях и обязательствах, отличать требования от исключений, извлекать структурированный результат и предоставлять подтверждающие доказательства для проверки.

Для кредитного соглашения agentic workflow может:

1. Определить тип документа и структуру соответствующего соглашения.
2. Найти разделы, относящиеся к обязательствам заемщика, финансовой отчетности, ограничениям, дефолтам и remedies.
3. Вывести, какие пункты являются covenants, даже если они явно не помечены.
4. Извлечь название covenant, требование, порог, частоту, срок действия, ответственную сторону и последствия нарушения.
5. Сослаться на исходный документ для проверки человеком.
6. Направить неоднозначные или низкоуверенные результаты отраслевому эксперту.
7. Сохранить исправления и вернуть их в workflows схем, prompts и оценки.

Именно такой сдвиг был нужен Built: от document extraction к document understanding. Та же модель применима и в финансировании недвижимости. Агентам нужно понимать, соответствует ли страховое покрытие требованиям, содержит ли draw package нужные документы, подтверждает ли оценка assumptions андеррайтинга, содержит ли offering memorandum ключевые risk indicators или есть ли в документе портфеля исключения, требующие внимания. В каждом случае документ — это не только источник текста, но и источник бизнес-контекста.

Горизонтальное решение для agentic AI-дорожной карты Built Technologies

Built спроектировала новое решение document intelligence как горизонтальную возможность, а не как одноцелевую систему. Первый production use case был сфокусирован на коммерческих draw packages для строительных кредитов, где заемщики подают наборы документов для запроса выдачи средств в ходе строительства. Draw packages — хороший полигон, потому что они большие, вариативные, чувствительные ко времени и операционно важные.

При этом решение изначально проектировалось для всего рынка real estate finance. Одни и те же возможности classification, splitting, extraction, evaluation и human-review могут переиспользоваться в разных агентах и workflows, включая:

• Агенты для проверки draw, которые классифицируют содержимое пакета, находят недостающие документы, извлекают данные из инвойсов и lien waiver и отмечают исключения.
• Агенты по кредитным соглашениям, которые определяют covenants, требования к отчетности, финансовые пороги, ограничения для заемщика и положения о дефолте.
• Страховые агенты, которые валидируют certificates of insurance, декларации полисов, лимиты покрытия, endorsements, exclusions и даты окончания.
• Агенты андеррайтинга, которые суммируют offering memorandums, оценки, rent rolls, бюджеты и финансовые модели.
• Агенты управления активами, которые отслеживают текущие reporting packages, выявляют изменения и подсвечивают риски на уровне портфеля.
• Агенты compliance, которые проверяют обязательные формы, разрешения, отчеты об инспекциях и регуляторную документацию.

Каждый из этих агентов опирается на одну и ту же базовую способность: превращать неструктурированные, непоследовательные и объемные документы в структурированный, проверенный и объяснимый intelligence.

Сделав обработку документов общей платформенной возможностью, Built может ускорять AI-дорожную карту без необходимости заново строить extraction pipelines для каждого продукта. Новые агенты могут использовать ту же инфраструктуру для ingestion, classification, schema management, extraction, evaluation и review.

Разбор архитектуры: Intelligent Document Processing Accelerator и Amazon Bedrock

Built вместе с AWS GenAIIC и AND Digital построила решение на базе AWS Intelligent Document Processing (IDP) Accelerator. Для generative AI-обработки classification, splitting, generation схем, extraction, assessment и reasoning по документам используется Amazon Bedrock.

Решение использует многоступенчатый pipeline, оркестрируемый AWS Step Functions. Каждый документ проходит последовательность этапов: OCR, classification и splitting, extraction, assessment и, при необходимости, rule validation. Каждый этап реализован отдельной функцией AWS Lambda. Ниже показан этот pipeline на примере: коммерческий 150-страничный draw package для строительства приходит как один PDF, содержащий инвойсы, lien waiver, страховые сертификаты и сопроводительное письмо без определенного порядка.

На высоком уровне pipeline работает так. Документ, загруженный в входной bucket Amazon Simple Storage Service (Amazon S3), создает событие Amazon EventBridge. Функция Queue Sender Lambda записывает событие в tracking table Amazon DynamoDB и помещает сообщение в очередь Amazon Simple Queue Service (Amazon SQS). Функция Queue Processor Lambda управляет параллелизмом через атомарный счетчик DynamoDB и, когда есть доступная емкость, запускает для документа выполнение AWS Step Functions. Затем state machine последовательно запускает стадии обработки: OCR, затем classification и splitting, затем extraction, затем assessment и, наконец, process-results.

Extraction выполняется внутри состояния Step Functions Map, что позволяет обрабатывать классифицированные секции параллельно. Когда 150-страничный draw package разделяется на составные документы, каждая секция получает свой вызов extraction, который выполняется одновременно с остальными. Общее время обработки определяется самым медленным отдельным разделом, а не суммой всех разделов. Это одна из причин, почему workflows, ранее занимавшие дни, теперь завершаются за минуты. Результаты записываются в выходной bucket S3, а AWS AppSync передает обновления статуса в реальном времени в пользовательский интерфейс через GraphQL subscriptions.

Загрузка документов и интерфейс проверки

AND Digital создала пользовательский React-based интерфейс, аутентифицируемый через Amazon Cognito. Интерфейс дает пользователям единое место для загрузки документов, управления процессорами, определения схем, проверки результатов extraction, сравнения версий и просмотра confidence scores.

Пользовательский интерфейс был важен, потому что Built нужно было решение, подходящее как для технических пользователей, так и для отраслевых экспертов. Document intelligence нельзя управлять только силами инженерной команды. Лучше всех документы часто понимают специалисты по кредитованию, операционные команды, специалисты по compliance, product managers и customer-facing команды.

Когда пользователь загружает draw package, документ через pre-signed URLs сохраняется в Amazon S3, а событие загрузки Amazon EventBridge запускает pipeline. Слой параллелизма — атомарный счетчик DynamoDB вместе с очередью SQS — удерживает скорость запусков Step Functions в пределах лимитов сервисов Amazon Bedrock и Amazon Textract. Это позволяет одному и тому же пути обрабатывать как единичную ad hoc-загрузку, так и batch-прогон на 50 000 документов без изменений.

OCR и структурное извлечение

Когда документы попадают в pipeline, AWS Lambda запускает Amazon Textract для извлечения текста, таблиц, форм, подписей и структурной иерархии. Textract предоставляет документную структуру, на которую опираются downstream generative AI workflows для classification и extraction. Для больших документов система обрабатывает страницы по одной, что позволяет распараллеливание, но требует тщательного управления параллелизмом и throttling на масштабе.

На этапе OCR результат нормализуется в согласованную структуру, которую используют последующие этапы, фиксируя расположение raw text, parsed text и изображения страницы для каждой страницы в Amazon S3:

{
 "metadata": {
 "input_bucket": "<BUCKET>",
 "object_key": "<KEY>",
 "num_pages": "<NUMBER>"
 },
 "pages": {
 "1": {
 "rawTextUri": "<S3_URI>",
 "parsedTextUri": "<S3_URI>",
 "imageUri": "<S3_URI>"
 }
 }
}

Решение также может использовать Amazon Bedrock как альтернативный OCR backend для документов, где vision-capable model читает страницу надежнее, чем традиционный OCR, например для низкокачественных сканов или плотных рукописных пометок. Выбор OCR backend — это настройка, а не изменение кода, поэтому команды могут выбирать Textract или Bedrock для каждого процессора отдельно.

Интеллектуальная классификация и разделение

После OCR workflow классификации использует Amazon Bedrock, чтобы определить типы документов и найти границы внутри объединенных PDF. Это особенно важно в real estate finance, где один пакет может содержать множество документов в непредсказуемом порядке. Вместо отдельного splitter-а с жесткими ограничениями по страницам решение выявляет составные документы внутри больших пакетов и сохраняет их связь с более широкой сделкой.

Классификация управляется настраиваемым prompt, который перечисляет доступные типы документов и набор примеров. Разделитель prompt cache отделяет статические инструкции от текста документа, чтобы статическая часть могла переиспользоваться между запросами:

classification:
 task_prompt: |
 Classify this document into the following categories:
 {CLASS_NAMES_AND_DESCRIPTIONS}
 <few_shot_examples>
 {FEW_SHOT_EXAMPLES}
 </few_shot_examples>
 <<CACHEPOINT>>
 <document_content>
 {DOCUMENT_TEXT}
 </document_content>

Маркер <<CACHEPOINT>> и делает это эффективно на масштабе Built. Все, что находится до delimiter-а кэша, например определения классов и примеры, одинаково для каждого документа, который обрабатывает процессор, поэтому Amazon Bedrock кэширует это и переиспользует в запросах. Меняется только текст документа после маркера. Для draw-package процессора, который определяет дюжину или больше классов документов с примерами, это избавляет от повторной обработки одних и тех же инструкций на каждой странице каждого пакета.

Этап document splitting формирует структурированный результат, который сопоставляет диапазоны страниц с типами документов. Для примера draw package вывод группирует страницы в размеченные секции:

{
 "sections": [
 { "id": "group-001", "class": "CoverLetter", "pages": [1] },
 { "id": "group-002", "class": "Invoice", "pages": [2, 3, 4, 5, 6] },
 { "id": "group-003", "class": "LienWaiver", "pages": [7, 8] },
 { "id": "group-004", "class": "InsuranceCertificate", "pages": [9, 10] }
 ]
}

Каждая секция становится независимой задачей в Step Functions Map state, а extraction выполняется по схеме, специфичной для этого типа документа.

Динамическая генерация схем и extraction

Ключевая возможность решения — динамическая генерация схем. Пользователи могут загружать примеры нового типа документа, а Amazon Bedrock генерирует предложенную extraction-схему: поля, структуры и выходные данные, которые нужно извлечь из этого документа. Затем отраслевые эксперты могут доработать схему, протестировать ее на примерах, сравнить результаты разных версий модели и создать новые версии процессора.

Внутри каждый тип документа определяется JSON Schema, а описание каждого поля становится частью extraction prompt. Именно отсюда приходит значительная часть точности: описание поля, в котором указано, где именно обычно находится значение и как оно называется, направляет модель гораздо лучше, чем одно лишь имя поля. Например, схема lien waiver фиксирует тип waiver, contractor, project, применимый период, сумму и любые исключения:

classes:
 - $id: LienWaiver
 x-aws-idp-document-type: LienWaiver
 type: object
 description: >
 A lien waiver in which a contractor or supplier waives the right
 to file a mechanic's lien against the property for payment received.
 properties:
 WaiverType:
 type: string
 description: >
 The type of waiver: Conditional, Unconditional, Partial, or
 Final. Look for these terms in the heading at the top.
 ContractorName:
 type: string
 description: >
 The contractor or subcontractor signing the waiver. Usually in
 the 'From' or 'Claimant' field, or above the signature line.
 ProjectName:
 type: string
 description: >
 The project name or address. Look for 'Project', 'Job Name',
 or 'Property' labels.
 ThroughDate:
 type: string
 description: >
 The date through which the waiver applies. May be labeled
 'Through Date', 'Period Ending', or 'For Work Through'.
 AmountWaived:
 type: string
 description: >
 The dollar amount being waived, typically near the waiver
 statement.
 ExceptionItems:
 type: array
 description: Any exceptions or exclusions listed in the waiver.
 items:
 type: object
 properties:
 Description: { type: string }
 Amount: { type: string }

Аннотация x-aws-idp-document-type связывает схему с результатом классификации. Когда классификация помечает страницы 7 и 8 как LienWaiver, этап extraction загружает эту схему и строит prompt из описаний полей и OCR-текста этих страниц. Где нужна дополнительная опора, команды могут прикреплять few-shot примеры к классу — образец документа вместе с ожидаемыми атрибутами, чтобы показать требуемый результат для необычного макета.

Именно schema-driven подход делает поддержку более 250 типов документов практичной. Вместо ручного написания каждой схемы команды используют discovery-возможности Accelerator, чтобы сгенерировать первый черновик из образцов документов: загрузите один или несколько примеров, и Amazon Bedrock предложит схему с именами полей, типами и описаниями, которые эксперт затем доработает. Для массового онбординга решение может кластеризовать большую коллекцию образцов по схожести и предложить схему для каждого кластера.

Поскольку схема, prompts и модель — все это параметры конфигурации, Built может использовать гибкую модельную стратегию. Для простых документов, таких как стандартные инвойсы или страховые сертификаты, команды могут выбирать меньшие и более быстрые модели, например Amazon Nova Lite. Для документов, которые требуют более глубокого reasoning или более сложной интерпретации layout, таких как кредитные соглашения или offering memorandums, можно выбирать более крупные модели, например Anthropic Claude, доступные через Amazon Bedrock. Решение использует подходящую модель для нужного документа и workflow вместо того, чтобы пропускать все сценарии через один способ extraction.

Оценка уверенности, human review и feedback loops

Каждый результат extraction включает confidence scoring на уровне поля. Built требует более 95 процентов уверенности в ключевых production workflows, и результаты ниже порога направляются на human review.

Confidence scores поступают не из самого вызова extraction, а из отдельного этапа assessment. После extraction отдельный вызов Amazon Bedrock сравнивает извлеченные значения с исходным документом и OCR-текстом и для каждого поля выдает confidence score от 0 до 1, короткое объяснение и расположение подтверждающего доказательства на странице. Для lien waiver из примера assessment может вернуть:

{
 "WaiverType": {
 "confidence": 0.95,
 "confidence_reason": "Heading reads 'CONDITIONAL WAIVER AND RELEASE ON PROGRESS PAYMENT'",
 "geometry": [{ "boundingBox": { "top": 0.05, "left": 0.2, "width": 0.6, "height": 0.04 }, "page": 7 }]
 },
 "AmountWaived": {
 "confidence": 0.72,
 "confidence_reason": "Several dollar amounts on the page; value near the waiver statement chosen, but a handwritten notation is partially illegible",
 "geometry": [{ "boundingBox": { "top": 0.45, "left": 0.3, "width": 0.2, "height": 0.03 }, "page": 7 }]
 }
}

В этом примере тип waiver проходит порог, а сумма waiver — нет, поэтому документ отправляется на проверку. Ревьюеры работают в интерфейсе с двумя панелями: слева исходное изображение страницы с наложенными bounding-box, взятыми из assessment geometry и показывающими, где найдено каждое значение, а справа — извлеченные поля с цветовой маркировкой, чтобы значения ниже порога уверенности выделялись. Ревьюеры исправляют классификацию, обновляют значения и отмечают разделы как завершенные. Ролевой доступ удерживает это в порядке на масштабе. Ревьюеры обрабатывают документы в своей очереди, а администраторы управляют конфигурациями и пользователями.

Важно, что эти исправления не остаются только на уровне отдельного документа. Они возвращаются в базовые наборы данных для evaluation, поэтому тот же труд ревьюера, который исправляет один пакет, улучшает схемы, prompts и примеры для следующего. Такой human-in-the-loop процесс позволяет Built масштабировать автоматизацию, сохраняя экспертный контроль там, где он наиболее важен.

Reasoning по документам

Extraction отвечает на вопрос, что содержится в документе. Во многих workflows финансирования недвижимости нужно также ответить, соответствует ли документ требованию. Это разница между тем, чтобы просто извлечь лимит покрытия со страхового сертификата, и тем, чтобы определить, соответствует ли это покрытие условиям кредитного соглашения. Решение поддерживает это через workflow rule validation, который оценивает документы по бизнес-правилам в два этапа.

Сначала этап fact-extraction отправляет релевантные разделы документа в Amazon Bedrock и собирает факты, относящиеся к конкретной policy area, вместе со ссылками на места, где каждый факт был найден. Затем orchestration step рассуждает на основе этой отобранной доказательной базы и возвращает заключение — compliant, non-compliant или insufficient evidence — с цитатами на поддерживающие разделы. Сами правила выражаются в виде обычных вопросов, сгруппированных по policy classes, что делает их понятными для отраслевых экспертов:

policy_classes:
 - policy_type: "loan_covenants"
 questions:
 - "Does the document specify a debt service coverage ratio requirement?"
 - "Is there a minimum net worth maintenance clause?"
 - "Are there restrictions on additional indebtedness?"
 - policy_type: "insurance_requirements"
 questions:
 - "Does the coverage meet the minimum limits in the loan agreement?"
 - "Is the lender listed as an additional insured or loss payee?"

Разделение fact-finding и judgment и делает систему надежной на длинных и плотных документах. Этап fact-extraction концентрирует внимание модели на поиске релевантных пунктов в сотне страниц соглашения. Затем orchestration step может оценить доказательства, не отвлекаясь на остальной документ. Это тот же agentic-паттерн, о котором говорилось выше: поиск релевантных разделов, рассуждение об обязательствах и предоставление доказательств для проверки.

Почему совместные схемы и оценки критически важны

Чтобы agentic document processing работал в production, командам нужны не только prompts. Им нужны общие определения того, что следует извлекать, как выглядит правильный ответ, как измеряется точность и как изменения тестируются до внедрения.

Это особенно важно в real estate finance, потому что многие задачи извлечения специфичны для отрасли. Гибкая универсальная модель может понимать слова в кредитном соглашении, оценке или страховом сертификате, но командам Built нужны результаты, соответствующие бизнес-смыслу этих документов.

Решение дает техническим и нетехническим командам общее рабочее пространство для:

• Проектирования схем: определение полей, вложенных структур и выходных данных, которые нужны агентам.
• Тестирования extraction: прогон документов через процессоры и сравнение результатов.
• Процессов evaluation: измерение точности по размеченным примерам и ожидаемым ответам.
• Управления версиями: отслеживание изменений схем, prompts и конфигураций моделей.
• Человеческой обратной связи: фиксация исправлений ревьюеров и использование их для улучшения будущих результатов.

Именно это сотрудничество делает систему масштабируемой. Отраслевые эксперты могут формировать слой document understanding, не превращая каждое изменение в инженерный проект. Инженерные команды могут переводить эти определения в работу через версионируемые схемы, evaluation, model orchestration и workflows развёртывания.

В результате получается document intelligence-решение, которое со временем улучшается и может поддерживать широкий портфель AI-агентов.

Результаты и эффект

AI-powered document intelligence solution Built создает основу для более быстрых, точных и масштабируемых workflows в real estate finance.

Ключевые результаты:

• От дней к минутам: workflows классификации и extraction, которые раньше занимали 3–9 дней, теперь можно завершать за минуты на пакет.
• Поддержка сложных документов: решение может обрабатывать пакеты на сотни страниц, вложенные таблицы, встроенные изображения, сканы и нестандартные макеты, с которыми OCR-based системы работают плохо.
• Масштаб по типам документов: архитектура рассчитана на поддержку более 250 типов документов во всех workflows real estate finance. Production-нагрузка масштабируется до 20 миллионов документов в месяц, 300 000 документов в неделю и более 50 000 batch-processing прогонов.
• Горизонтальное переиспользование агентами: те же возможности document intelligence могут обслуживать несколько agentic AI-продуктов в строительном кредитовании, страховании, андеррайтинге, asset management, compliance и portfolio intelligence.
• Пропускная способность production-уровня: команда проверила pipeline на больших batch-прогонах и production-scale тестах, включая устранение throttling-ограничений Amazon Textract при обработке больших документов на высокой параллельности.
• Качество, управляемое оценкой: интеграция Built с workflows evaluation позволяет тестировать изменения схем, сравнивать поведение моделей и удерживать пороги confidence до выката в production.
• Доверие через human-in-the-loop: низкоуверенные или неоднозначные результаты направляются ревьюерам, что сохраняет экспертный контроль и снижает ручной труд.

Заключение

Сотрудничество Built Technologies, AWS GenAIIC и AND Digital показывает, как generative AI может трансформировать document-intensive workflows в real estate finance.

Используя AWS Intelligent Document Processing Accelerator и Amazon Bedrock, Built создала переиспользуемое решение document intelligence, демонстрирующее, как компании в сфере финансирования недвижимости могут модернизировать workflows обработки документов. Для Built эта возможность является фундаментом AI-стратегии. Document intelligence — это горизонтальный слой, который позволяет агентам понимать workflows real estate finance, выявлять исключения, ускорять принятие решений и превращать неструктурированные документы в доверенные бизнес-действия.

Чтобы узнать больше об использовании Amazon Bedrock для обработки документов, см. Document processing with generative AI on AWS.

Чтобы узнать больше о программе GenAIIC, см. AWS Generative AI Innovation Center.

Чтобы изучить возможности партнерства AND Digital с AWS, см. AWS alliance AND Digital.

Built — это AI-powered financial operations platform для индустрий недвижимости и строительства. Соединяя providers капитала, собственников и developers, а также строителей, Built автоматизирует workflows, ускоряет движение денег и информации и дает инсайты для более умных решений. Более 300 крупнейших финансовых институтов и тысячи собственников и строителей доверяют Built управление сотнями миллиардов долларов в real estate и construction activity, чтобы вы тратили меньше времени на процесс и больше — на progress. Подробнее на getbuilt.com.

Материал — перевод статьи с английского.

Оригинал: Built Technologies builds an AI-powered document intelligence solution on AWS to power agents across real estate finance