Все потоки

1. OpenAI может работать с вашей базой, например, вики техподдержки, но её надо векторизовать. Получится, что модель только ищет по ней и может отвечать фрагментом исходника, но может его обрабатывать как текст (то есть сравнивать, анализировать и тому подобное).
2. Дальше можно использовать подход QA Retrieval Chain для работы с векторной базой. Работает это так: задаём вопрос, LLM формируют запрос к векторной базе, мы вынимаем из неё данные, подкладываем их в вопрос как контекст и передаём в LLM, а они формируют ответ.

1. Какого размера промпты могут быть, сколько, какие лимиты, как их частично обходить.
2. Как подключается база, как закидывать реально большие документы, как эмбеддится вектор, на каких языках это происходит и тому подобное.
3. Разные API.
4. Агентная модель GPT Engineer и АutoGPT.
5. Фреймворк лангчейн (построение цепочек запросов и разбиение макрозапроса на сотни).

Всем доброе утро! С Вами Крылов Александр, и сегодня я расскажу Вам про занимательную магию сервисного подхода DevOps, или как можно двигать культуру коммуникации в компании.

Вопросы и аудитория

Прежде чем начинать рассказ, следует ответить на вопрос, чем внедрение “DevOps as service” может быть полезно для компании? Какую пользу это внедрение может принести? И что так же не маловажно – кому это будет полезно?

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

Привет, Хабр!

Мы сталкиваемся с огромными объемами информации, высокой нагрузкой, и постоянно меняющимися требованиями. Все это требует от нас не только навыков программирования, но и грамотного проектирования архитектуры, которая способна справиться с этими вызовами.

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

Всем привет! Я Алексей Пономаревский, разработчик решений для платформ сбора и обработки больших данных.

Два года назад мы в ITSumma создали решение для потоковой обработки данных с помощью Apache Spark и базы данных Greenplum — spark-greenplum-connector. Это многофункциональный плагин для Spark, на его основе инженеры могут строить ETL-решения и анализировать данные in-memory.

Изначально мы разработали его, как часть клиентской платформы потоковой обработки данных. Но со временем он прирос одной интересной функциональностью, которая недоступна сейчас в других подобных решениях. В этой статья я хочу сделать краткое сравнение между двумя opensource-продуктами Apache Spark и Flink, а также рассказать об одной интересной особенности Spark, которую мы реализовали в коннекторе.

В этой статье я постараюсь максимально подробно описать, как выглядит процесс получения стартап визы и ВНЖ Испании в 2023 году, поделиться реальными кейсами, затыками и рисками. Статья будет полезна для фаундеров и сотрудников стартапов, предпринимателей и других специалистов, рассматривающих Испанию для переезда

Если вы хотите узнать, как проприетарное приложение можно перенести на новые операционные системы, спустя 30 лет после выпуска, читайте дальше.

Средство обработки унифицированных по назначению данных (Sound – system for operating with unified data) разрабатывается для внятного программирования, обеспечивающего соответствие результатов вычислений назначениям. Под назначением данных понимается формальная спецификация вычислений, приводящих к этим данным. Язык программирования Sound нужен как универсальный инструмент, позволяющий транслировать вычислительную логику в любой язык программирования.

Полосы прокрутки. Слышали когда-нибудь о них? Довольно крутая штука. Достаточно зажать и перетаскивать полосу прокрутки, чтобы перемещаться по контенту панели со скроллингом. Я это просто обожаю. Ежедневно целыми днями сижу за компьютером и тягаю полосу прокрутки. Но полосы прокрутки становятся мельче, и это оказывается всё более серьёзной проблемой. В статье я покажу скриншоты, но они настолько малы, что даже делать их было сложно. А разработчики продолжают делать их всё мельче, как будто не хотят, чтобы вы скроллили! Они говорят: «для этого ведь колесо прокрутки и существует». Друг мой, не у каждого есть колесо прокрутки и не каждый может свайпать по сенсорному экрану. И даже я, счастливый обладатель колеса прокрутки, хотел бы перемещаться по контенту быстро.

В предыдущей статье «Причина ”несбытия мечт”» мы установили, что главной причиной «несбытия мечт» выступает «низкая производительность труда». Что является тождественным высказыванию «делается мало задач имеющимися ресурсами в заданные сроки».

Теперь встаёт вопрос, что подразумевается под общим показателем «производительность труда»?

Ведь прежде, чем говорить о низкой производительности труда, нужно понять, а что такое сама «производительность труда»? Как она считается?

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

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

Привет, Хабр. Меня зовут Артур Нек. Я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В этой статье поделюсь опытом компании Kaiten в поиске работающего способа оценки времени выполнения задач: с чего начинали, с чем столкнулись и что выбрали в итоге.

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

