Защо записваме работата на AI асистентите на собствената си машина

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

Около тези въпроси изградихме системата си за наблюдение. Техническият термин е observability: събиране на достатъчно информация за работата на системата, за да можем после да разберем какво е станало вътре. Използваме Langfuse на собствената си машина.

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

Системата вече ни принуди да поправим допускания за пълнотата на записите, отчитането на разходите и поверителността. Показа ни и друго: „записваме всяка стъпка“ е намерение, което трябва да проверяваме. Наличието на табло с данни само по себе си не го доказва.

Какво всъщност се записва

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

Влизат и блоковете с разсъждения, които присъстват в транскрипта, работата на подагентите и означенията на използваните умения. Подагентът е допълнителен асистент, на когото е възложена част от задачата. Записът показва достъпната история на изпълнението, но не дава пълен достъп до вътрешното мислене на модела.

Изображения, поставени в разговора или върнати от инструмент, също могат да се запазят като файлове. Ходовете са групирани по сесия, за да проследяваме развитието на работата, вместо да гледаме отделни несвързани събития.

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

Смисълът е после да можем да прочетем и анализираме събраното. Кои сесии са изразходвали най-много ресурс? Къде дадено умение не се е справило? Какво е станало при работата с конкретни инструкции? Без тази възможност получаваме място за съхранение, което трябва да поддържаме, но малко помощ за решенията си.

Защо държим записите при нас

Решението за собствен хостинг дойде от съдържанието на трасетата. Изходът на инструмент може да съдържа клиентски документ или работна чернова. Изпращането на такъв запис към външна услуга създава още едно копие извън нашата машина.

Затова избрахме локален Langfuse вместо облачната му услуга. Лимитът за събития в разглеждания облачен вариант също имаше значение. Решаващият въпрос обаче беше къде ще стоят материалите.

Това описва пътя на данните за наблюдение. Не означава, че локалното съхранение на трасетата прави всяка AI операция локална или че никакви данни не стигат до доставчика на модела. Това са отделни потоци, за които трябват отделни решения.

Стекът работи с Docker, който организира помощните услуги в изолирани приложения, наречени контейнери. Уеб интерфейсът, фоновата обработка, базите данни и файловото хранилище работят заедно на машината. Премахнахме ненужните външни портове на базите, така че услугите да общуват вътре в стека.

Собственият хостинг означава и собствена поддръжка. Стекът трябва да е включен, когато към него се изпращат записи. Дисковото пространство също изисква внимание. Приехме тази отговорност, защото алтернативата променяше местоположението на записи с клиентско съдържание.

Локално не означава автоматично поверително

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

Ограничихме интерфейса до самата машина и изключихме регистрацията. Записаната проверка потвърди, че локалният достъп работи, а мрежовият адрес е недостъпен. За регистрацията проверихме настройката, без да създаваме реален акаунт.

Трябва да сме точни и за поправката, и за проверката. Твърдението „хостваме локално“ не би обяснило този риск. А твърдението „всичко е проверено“ би преувеличило проверката на регистрацията.

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

В досието ни има предложение първо да се проверят записите за чувствителни идентификатори и ключове и да се преброят съвпаденията, а после да се реши кои правни проекти да се изключат. Наличните записи не потвърждават, че проверката и изключването са изпълнени. Потвърдената защита е ограничението на мрежовия достъп. То не ограничава какво клиентско съдържание се записва. Същото важи за изображенията, които могат да запазят цял документ, докато вниманието е насочено към текстовите полета.

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

Как открихме липсите в самото записване

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

Без тази проверка сесията можеше да изглежда завършена, а последната дейност да липсва. Това отслабва всеки последващ анализ, особено ако точно там са били финалната проверка или резултатът.

Установихме и какво става, когато локалният стек не работи. Изпращането се повтаря за кратко, но няма локална опашка, която да пази трасето за по-късно. Записът се губи. Работата на асистента продължава.

Приехме този компромис, вместо да поддържаме допълнителен механизъм за отложено изпращане. Затова трасетата са полезни оперативни доказателства с известни пропуски. Не ги представяме като гарантирано пълен одитен запис.

В нерешените въпроси е посочена и необходимостта да се провери покритието на автоматичната работа през Agent SDK, библиотеката за стартиране на асистенти от код. Настройка, която работи в терминална сесия, не доказва, че фоновият процес изпраща същите записи.

Когато екип твърди, че всичко се записва, бих попитала как е проверил края на сесията, фоновите задачи и периода, в който събиращата система е била недостъпна.

Наложи се да поправим и сметките

Интеграцията с Codex показа, че повече телеметрия не означава по-ясна информация. Телеметрията е поток от данни за действията на програмата. При локалния ни опит заявка за отговор от една дума произведе около 1000 спана, тоест отделни записани операции.

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

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

Трябваше да избегнем и повторното броене на токените за разсъждение, когато вече са включени в изходните токени. Иначе една и съща работа изглежда по-скъпа само защото сме изпратили застъпващи се полета.

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

Качеството не се свежда до по-евтина сесия

Искахме доказателства и за качеството. Скриптът за оценяване чете транскриптите и отчита дали тестовете са минали при първото пускане и колко забележки е върнал рецензентът. Това са наблюдаеми събития, които така или иначе възникват в работата.

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

Така по-чистият отчет не подменя случилото се. Неизвестният резултат трябва да остане неизвестен. Иначе показателят започва да възнаграждава липсите в записа.

Сравненията между модели също искат контекст. В нашите бележки изрично е отбелязано, че задачите не са съпоставими: Codex получава по-тесни, предварително планирани стъпки. По-добър резултат при първо пускане на тестовете в такава среда не доказва универсално по-добър модел.

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

Да запазим наученото, без да пазим всичко

Локалното съхранение направи срока на пазене практически въпрос. При измерването ни вътрешните системни логове на ClickHouse бяха достигнали 6.0 GiB, срещу 1.9 GiB данни от трасета. ClickHouse е базата, която използваме за аналитичните записи. Нейните собствени служебни логове се оказаха отделен източник на растеж.

За тях приложихме срок на пазене от 7 дни. Това е различно от решението колко дълго да пазим трасетата, с които изследваме работата на асистентите.

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

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

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

Какво означава това за собственика

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

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

Ако не можете да обясните какво са направили AI асистентите ви, откъде идва отчетеният разход или къде стоят записите им, можем да разгледаме процеса в безплатен одит. Ще определим какви доказателства ви трябват за оперативните решения и кои данни е по-добре изобщо да не копирате в системата за наблюдение.