Как оптимизировать расходы при работе с GPT API

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

Но сначала рассмотрим пару примеров того, что вообще такое неоптимизированное использование API-обращений — чтобы каждый мог понять, о чем идет речь.

Примеры неоптимизированной работы через API

Сразу заметим, что, применительно к оптимизации взаимодействия по API, у слова «оптимизация» может быть три смысла:

• Оптимизация быстродействия — когда в приоритет ставится скорость получения ответа нейронки. Обратите внимание — именно получения ответа, а не скорость ответа. Это важно.

• Оптимизация эффективности — а вот тут речь уже и о скорости ответа в том числе. Впрочем, упор все же делается не только на скорость ответа, но и на его релевантность. То есть смысл данной оптимизации в том, чтобы ИИ максимально быстро дал наиболее четкий ответ.

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

Теперь, когда мы определились с тем, о какой именно оптимизации идет речь, приведем примеры того, как это бывает в реальности.

Пример из SEO

Допустим, вы — SEOшник. Начитались статей про нейронки и решили генерировать title и description для пачки страниц. В большинстве случаев далекие от алгоритмизации пользователи, даже если они имеют опыт программирования, выстроят схему по типу:

1. Промпт.
2. Страница N.
3. Возвращение к шагу 1.

Казалось бы, а как еще проанализировать 100 страниц? Однако гораздо эффективнее, если схема выглядит примерно вот так:

1. Промпт.
2. Список страниц 1–100.

Такой подход называется батчинг.

На всякий случай напомним, что речь идет про обращения по API. При работе через окно чата эта инфа не будет актуальной. Но почему это дешевле? Разве ChatGPT не анализирует в обоих случаях одно и то же количество страниц? Да, но нет. Во-первых, при API-взаимодействии вы платите как за входные токены, так и за выходные. И очевидно, что 1 входной будет стоить дешевле 100.

Во-вторых, как бы странно это ни звучало, нейронка действительно не перебирает 100 раз по 1 странице — она анализирует 1 раз сразу 100. На уровне физических протоколов, разумеется, это все еще будет 100 по 1 разу. Но на уровне архитектуры самой нейросети — это 1 сессия сразу на весь массив.

Ну и в-третьих, вам не придется каждый раз платить за обработку одного и того же промпта. Если задача шаблонная (а другие по API, за редким исключением, в общем-то и нет смысла реализовывать) — то зачем ее каждый раз повторять? Вдобавок, единый промпт минимизирует количество аномалий. Проще говоря, все 100 страниц будут проанализированы одним и тем же образом, а не «чуть-чуть иначе» из раза в раз.

Анализ тональности клиента

Допустим, вы ведете с клиентом коммуникацию в чате или ЛС. Неважно — продажи ли это, адалт-переписка или прогрев в гембле, суть в другом. Вы решили автоматизировать анализ тональности и закинули все это дело (переписки) в нейронку. И, допустим, вы даже начали закидывать все это пачкой, вместо того чтобы закидывать каждый чат или того хуже — каждое сообщение отдельно.

Чаще всего это выглядит примерно так:

1. Переписка ID и промпт.
2. Получение ответа.
3. Переход к переписке со следующим ID.

Визуально может казаться, что все супер — ведь у нас нет постоянного повтора одного и того же промпта. Однако на деле он есть — просто он вшит в запрос, передающий нейронке содержимое переписки.

В данном случае правильнее организовать свои скрипты следующим образом:

1. Переписка ID-1 — Переписка ID-N.
2. Промпт.
3. Получение ответа.

В этом случае нейронка сначала анализирует содержимое коммуникации, а лишь после этого определяет тональность для каждой из переписок. При этом токены не расходуются на интерпретацию одного и того же промпта.

Парсинг

Приведем еще один пример, актуальный для тех, кто парсит большие объемы инфы. Для упрощения понимания сути пусть это будут HTML-страницы из какой-то социальной сети. Но вообще речь об абсолютно любом парсинге.

Допустим, нам нужно собрать базу юзеров из какого-то ГЕО и сегментировать их по полу и возрасту. Как поступит большинство? Правильно, накатает скрипт с примерно следующей логикой:

1. Страница N.
2. Парсинг ГЕО, возраста и пола.
3. N=N+1 и возврат к шагу 1.
4. Сегментирование.