Например, космический телескоп «Джеймс Уэбб» не подтвердил наличия плотной атмосферы вокруг скалистой экзопланеты TRAPPIST-1 C. А она выглядела весьма перспективной с точки зрения возможности существования воды в жидком виде и, возможно, жизни. Какие же признаки могут быть относительно надёжным свидетельством существования внеземной жизни? Давайте разберёмся.

Я системный аналитик и хочу поделиться своим опытом в написании требований.

Когда я пришла на проект, в качестве единственного аналитика, а четких требований что же должно быть в постановке не было, возник вопрос: как мне их оформлять? Этот вопрос я декомпозировала на следующие пункты:

• где должны храниться требования к задачам: есть Confluence и есть Jira, надо ли дублировать требования в обеих системах?

• какие обязательные разделы включать в техническое задание, какую сделать структуру требований?

Привет, Хабр!

Сегодня мы поговорим о чем-то, что является неотъемлемой частью современной микросервисной архитектуры, что-то, без чего трудно представить себе успешное и надежное приложение в мире распределенных систем. Да, вы правильно догадались, мы говорим о сквозном наблюдении, или, как его еще называют, "observability."

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

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

Разберемся подробнее с первым из ключевых компонентов сквозного наблюдения - трассировкой.

Перевод статьи Луизы Норт о том, откуда взялся дизайн-тренд Bento UI, что сделало его популярным, как делать интерфейсы в таком стиле и почему он так полюбился дизам Apple.

Статья взята из источника Daily Dose of Data Science.

Оговорюсь сразу: Я новичок в Data Scince и в оформлении статей. Пишу лишь сюда для своих заметок ну и может быть будет кому-то полезно. Прошу сильно не судить!)

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

В таких сферах, как исследование операций (Operations Research) и наука о данных (Data Science) чрезвычайно актуально сближение теории и её практического применения в виде программных проектов. Теоретические выкладки формируют базу программ для оптимизации чего‑либо, так как теория даёт средства для решения разнообразных задач. Но очень важно помнить и о том, что подобные программы должны быть доступны конечному пользователю, что с ними должно быть удобно работать.

Задача коммивояжёра (Traveling Salesman Problem, TSP) — это, без сомнения, та самая задача комбинаторной оптимизации, которая изучена лучше всего (Rego, C., Gamboa, D., Glover, F., & Osterman, C., 2011. Traveling salesman problem heuristics: Leading methods, implementations and latest advances. European Journal of Operational Research, 211(3), 427–441). Её легко описать (по крайней мере — на словах), её можно использовать для того чтобы продемонстрировать некоторые из возможных компонентов API современной программы по построению маршрутов. В результате я просто не мог подобрать ничего лучше этой задачи в качестве основы для примера, который разобран в этой статье.

Здесь вы узнаете о том, как использовать Python‑библиотеку Streamlit для создания веб‑приложения, которое позволяет решать задачу коммивояжёра с использованием входных данных, предоставленных пользователем. Так как нас интересует создание приложения, пригодного для решения реальных задач, мы, анализируя пути перемещения между некими географическими точками, будем интересоваться не только евклидовым расстоянием между ними, но и другими характеристиками путей. В частности, наша программа, используя координаты точек, должна уметь получать данные о том, какое расстояние по автомобильным дорогам нужно преодолеть для перемещения между ними. Эти данные должны учитываться при выполнении оптимизации. Для этого мы воспользуемся API OpenStreetMap.

Если вы хотите лучше разобраться в теоретических аспектах числовой оптимизации — вам, возможно, интересно будет почитать мои статьи о линейном программировании и о задаче маршрутизации транспорта (это — обобщение задачи коммивояжёра).

Готовы поработать? Взгляните на то, что у нас должно в итоге получиться…

Ранее мы рассказали о том, как выполняется мониторинг Linux-систем. Теперь рассмотрим, как настроить Windows Server.

Привет! Меня зовут Андрей, я возглавляю команду, которая отвечает за надежность и стабильную работу бэкенда в Wrike. Если вы когда-нибудь задумывались, что же такое «backend reliability», то знайте, что вы не один! Я часто объясняю, что это что-то вроде должности инженера по надежности сайта (SRE), но сфокусированная исключительно на бэкенде. В статье я расскажу о зонах ответственности BRE команды и инструментах, которые мы применяем для поддержания стабильной работы бэкенда на высоком уровне.

На стабильную работу ИТ-инфраструктуры компании в локальном дата-центре влияет много факторов: резервирование по схеме N+1, работа инженерных систем, экспертиза технических специалистов. Однако есть и внешние. К ним относится отказ оборудования, природные катаклизмы и геополитические конфликты.

В статье мы рассказали, как специалисты ITGLOBAL.COM запустили резервную площадку для восстановления данных после сбоев (Disaster Recovery) в облаке для ГК «Интерлизинг». А на YouTube выпустили видео с интервью участников проекта.