#архитектура_llmприложений — Public Fediverse posts

Алгебра правосудия: как инженеры оцифровывали суды за 50 лет до ИИ

Сейчас в Legal AI доминирует довольно наивная идея: если большая языковая модель уже умеет писать приличный юридический текст, значит осталось только дать ей корпус судебных актов, прикрутить чат и получить "цифрового юриста" То есть будто бы право - это просто очень длинный prompt. Проблема в том, что суд - не текстовый жанр. Суд - это система. И как только вы выходите за пределы задач вроде "суммаризируй решение", "достань нормы" или “набросай черновик ходатайства”, выясняется неприятная вещь: LLM неплохо работает как интерфейс, но очень слабо подходит на роль самой архитектуры. Она умеет красиво объяснять. Но плохо заменяет процессную модель, вероятностный движок, слой маршрутизации и проверку ограничений. Это особенно заметно в задачах судебной аналитики: где дело может зависнуть, на каком этапе ломается траектория, где процесс ветвится, где нужен не текст, а расчет. И вот тут внезапно оказывается, что самые полезные идеи лежат не в свежем AI-маркетинге, а в работах полувековой давности. Еще в конце 1960-х исследователи моделировали прохождение felony defendants через судебную систему округа Колумбия, а в 1973 году уже описывали преимущественно алгебраический подход к симуляции legal systems для совместной работы инженеров и юристов, в том числе на материале судов Индианы. С инженерной точки зрения это важно не как исторический курьез, а как ранняя попытка честно ответить на вопрос: что именно мы автоматизируем в праве - текст, решение или саму систему. Ниже несколько простых, но, как кажется, важных идей по прочтении двух статей полувековой давности - Simulation Applied to a Court System (Jean G. Taylor, Joseph A. Navarro, Robert H. Cohen, 1968) и An algebraic method for simulating legal systems (Michael K. Sain, Eugene W. Henry, John J. Uhran, 1973) .

https://habr.com/ru/articles/1016538/

#legaltech #legal_ai #lexometrica #архитектура_llmприложений

Антипаттерн LLM-приложений: когда модель игнорирует контекст. Часть 2

Всем привет! В первой части мы разобрали теорию : почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются. Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене? Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного. В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.

https://habr.com/ru/articles/972626/

#llm #nlp #ruler #nolima #длинный_контекст #lost_in_the_middle #архитектура_llmприложений #rag

Антипаттерн LLM-приложений: Когда модель игнорирует контекст. Часть 1

Всем привет! Бездумно соглашаться с любыми хотелками заказчика или начальства в технических вопросах — почти то же самое, что саботировать проект: всё это быстро превращается в тяжёлый технический долг. Да, жёсткие сроки, ограниченный бюджет и нехватка "свободных рук" — реальность, с которой приходится считаться. Но это не отменяет простой вещи: свои опасения и архитектурные риски нужно озвучивать, выносить на обсуждение и предлагать не только «работающие на сейчас», но и масштабируемые решения. Как разработчикам нам обычно говорят: «давайте максимально быстро и топорно соберём proof-of-concept (PoC)». Мы собираем PoC на костылях, а дальше слышим: «отлично, теперь давайте из этого сделаем MVP». Времени на переорганизацию и реинжиниринг архитектуры никто не даёт. В итоге недели и месяцы работы превращают проект в тупиковую поделку — груду классов, методов и промптов, к которой страшно прикасаться. С LLM эта история становится ещё болезненнее. В работе у меня было несколько показательных проектов с LLM в роли основного движка (RAG, Q&A-системы), на которых я очень наглядно увидел, как делать не стоит. Эти «шишки» превратились в набор антипаттернов проектирования LLM-приложений, о которых я хочу поговорить в серии статей. В этой части — антипаттерн взаимодействия с LLM, когда модель игнорирует контекст: важные детали промпта, куски документов и даже прямые инструкции. Представьте ситуацию: вы даёте модели текст, в котором прямо содержится ответ на вопрос, но она отвечает что-то совсем не то. Вы прописываете инструкции, как именно нужно вести диалог и решать задачу, но они стабильно игнорируются. Вы добавляете новые чанки с данными, дописываете всё более подробные правила и уточнения — а качество ответов только падает.

https://habr.com/ru/articles/970474/

#llm #nlp #lost_in_the_middle #rope #selfattention #архитектура_LLMприложений #promptengineering

Антипаттерн LLM-приложений: когда модель игнорирует контекст. Часть 2

Всем привет! В первой части мы разобрали теорию : почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются. Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене? Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного. В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.

https://habr.com/ru/articles/972626/

#llm #nlp #ruler #nolima #длинный_контекст #lost_in_the_middle #архитектура_llmприложений #rag

Антипаттерн LLM-приложений: когда модель игнорирует контекст. Часть 2

Всем привет! В первой части мы разобрали теорию : почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются. Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене? Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного. В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.

https://habr.com/ru/articles/972626/

#llm #nlp #ruler #nolima #длинный_контекст #lost_in_the_middle #архитектура_llmприложений #rag

Антипаттерн LLM-приложений: когда модель игнорирует контекст. Часть 2

Всем привет! В первой части мы разобрали теорию : почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются. Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене? Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного. В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.

https://habr.com/ru/articles/972626/

#llm #nlp #ruler #nolima #длинный_контекст #lost_in_the_middle #архитектура_llmприложений #rag

[Перевод] Технический обзор моделей DeepSeek от V3 до V3.2

Три самые постоянные вещи в мире — оливье с мандаринами на Новый год, желание начать новую жизнь с понедельника и то, что если выходит статья Себастьяна Рашки, то я делаю ее качественный перевод на русский. Эта перевод крутой технически глубокая статьи известного исследователя LLM о том, как эволюционировали флагманские модели с открытыми весами от DeepSeek и обзор DeepSeek V3.2.

https://habr.com/ru/articles/973954/

#deepseek #дипсик #архитектуры_ai #llm #ллм #архитектура_llmприложений #большие_языковые_модели