Однако даже несмотря на указание полей, которые нужно парсить, нейронка будет анализировать всю страницу. Иначе говоря, вся постобработка будет происходить на стороне ИИ. Стоит ли говорить, во сколько раз (десятков раз…) вырастет расход токенов? Поэтому куда рациональнее использовать что-то вроде:

1. Страница N.
2. Удаление мусора.
3. Парсинг ГЕО возраста и пола.
4. N=N+1 и возврат к шагу 1.
5. Передача инфы в нейросеть.
6. Сегментирование.

Подход может быть реализован и иначе, главное, чтобы не было постобработки на стороне нейросети там, где это можно реализовать на стороне скрипта.

Важно!

Следует уточнить, что примеры выше не стоит рассматривать как инструкцию. В вопросах оптимизации ключевое — не следование шаблонам, а понимание происходящих процессов. Суть не в том, можно ли генерировать title без батчинга, а в том, чтобы исключить ненужные действия, съедающие токены. Ведь все это перекладывается на бюджет.

Основные принципы оптимизации

Кроме всего прочего, важно понимать, что приведенный выше список примеров далеко не исчерпывающий. В реальности ситуаций неоптимизированной работы через API сотни тысяч, если не миллионы — и все они уходят очень далеко от алгоритмических ошибок, описанных ранее. Поэтому важно понимать основные принципы оптимизации и включать фантазию. Но если фантазия остается на откуп читателя, то основные принципы мы сейчас приведем.

Ключевое, что следует запомнить:

• Одна ошибка = миллиард ошибок — если есть хотя бы базовые арифметические вычисления, то наличие даже одной ошибки чревато лавинообразным ростом числа других ошибок. Поэтому крайне важно убедиться, что все исходные данные передаются в нейросеть корректно.

• Чекать статку — да, и тут статка. Такая лайф. А если серьезно, то это нужно для своевременного выявления и фикса аномалий. Причем в случае с нейросетями это особенно важно, ведь аномалии могут быть как из-за ошибок в работе ваших скриптов, так и из-за чего-то неведомого пользователям. Условно, даже если вы четко прописали 2+2=4, а ИИ вдруг начнет считать, что 2+2=5 — в ваших же интересах своевременно это выявить, чтобы не сливать бюджет в пельменную.

• Единообразие данных — вообще, это актуально при работе с любой программой. Ведь чем разношерстнее инфа, тем больше ненужных операций. Но в случае с ИИ все будет бить по вашему карману. Поэтому при работе с большими объемами данных сначала приводим все к единому стандарту, и лишь затем передаем в нейронку по API.

• Пакетная обработка — помимо упомянутого ранее батчинга, также следует ориентироваться на пакетную обработку. В подавляющем большинстве случаев это дешевле прямых обращений. Кроме того, пакетная обработка позволяет выполнять несколько разных операций одновременно. Правда, такая потребность возникает не у всех. Но если она возникла — имейте это в виду.

• Подходящая модель — многие пользователи зачем-то выбирают самую топовую модель там, где с легкостью справится GPT 3.5 или даже другая, более примитивная нейросеть. Это как если бы вы хотели, чтобы статью писал директор медиа. Он-то напишет — но зачем переплачивать?

• Сухость данных — не нужно думать, что нейросети есть дело до вашей вежливости. В API-запросах уж точно нет — ведь это ровно то же самое, как если бы вы желали приятного дня после каждого сообщения в Телеге, при том, что за час слали бы десятки тысяч сообщений. Данные должны быть сухими — это и риск ошибок снизит, и процесс удешевит.

Теперь, когда основные принципы вам известны, перейдем к алгоритмам экономии.

Алгоритмы экономии

Сразу уточним, что все эти алгоритмы — для скриптов на вашей стороне. То есть ДО отправки инфы в GPT. Вообще, они могут использоваться и после получения ответа — но, опять же, лишь в том случае, если вы собираетесь еще раз отправить в GPT инфу из ответа после своих манипуляций с ней.

Собственно, сами алгоритмы, точнее, их виды:

