Изграждане на самоусъвършенстващи се данъчни агенти с Codex

Как Thrive Holdings и OpenAI съвместно разработиха Tax AI за счетоводителите на Crete, като обединиха експертизата на практиците с цикъл, задвижван от Codex

Системите от реалния свят се държат различно в production, отколкото в лаборатория, и се чупят по начини, които е трудно да се предвидят преди внедряване. Екипите често откриват тези проблеми след пускането, а след това прекарват седмици в разглеждане на гранични случаи, коригиране на подкани и превеждане на обратната връзка от production в трайни продуктови подобрения. Цикълът на обратна връзка е ръчен и бавен и се подобрява само когато инженер го придвижи напред. Но днес, с добре проектирана инфраструктура за оценяване, директен достъп до практици и реални среди и водещите агентни възможности на Codex, можете да изграждате агенти, които се самоусъвършенстват.

В тази публикация ще разгледаме как използвахме Codex, за да изградим такъв тип Агент. През последните шест месеца инженери и изследователи на OpenAI, изпратени на място, заедно с инженерите на Thrive Holdings, работиха съвместно за изграждането на Tax AI заедно със и за мрежата от над 30 счетоводни фирми на Crete⁠(отваря се в нов прозорец), за да помогнат при подготовката на все по-сложни данъчни декларации. Вместо да разчита на инженери да намират и поправят всеки проблем, Tax AI използва Codex, за да превръща използването в production в структурирани сигнали, които захранват автономното подобрение.

Практиците в Crete подготвят десетки хиляди данъчни декларации всеки сезон, което изисква работа с милиони базови документи. При декларации със средна до висока сложност само въвеждането на данни може да отнеме осем часа на декларация и често включва неструктурирани източници на данни, документи от предходната година и ръчно извличане и изчисление. Те ни посочиха данъчната подготовка като значително тясно място в най-натоварения период на данъчния сезон.

За да реши този проблем, Tax AI обработи 7 000 данъчни декларации в рамките на фирмите на Crete, участвали в пилота през този данъчен сезон. Системата автоматизира голяма част от отнемащия време процес по подготовка на данъчни декларации 1040 и 1041, но още по-впечатляващо от повишението на ефективността е, че самата система е измеримо по-добра от версията, внедрена за първи път преди три месеца.

В Tax AI практиците качват изходни файлове заедно с всички бележки, специфични за клиента. След това Tax AI създава подаване към данъчния енджин, готово за преглед. Това спестява на практиците около една трета от времето им за данъчна подготовка, изготвя декларации с точност до 97% и увеличава производителността с около 50%, като им оставя повече време за работа с клиенти. 

Можем да измерим това подобрение, като разберем колко точно Tax AI може да попълни една декларация, без по-късно да е нужна корекция. Измерваме точността, като проверяваме какъв дял от декларациите достигат 75%, 90% или 100% правилно попълване на полетата. При старта само една четвърт от декларациите достигаха 75% правилно попълване на полетата, но в рамките на шест седмици 86% достигнаха тази стойност. Системата показа още по-бърз растеж при нивата от 90% и 100% правилно попълване на полетата. Тези прагове ни дават практическа представа колко последваща работа от практик все още изискват различните декларации. 

В началото Tax AI се справяше с по-проста работа, като W-2 и 1099. С напредването на сезона той премина към по-сложни декларации с K-1, приложения и по-трудни гранични случаи. Всяка нова способност спестяваше повече време на декларация от предишната, защото задачите, които поемаше, бяха по-трудни и по-отнемащи време за ръчно изпълнение. Продължаваме да наблюдаваме постоянен напредък и днес.

След това ще разгледаме как нашите екипи съвместно проектираха Tax AI така, че да се самоусъвършенства, опирайки се на три критични стълба: 1) обратна връзка от експертни практици, 2) производствени следи (структурирана история от входовете до крайния изход) и 3) цикъл на итерация, задвижван от Codex, базиран на специално пригодени evals, за да се позволи непрекъснато и по-бързо продуктово развитие. Надяваме се нашият опит да бъде полезен и за други създатели в области, където експертизата на практиците е ключова за оформянето на качеството на цялостната система и на данните, които преминават през нея.

Когато навлязохме в по-трудните части на данъчната подготовка (K-1, приложения за недвижими имоти под наем и данъчни формуляри, при които стойностите трябваше да се съгласуват между множество изходни файлове), стана очевидно, че истинското предизвикателство е дали продуктът може да направи сложните проблеми в production видими, разбираеми и приложими.

