Как минимум я видел перевод статьи от одного из работников Google, который рассказывал про карьерный рост менеджеров в компании через внедрение новых фичей. Если ты будешь просто оптимизировать сервис, ты повышение не получишь. Отсюда периодические переделки интерфейса, появление новых фичей и т.д. - и проблемы с тормозами приложения, которые в последствие могут еще и усиливаться.
Вы можете загрузить в чат полное собрание сочинений Достоевского или весь роман "Евгений Онегин" и попросить ИИ найти все упоминания конкретных деталей гардероба героев. Или загрузить выгрузку метрик вашего сайта за год, чтобы алгоритм составил подробный план по SEO-оптимизации. Нейросеть найдет нужную информацию со стопроцентной точностью.
Не понятно, почему все приводят в качестве плюсов возможность однократно загрузить какой-то большой объем данных. Ведь в дальнейшем в диалоге при каждом запросе окно будет заполняться промтом, контекстом диалога. а так же всеми данными которые были загружены в память ранее. И миллион токенов или даже два не кажется чем-то реально крутым - ведь пользователь будет каждый раз платить за все эти сотни тысяч сохраненных в контексте токенов. Тем более что насколько я помню, ИИ обрабатывает данные отдельными батчами.
Статья говорит о проблеме фокусируясь в основном только на одной из причин - некомпетентности разработчика. Тогда как половина причин, а может и больше это хотелки бизнеса или внутренняя парадигма организации. Разработчик может и хочет что-то там ускорить, но всегда ли ему дадут это сделать?
На рынке конкуренция и надо выпустить MVP быстрее конкурентов? - Нафиг оптимизацию, делаем рабочий прототип на %известный фреймворк% и в продакшн. Оптимизируем потом с ростом нагрузки.
Клиенты жалуются на тормоза приложения? - Подтяните основные метрики. Если надо добавим ресурсов.
70% запросов жрет аналитика? - Ну простите уж, нам надо собирать много, много данных.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
А потом в Gmail тормозит интерфейс так, словно они майнят на клиенте крипту. Не думаю что в Google работают отбитые вчерашние ученики курсов, которые не могут посмотреть вне абстракции.
Хотя, причем тут ученики курсов. Тут затрагиваются архитектурные вопросы, к которым у джунов по идее не должно быть доступа. Джун не должен проектировать структуру БД. Это задача сеньора, который потом должен бить по рукам тех, кто пишет херовый код или запросы.
Желательно: поднимите публичный узел, если у вас есть сервер или белый IP. Каждый новый узел в России - это ещё одна точка, которую сложнее вырубить одним решением.
То есть, я правильно понимаю, что если это сделать, то данные этого публичного узла (сервер, собственный белый IP) будут доступны тем, кто будет заинтересован в отслеживании участников сети? А так же факт использования Yggdrasil будет известен DPI по фигнерпринту и самому провайдеру интернета, если не завернуть трафик в прокси?
А чтобы завернуть трафик в прокси, надо иметь свой сервер, в России или за пределами РФ. Если в РФ - то этот сервер можно будет связать с конкретной личностью, а если за пределами РФ - то просто заблокировать.
Как минимум я видел перевод статьи от одного из работников Google, который рассказывал про карьерный рост менеджеров в компании через внедрение новых фичей. Если ты будешь просто оптимизировать сервис, ты повышение не получишь. Отсюда периодические переделки интерфейса, появление новых фичей и т.д. - и проблемы с тормозами приложения, которые в последствие могут еще и усиливаться.
Не понятно, почему все приводят в качестве плюсов возможность однократно загрузить какой-то большой объем данных.
Ведь в дальнейшем в диалоге при каждом запросе окно будет заполняться промтом, контекстом диалога. а так же всеми данными которые были загружены в память ранее. И миллион токенов или даже два не кажется чем-то реально крутым - ведь пользователь будет каждый раз платить за все эти сотни тысяч сохраненных в контексте токенов.
Тем более что насколько я помню, ИИ обрабатывает данные отдельными батчами.
Статья говорит о проблеме фокусируясь в основном только на одной из причин - некомпетентности разработчика. Тогда как половина причин, а может и больше это хотелки бизнеса или внутренняя парадигма организации. Разработчик может и хочет что-то там ускорить, но всегда ли ему дадут это сделать?
На рынке конкуренция и надо выпустить MVP быстрее конкурентов? - Нафиг оптимизацию, делаем рабочий прототип на %известный фреймворк% и в продакшн. Оптимизируем потом с ростом нагрузки.
Клиенты жалуются на тормоза приложения? - Подтяните основные метрики. Если надо добавим ресурсов.
70% запросов жрет аналитика? - Ну простите уж, нам надо собирать много, много данных.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
А потом в Gmail тормозит интерфейс так, словно они майнят на клиенте крипту.
Не думаю что в Google работают отбитые вчерашние ученики курсов, которые не могут посмотреть вне абстракции.
Хотя, причем тут ученики курсов.
Тут затрагиваются архитектурные вопросы, к которым у джунов по идее не должно быть доступа. Джун не должен проектировать структуру БД. Это задача сеньора, который потом должен бить по рукам тех, кто пишет херовый код или запросы.
То есть, я правильно понимаю, что если это сделать, то данные этого публичного узла (сервер, собственный белый IP) будут доступны тем, кто будет заинтересован в отслеживании участников сети?
А так же факт использования Yggdrasil будет известен DPI по фигнерпринту и самому провайдеру интернета, если не завернуть трафик в прокси?
А чтобы завернуть трафик в прокси, надо иметь свой сервер, в России или за пределами РФ.
Если в РФ - то этот сервер можно будет связать с конкретной личностью, а если за пределами РФ - то просто заблокировать.
Или я что-то не так понял?