• Кластеризация — тема кластеризации данных, по-хорошему, заслуживает отдельной статьи, настолько много разных крутых алгоритмов кластеризации изобретено. Загвоздка, что занимательно, заключается в том же самом — в их количестве. Алгоритмов кластеризации потому и много, что для каждого случая нужен свой. И тот, что был эффективен при решении иных задач, может оказаться бесполезным в текущей. В общем, кластеры кластерам рознь. Если вы хотя бы примерно понимаете, зачем оно вам — советуем все же разобраться глубже и найти подходящий алгоритм. Если не понимаете — просто скипайте и переходите к следующему пункту. Для работы с текстовыми данными советуем алгоритмы K-Means, DBSCAN и Hierarchical Clustering.

• Регулярные выражения — по какой-то неведомой причине базовая база кодинга очень часто игнорируется при работе с нейросетями. Алгоритмов для работы с регулярными выражениями бесконечное множество. Поэтому просто напомним, что они есть и их можно и нужно использовать. Ну и для работы с текстом все же советуем Rule-based NLP и Keyword Detection. Ибо зачем вам GPT, чтобы понять, что отзыв, состоящий из «Супер! Рекомендую!» — положительный?

• Семантическая дедупликация — очень часто, в особенности если речь о какой-либо вспомогательной информации, одни и те же данные многократно дублируются. Например, если вы анализируете переходы из In-App, то прила, из которой был переход, может дублироваться в списке установленных прил. А зачем анализировать одну и ту же инфу? Помочь убрать дупликацию могут такие алгоритмы, как Cosine Similarity, FAISS и Annoy.
  

  

• Фильтрация нерелевантного — существует множество способов исключить «мусорную информацию» из пула данных, отправляемых вами в GPT по API. Так, например, зачем вам анализировать отзыв, содержащий только ссылку, если это очевидный спам? Помочь с этим могут такие алгоритмы, как Heuristics, LangDetect, TextLength thresholding и им подобные.

• Семантическая компрессия/реферирование — если вам приходится работать с большими объемами человеческого текста, например, длинными отзывами, то нет никакого смысла тратиться на обработку каждого слова. Куда проще предварительно обработать текст с помощью алгоритмов Automatic summarization и закидывать в GPT что-то вроде краткой выжимки. На результатах маркетинговых исследований это практически не скажется, а бюджет сэкономит.

К сожалению, привести алгоритмы на все случаи жизни мы не можем. Но статья написана и не для этого. Ее цель — показать, что расходы на обработку API-запросов можно многократно снизить. И даже изобретать велосипед для этого не нужно: большинство алгоритмов предобработки информации были изобретены задолго до появления нейросетей. И можно было бы на этом закончить, но куда же без мифов?

Мифы про нейросети

Собственно — мифы:

• Инглиш рулез — вопреки популярному заблуждению, перевод данных на английский не только не помогает обрабатывать их эффективнее, но еще и создает риск появления ошибок из-за перевода. GPT обучали не только на английском. И большинство языков мира для этой нейросети «родные».

• Temperature=0 — это мастхэв — а вот и нифигашеньки. Конечно, мы не призываем сразу ставить 1, и уж тем более >1. Но что-то в районе 0,3–0,7 (в зависимости от специфики вашего проекта) — всегда лучше, чем 0. Реальная потребность в Temperature=0 встречается крайне редко.

• Нужно регулярно освежать контекст — не нужно. Достаточно один раз правильно задать системный промпт. Можно вообще вынести его в переменную и не трогать, пока не сменится задача. Обновление контекста при работе по API — это пустая трата денег — не более того.

• Лучше кидать по 1 шт. — выше мы уже писали про батчинг, но повторим еще раз. Не нужно закидывать запросы по одной штуке там, где их можно закинуть пачкой. Не «перегрузится» GPT от этого. Нейронка одновременно обрабатывает миллиарды сессий по всему миру. А вы переживаете о том, что ваши 100 HTML-страничек взорвут ей мозг.

• Нужно быть вежливым, тогда GPT вас пощадит — без комментариев.

Подводя итоги

Надеемся, наша статья помогла вам понять, что способно сэкономить ваши деньги, а что — бесполезно. Но даже если вы пока не поняли, как все это применить — не страшно. Куда важнее то, что вы вообще задумались об оптимизации взаимодействия по API. А значит, рано или поздно что-то вы нет-нет да оптимизируете. И это уже круче, чем бездумно сливать бюджеты. Главное, помните, что оптимизация — это не про выполнение шаблонных инструкций, а про глубокое понимание процессов и творческий подход к их доработке.