В ранните дни на продукта по-голямата част от корекциите беше ръчна. Практиците можеха да коригират грешките на системата, но продуктът не улавяше пълния контекст: променена стойност преди подаване можеше да отразява истински пропуск при извличането, проблем при съпоставянето, липсваща продуктова поддръжка или очакван шум в работния процес. Разграничаването на тези случаи все още изискваше последваща работа от инженерния екип. Инженерите можеха да използват кодиращи агенти, но системата все още не беше проектирана да използва AI смислено вътре в цикъл на подобрение. Нямахме сигнала, за да определим правилния връх за изкачване.

Това ни доведе до проектирането на системата около три стълба:

1. Бъдете близо до практиците: Хората, които вършат работата, трябва да насочват какво научава продуктът. Тяхната интуиция и разбиране разкриват кои грешки имат значение и помагат да се определи върху кои части от работния процес си струва да се фокусираме след това.
2. Изградете продукта така, че production да създава доказателства: Продуктът трябва да улавя повече от входове и изходи; той трябва да улавя целия път от изходния материал, през извлечените полета и произхода им, до последващото подаване и експертната корекция.
3. Създайте цикъл на подобрение, задвижван от Codex: След като проблемите в production станат видими и структурирани, те могат да се превърнат в находки, специално пригодени evals и ограничени инженерни задачи. След това Codex може да помогне за разследване, предлагане на промени, валидирането им спрямо целеви и регресионни evals и придвижване на продукта напред по-бързо от изцяло ръчен цикъл на итерация. 

Примерът с имотите под наем по-долу показва как този цикъл работи на практика, като ви превежда през това как корекция от практик се превръща в структурирана находка, после в цел за оценяване и накрая в ограничена инженерна задача за Codex.

Доходът от имот под наем се отчита в Schedule E на индивидуална данъчна декларация. От инженерна гледна точка задачата по извличането му е лесна за описание, но трудна за добро изпълнение. Системата трябва да чете неструктуриран изходен материал (ръкописни бележки, имейли, електронни таблици и други клиентски файлове), да извлича полетата за имота под наем, които системата може уверено да съпостави към данъчния енджин, и да запази достатъчно доказателства, така че практик да може да одобри или коригира резултата. Опростеният пример по-долу показва как биха могли да изглеждат тези изходни файлове и извлечени резултати.

Разлика между стойността, предвидена от Агента, и действителната стойност от подадената данъчна декларация може да отразява истински пропуск при извличането, но може също да е предпочитание на практик, стойност, пренесена от декларация за предходна година в данъчния енджин, или стойност, въведена или променена другаде в работния процес по подаване. Практиците ни помогнаха да разграничим тези случаи, за да установим кои действия са изисквали корекция от практик или са блокирали подаването.

Тъй като можехме да виждаме тези корекции в детайл, преобразихме процеса на преглед от крайна стъпка след неуспех в непрекъснат цикъл на учене. Проектирахме работния процес така, че да улавя действията на експертите като структурирани данни. Сега всяка намеса захранва цикъла за подобрение на продукта, като записва точно какво е предложил Tax AI, какво е променил практикът и какво в крайна сметка е влязло в подадената декларация.

При сложен работен процес като този за имоти под наем системата трябва да запази какво се случва между изходните файлове и подадената декларация. По този път документите се организират, разделят и класифицират; полетата за имоти под наем се извличат с цитати обратно към изходния материал; тези стойности се съпоставят към данъчния енджин; и практиците все още могат да ги коригират преди подаване. Тези следи на ниво продукт правят възможно разследването къде е възникнал проблемът. За да превърне корекциите от практици в полезни цели за оценяване, системата ги обработва в три стъпки:

• Улавяне на разликата: Изходът на Tax AI се сравнява с подадената декларация, за да се създадат редове за преглед на ниво поле, които улавят очакваната стойност, предвидената стойност и дали разликата изглежда приложима.
• Групиране на свързани проблеми: Подобни редове за преглед се групират, за да се отделят повтарящите се продуктови проблеми от очаквания шум в работния процес. Например повтарящи се корекции от практици могат да покажат, че Tax AI често пропуска полетата за „дни на справедлив наем“, обработва неправилно „други разходи“ или обърква множество имоти под наем в рамките на един и същ пакет източници.
• Превръщане на повтарящите се модели в цели за оценяване: След като бъдат прегледани и измерени, повтарящите се находки се превръщат в ясни цели за оценяване, които Codex да подобри.

Третият стълб е създаването на инженерен цикъл, способен да действа върху тези нови evals. Тук Codex става централен.

Да предположим, че нашият eval pipeline отбелязва, че Tax AI последователно пропуска полето „дни на справедлив наем“, докато практиците надеждно го попълват. Тъй като тази находка вече е пакетирана в целеви набор за оценяване, с представителни пакети източници и очаквани изходи, Codex може да разследва първопричината директно в рамките на продуктовия скелет.

Codex не работи само с незадоволителен краен изход. Той разглежда заедно следата, eval, хранилището и уменията:

• Разследване на pipeline-а: Проверка на пакетите източници, схемите за извличане, поведението на mapper-а и кодовите пътища, за да се определи дали проблемът е неподдържано поле, пропуснат модел на извличане, проблем при избора на източник, пропуск в mapper-а или проблем с grader-а.
• Прилагане на целеви корекции: Разширяване на схемата за извличане, подобряване на избора на източник за документи за имоти под наем, актуализиране на mapper-а за данъчния енджин или прецизиране на grader-а, ако очакваният шум в работния процес се отчита като проблем.
• Валидиране и предлагане: Повторно изпълнение на целевото оценяване, пускане на по-широки регресионни набори и показване на кандидат pull request за инженерен преглед.
• Затваряне на цикъла: Превърнете повтаряща се корекция от практик в измерима инженерна задача. Ако доказателствата са нееднозначни или не могат безопасно да се автоматизират, случаят се връща към продуктовия екип, вместо да бъде насилствено прекаран през цикъла.

Примерът с имотите под наем е показателен за по-широк, повторно използваем модел: използване на производствени артефакти и следи за подобряване на способностите на един Агент. Като се дадат прегледани находки от производствени данни, изходни следи, очакван изход от данъчния енджин, релевантни примери за код и команди за оценяване като набор от входове, Codex може съществено да подобри производителността и точността в рамките на седмици и месеци. Това стъпва върху принципите, описани в нашата работа по harness engineering и Symphony, които показват как задачите да станат разбираеми за Codex, как да се осигурят ограничен контекст и инструменти и как валидирането и човешкият преглед да останат част от средата. 

Тези доказателства не се превръщат автоматично в задача за Codex. Корекция от практик може да отразява пропуск при извличането, проблем при съпоставянето, неподдържано продуктово поведение, данъчна преценка или очакван шум в работния процес. Едва след като повтарящите се разлики бъдат прегледани и групирани в приложима находка, системата ги превръща в ограничена задача с ясно условие за успех.

Прилагаме тази автоматизация към ограничен слой от продукта. Този слой извършва извличане и съпоставя изходните документи към данъчни работни процеси. Инженерите остават отговорни за архитектурата, продуктовите решения и внедряването. Практиците насочват цикъла на подобрение чрез работата, която вече вършат: коригиране на извлечени стойности, преглед на декларации и одобряване на окончателни подавания.

За Codex резултатът не е неясно предупреждение, а ограничена инженерна задача с доказателства, редактируеми продуктови повърхности и изрични валидиращи бариери. Контекстът за представителна задача за имот под наем може да бъде обобщен така:

Същият цикъл се прилага и извън имотите под наем. Имотите под наем отнеха около шест седмици и значителен инженерен надзор, за да достигнат 90% прецизност и пълнота, но тази работа създаде повторно използваеми абстракции, артефакти за преглед, конвенции за оценяване и модели за имплементация, които улесниха поддръжката на сходно сложни приложения като Schedule C и Schedule A.

Tax AI доказва път към изграждането на самоусъвършенстващи се агенти. Практиците генерират сигнали за обратна връзка с висока стойност, като предоставят услугата. Продуктовите работни процеси запазват тези сигнали като структурирани доказателства. Инженерните системи, подкрепени от evals, валидират подобренията, преди да стигнат до production, а цикъл, задвижван от агент, поддържа системата в непрекъснат поток на самоусъвършенстване. 

Структурата на Thrive Holdings ни позволява да възпроизвеждаме тази среда в конкретни индустрии. Holdings е едновременно собственик и Operator, така че обединените ни инженерни екипи могат да работят директно с практици и производствени данни вътре в бизнеси като Crete не като доставчик, а като партньори. Това означава, че технологията, продуктът и услугата са под един покрив, за да ни помогнат да се движим по-бързо и да изграждаме изключителни продукти.

Една старша счетоводителка, която миналата година е прекарала 180 часа в данъчна подготовка, тази година е прекарала само 15 часа. Тя използва част от това време, за да се обади на всеки свой клиент и да го преведе през декларацията му — ниво на персонално обслужване, което преди година не беше възможно. Останалата част от това време тя използва, за да поеме нови клиенти и да разшири предлаганите услуги.

Заедно нашите екипи вече използват същия тричастен дизайн от Tax AI като план за изграждане на работни процеси в други области в Thrive Holdings⁠(отваря се в нов прозорец); счетоводни работни процеси като водене на счетоводство и одит, и оперативни работни процеси като автоматизация на IT help desk. В различни области и индустрии по-широкото обещание на самоусъвършенстващите се агенти остава валидно. Най-добрите агенти се насочват от хора, за да се учат и с времето да стават по-способни, по-доверени и по-ценни.

За да научите повече за екипа на OpenAI, работил по този проект, свържете се с нас.