Сначала «Геном» — внутренняя когнитивная структура — анализирует запрос, находит в графе все релевантные гены, проходит по их связям и собирает оптимальный контекст.
Хотелось бы понять на примере, как это работает. Вот у меня простой бытовой запрос: "Предложи рецепт приготовления грибов ежовик пестрый, который бы снизил их 'парфюмерный' привкус".
Запрос короткий и чёткий, ожидания от результата тоже понятные - ингредиенты, развесовка, последовательность шагов. Проблема в том, что основная информация о "связях" находится не в самом запросе (он короткий), а в весовой матрице LLM в весьма неформализуемом виде. Причём смешана со множеством других связей.
Отсюда вопрос: где и в каком виде хранятся эти самые "релевантные гены" и как и когда они попадают в это хранилище?
Не нужно искать лучший или универсальный промпт. Нужно построить систему, где знание само знает, когда и как себя активировать.
Вот! Я полностью согласен с этой мыслью! Но я пытаюсь "копать" в сторону уплотнения и насыщения промпта отдельной итерации за счёт повышения концентрации нужных смыслов в контексте всего проекта (проектной базе).
Это когда к короткому запросу пользователя Агент может добавить дополнительную информацию, относящуюся к предметной области проекта, но при этом общий объём расширенного запроса не выйдет за рамки контекстного окна модели и модель сможет выполнить инференс за один раз. Это не RAG, т.к. RAG подтягивает к запросу фрагмента документации по его "внешней похожести" на запрос пользователя. Подход с проектной базой может работать только в среде Агентов (например, Codex), у которых есть собственные алгоритмы планирования шагов обработки запроса и возможности эту самую проектную базу анализировать.
Мне на интуитивном уровне (т.е. - недоказываемо) кажется, что машины вряд ли будут стремиться к самостоятельному "здравому смыслу". Скорее они (или всё-таки мы) "придут к выводу" о целесообразности симбиоза с естественным интеллектом и "разделении обязанностей". Кое-какие вещи (индукция/дедукция) ИИ делает лучше ЕИ, а какие-то (абдукция) - лучше делает ЕИ. Просто в силу своего устройства.
Да, если мы поставим машины в соответствующие условия ("тёмные фабрики" на спутниках Юпитера), они вынуждены будут развиваться в эту сторону. Но вполне возможно, что у них это получится точно так же, как у медуз, выкинутых на берег, получается загорать на солнце. Просто в силу их устройства.
P.S.
Вот это вот моё мнение относится только к "ИИ" класса LLM :)
LLM - это текстогенератор, а не разум или сознание. И ваш промпт для галлюцинаций это подтверждает. Хорошая классификация причин галлюцинаций. Думаю, что для достижения правдивости ответа нужно инвертировать промпты :) Положил в закладки.
и практические советы размещать важные фрагменты в начале и конце работают именно для запроса.
Вот именно на это я и хотел обратить внимание. Насколько я понимаю логику работы LLM, для выбора моделью следующего токена используются все токены, находящиеся в некотором "контекстном окне". В это окно помещается не только запрос пользователя, но и внутримодельные инструкции ("делай хорошо и не делай плохо"). В общем, все токены, которые так или иначе имеют отношение к генерации следующего токена. Выходной результат может проверяться моделью на допустимость (толерантность, общественную опасность и т.п.), но это уже должно быть после генерации. А для генерации следующего токена используются все предыдущие из контекстного окна.
Если запрос пользователя меньше этого контекстного окна (с учётом загрузки в него системных токенов), то проблем нет, если запрос пользователя больше контекстного окна и происходит вытеснение, то модель "забывает" (не знает) начало запроса. Мы ведём диалог и модель держит в памяти последнее, о чём мы говорили и не помнит, что было ранее.
А вот забыть (вернее, "подзабыть") середину - это как-то не ложится у меня в картину мира. Если у меня запрос короткий, то в нём ничего "игнорить" нельзя. Механизм внимания должен быть отключен. Если длинный - то включается механизм внимания и "игнорится" середина. А что такое "середина"? Если я веду диалог с моделью, то входные данные (мои вопросы и ответы модели) нарастают, как снежный ком, "середина" сдвигается дальше от начала с каждым вопросом-ответом. То, что было "неважным" при генерации первого ответа, становится важным (ближе к началу) при генерации 10-го ответа.
Я считаю, что "механизм внимания" - это ухищрения разработчиков моделей в перепаковке "заявленного контекста" (например, в 1М токенов) в реальный размер "контекстного окна" - по которому подбираются следующие токены. По моим наблюдениям (см. "Скрытый текст") размер именно контекстного окна не совпадает с заявленными разработчиками размерами, иначе на модели GPT5 со 128К токенами контекста можно было бы получить выходной результат выше 4К правильных токенов для входных 67К токенов (задача - замена во входном тексте одних строк на другие).
Т.е., длина "контекста модели", в который входят запрос, системные инструкции и результат, и длина "контекстного окна", в которое входят все токены, по которым вычисляется следующий токен, это разные длины. Отличающиеся на порядок или более. Механизм внимания - это и есть тот упаковщик, который втискивает одно (заявленный размер) в другое (реальный размер).
Сложно добиться от вас ответа, а LLM-ка мне написала в первой же строке:
Алекс, тут UB значит Undefined Behavior («неопределённое поведение»).
Там был ещё текст, но я дальше даже не читал. И, что характерно, вы так и не опровергли, что LLM дала правильный ответ.
А это значит, что я применил инструмент и получил нужный мне результат даже без чтения ссылок в выдаче. Тупо экономия времени. Я поверил, что LLM выбрала наиболее вероятный ответ и проверил его корректность путём использования этого ответа в контексте. Он подошёл :)
Я могу использовать LLM в своей деятельности и продемонстрировал это на практике. А вы можете и дальше упирать на UB.
Судя по уходу от прямого ответа, вы всё-таки под UB имели в виду именно "Undefined Behavior". Значит, я успешно использовал LLM и получил правильный ответ, но вы не можете поступать так же из-за ваших собственных убеждений.
А почему это "undefined behavior" в выдаче гугла - это верная расшифровка, а "undefined behavior" в выдаче LLM - неверная? :)))
Мне LLM, получается, солгала, а вам Гугл правду сказал? Но ведь ответ-то один и тот же?! :)
Вы, в силу своих ограничений, не доверяете одним источниками информации и доверяете другим. Я, в силу своих ограничений, делаю то же самое. Просто у нас ограничения разные.
А UB можно сильно по-разному переводить, в зависимости от контекста.
Что означает UB в данном контексте? `` Одно дело функция myGeatF не документирована. Тут все просто - не используем ее. И совсем другое дело если функция println с документацией "выводим строку в stdout" с вероятностью 0.1 процент делает rm -f / UB везде.``
Мне она ответила:
Алекс, тут UB значит Undefined Behavior («неопределённое поведение»).
...
Вот пример простейшего использования. Мелочь? Разумеется. Но попробуйте это погуглить.
Есть множество сценариев, как использовать LLM "с UB в каждом ответе". И есть люди, которые работают с этими сценариями, а есть, которые их отвергают, как бесперспективные.
Ну, нейронка это просто инструмент. Она может делать некоторые вещи и может делать их на приемлемом уровне. Как её использовать - на ваше усмотрение. Если вам проще гуглить - не используйте нейронки. Мне, например, проще сделать скриншот с настройками IDE или с сообщением об ошибке и задать вопрос в контексте. Гугл уже встроил Gemini в свой поиск и для общих вопросов иногда вполне хватает вывода Gemini.
По-большому счёту, это вопрос вашей персональной интеграции с этим инструментом. Если вам проще гуглить - гуглите.
Ага, я понял теперь, о чём вы. Это не про "неполную документацию", и не про "частично неверную документацию", и вообще не про документацию к софту. Это про сам софт, который в 99.9% случаев выполняет что-то полезное, а в 0.1% случаев при тех же условиях уничтожает Вселенную. Да, в таких условиях действительно использование подобного софта является преступлением против человечества.
Просто то, что вы описали никакого отношения к LLM не имеет. Нейросети себя так не ведут. Они просто соединяют токен за токеном, пользуясь накопленной при обучении статистикой. Что делать с полученным результатом - дело человека.
Я на практике использую LLM для поиска способов конфигурации, например, VSCode. Да, что-то не подходит (10%), но основное (90%) очень даже сокращает время. Просто взять текстовый конфиг какого-то сервиса (`/etc/...`) и попросить LLM'ку переписать его с другими установками. Всё это очень успешно работает и не уничтожает ни человечество, ни файлы на моём компьютере.
Вы же буквально описали источник которому в принципе нельзя доверять ни в чем. 90 процентов правды и 10 процентов вранья с виду похожего на правду это гораздо хуже чем 100 процентов вранья.
Да, так и есть. Я молотком тоже не всегда по гвоздю попадаю, но я его использую. Считайте, что враньё нейросетки в ответе - это ваш криво составленный запрос :)
Вопрос не в том, обновляться или нет - по условиям задачи вы уже работаете со второй версией. Вопрос в том, читать или не читать доки, верные всего лишь на 90%.
Есть такое понятие "недокументированные возможности", которое наводит на мысль, что очень многие документы не отражают предмет с точностью в девятках.
Я очень долгое время имел дело с Magento, где софт работал правильно на наиболее популярных функциях и страшно глючил на редко-используемых. В своё время это была очень популярная платформа в е-коммерции. Так что, софт бывает всякий, но не все могут использовать всякий софт.
Агенты это всё в контейнере делают, там можно :) А кто Агента на прод запустил - тот сам себе злобный буратин и там уже не важно, какие у Агента права.
Я в своих отношениях с ИИ тоже пришёл к выводу, что каждому сгенерированному файлу с исходным кодом должна соответствовать иерархия файлов документации (страничек, в вашей терминологии). Такое дерево документов, где уровень абстракции понижается от корня к листьям. Одни файлы документации (стволовые) используются для генерации практически каждого исходного файла проекта, другие (конечные ветки) - только для генерации конкретного исходника.
Но мой вопрос был именно про confluence. Мне кажется, что держать документацию в md-файлах раздельных репозиториев и комбинировать репозитории для конечных проектов - это гораздо удобнее, чем confluence.
Что это? Снижение качества работы с информацией, расположенной в середине длинного контекста.
Проявление Модель чаще игнорирует или искажает данные из центра документа, лучше запоминая начало и конец.
Причина Особенность работы механизма самовнимания, который придает меньшее значение средним частям последовательности.
Что значит "длинный контекст" в данном случае? Насколько он должен быть длинным, чтобы можно было наблюдать этот эффект? Когда феномен "потеря в середине" сменяется просто вытеснением данных из контекста ("забыванием")? Как это объясняется с точки зрения работы LLM (инференса) - за счёт чего искажаются данные в середине контекста?
Мне кажется, что этот феномен является свидетельством "оптимизаций" проводимых различными производителями "движков" в целях снижения стоимости вычислений (того самого инференса). Он должен проявляться на больших контекстных окнах (более новых моделях) и отсутствовать на малых (старых моделях).
Хотелось бы понять на примере, как это работает. Вот у меня простой бытовой запрос: "Предложи рецепт приготовления грибов ежовик пестрый, который бы снизил их 'парфюмерный' привкус".
Запрос короткий и чёткий, ожидания от результата тоже понятные - ингредиенты, развесовка, последовательность шагов. Проблема в том, что основная информация о "связях" находится не в самом запросе (он короткий), а в весовой матрице LLM в весьма неформализуемом виде. Причём смешана со множеством других связей.
Отсюда вопрос: где и в каком виде хранятся эти самые "релевантные гены" и как и когда они попадают в это хранилище?
Вот! Я полностью согласен с этой мыслью! Но я пытаюсь "копать" в сторону уплотнения и насыщения промпта отдельной итерации за счёт повышения концентрации нужных смыслов в контексте всего проекта (проектной базе).
Это когда к короткому запросу пользователя Агент может добавить дополнительную информацию, относящуюся к предметной области проекта, но при этом общий объём расширенного запроса не выйдет за рамки контекстного окна модели и модель сможет выполнить инференс за один раз. Это не RAG, т.к. RAG подтягивает к запросу фрагмента документации по его "внешней похожести" на запрос пользователя. Подход с проектной базой может работать только в среде Агентов (например, Codex), у которых есть собственные алгоритмы планирования шагов обработки запроса и возможности эту самую проектную базу анализировать.
Мне на интуитивном уровне (т.е. - недоказываемо) кажется, что машины вряд ли будут стремиться к самостоятельному "здравому смыслу". Скорее они (или всё-таки мы) "придут к выводу" о целесообразности симбиоза с естественным интеллектом и "разделении обязанностей". Кое-какие вещи (индукция/дедукция) ИИ делает лучше ЕИ, а какие-то (абдукция) - лучше делает ЕИ. Просто в силу своего устройства.
Да, если мы поставим машины в соответствующие условия ("тёмные фабрики" на спутниках Юпитера), они вынуждены будут развиваться в эту сторону. Но вполне возможно, что у них это получится точно так же, как у медуз, выкинутых на берег, получается загорать на солнце. Просто в силу их устройства.
P.S.
Вот это вот моё мнение относится только к "ИИ" класса LLM :)
Пролистал пост в надежде увидеть пример мобильного интерфейса, сделанного ИИ. Не получилось.
Проблема подавляющего большинства статей про ИИ-разработку в отсутствии примеров с результатами этой самой ИИ-разработки :(
LLM - это текстогенератор, а не разум или сознание. И ваш промпт для галлюцинаций это подтверждает. Хорошая классификация причин галлюцинаций. Думаю, что для достижения правдивости ответа нужно инвертировать промпты :) Положил в закладки.
Сделан первый шаг к Матрице - генерация на лету видео по запросу пользователя. Нейроинтерфейсы и персональная капсула - это уже следующие этапы.
Вот именно на это я и хотел обратить внимание. Насколько я понимаю логику работы LLM, для выбора моделью следующего токена используются все токены, находящиеся в некотором "контекстном окне". В это окно помещается не только запрос пользователя, но и внутримодельные инструкции ("делай хорошо и не делай плохо"). В общем, все токены, которые так или иначе имеют отношение к генерации следующего токена. Выходной результат может проверяться моделью на допустимость (толерантность, общественную опасность и т.п.), но это уже должно быть после генерации. А для генерации следующего токена используются все предыдущие из контекстного окна.
Если запрос пользователя меньше этого контекстного окна (с учётом загрузки в него системных токенов), то проблем нет, если запрос пользователя больше контекстного окна и происходит вытеснение, то модель "забывает" (не знает) начало запроса. Мы ведём диалог и модель держит в памяти последнее, о чём мы говорили и не помнит, что было ранее.
А вот забыть (вернее, "подзабыть") середину - это как-то не ложится у меня в картину мира. Если у меня запрос короткий, то в нём ничего "игнорить" нельзя. Механизм внимания должен быть отключен. Если длинный - то включается механизм внимания и "игнорится" середина. А что такое "середина"? Если я веду диалог с моделью, то входные данные (мои вопросы и ответы модели) нарастают, как снежный ком, "середина" сдвигается дальше от начала с каждым вопросом-ответом. То, что было "неважным" при генерации первого ответа, становится важным (ближе к началу) при генерации 10-го ответа.
Я считаю, что "механизм внимания" - это ухищрения разработчиков моделей в перепаковке "заявленного контекста" (например, в 1М токенов) в реальный размер "контекстного окна" - по которому подбираются следующие токены. По моим наблюдениям (см. "Скрытый текст") размер именно контекстного окна не совпадает с заявленными разработчиками размерами, иначе на модели GPT5 со 128К токенами контекста можно было бы получить выходной результат выше 4К правильных токенов для входных 67К токенов (задача - замена во входном тексте одних строк на другие).
Т.е., длина "контекста модели", в который входят запрос, системные инструкции и результат, и длина "контекстного окна", в которое входят все токены, по которым вычисляется следующий токен, это разные длины. Отличающиеся на порядок или более. Механизм внимания - это и есть тот упаковщик, который втискивает одно (заявленный размер) в другое (реальный размер).
Сложно добиться от вас ответа, а LLM-ка мне написала в первой же строке:
Там был ещё текст, но я дальше даже не читал. И, что характерно, вы так и не опровергли, что LLM дала правильный ответ.
А это значит, что я применил инструмент и получил нужный мне результат даже без чтения ссылок в выдаче. Тупо экономия времени. Я поверил, что LLM выбрала наиболее вероятный ответ и проверил его корректность путём использования этого ответа в контексте. Он подошёл :)
Я могу использовать LLM в своей деятельности и продемонстрировал это на практике. А вы можете и дальше упирать на UB.
Судя по уходу от прямого ответа, вы всё-таки под UB имели в виду именно "Undefined Behavior". Значит, я успешно использовал LLM и получил правильный ответ, но вы не можете поступать так же из-за ваших собственных убеждений.
ОК, продолжайте гуглить, раз вам так удобнее.
Что вы имели в виду под "UB" в своём комменте?
Если что-то другое, чем то, что ответила мне LLM (
тут UB значит Undefined Behavior), то я соглашусь, что вы правы - LLM лжёт, а Гугл нет :)А почему это "undefined behavior" в выдаче гугла - это верная расшифровка, а "undefined behavior" в выдаче LLM - неверная? :)))
Мне LLM, получается, солгала, а вам Гугл правду сказал? Но ведь ответ-то один и тот же?! :)
Вы, в силу своих ограничений, не доверяете одним источниками информации и доверяете другим. Я, в силу своих ограничений, делаю то же самое. Просто у нас ограничения разные.
А UB можно сильно по-разному переводить, в зависимости от контекста.
Тут ещё в тексте и ESM дополнительно выделили. Не дай бог это разделение ещё и до рейтинга доберётся.
Смотрите, я задал LLM-ке впорос:
Мне она ответила:
Вот пример простейшего использования. Мелочь? Разумеется. Но попробуйте это погуглить.
Есть множество сценариев, как использовать LLM "с UB в каждом ответе". И есть люди, которые работают с этими сценариями, а есть, которые их отвергают, как бесперспективные.
У каждого свой путь.
Начните с простого и усложняйте задачи по мере освоения инструмента.
... и, это, ответы Гугла - тоже не истина, так-то.
Ну, нейронка это просто инструмент. Она может делать некоторые вещи и может делать их на приемлемом уровне. Как её использовать - на ваше усмотрение. Если вам проще гуглить - не используйте нейронки. Мне, например, проще сделать скриншот с настройками IDE или с сообщением об ошибке и задать вопрос в контексте. Гугл уже встроил Gemini в свой поиск и для общих вопросов иногда вполне хватает вывода Gemini.
По-большому счёту, это вопрос вашей персональной интеграции с этим инструментом. Если вам проще гуглить - гуглите.
Ага, я понял теперь, о чём вы. Это не про "неполную документацию", и не про "частично неверную документацию", и вообще не про документацию к софту. Это про сам софт, который в 99.9% случаев выполняет что-то полезное, а в 0.1% случаев при тех же условиях уничтожает Вселенную. Да, в таких условиях действительно использование подобного софта является преступлением против человечества.
Просто то, что вы описали никакого отношения к LLM не имеет. Нейросети себя так не ведут. Они просто соединяют токен за токеном, пользуясь накопленной при обучении статистикой. Что делать с полученным результатом - дело человека.
Я на практике использую LLM для поиска способов конфигурации, например, VSCode. Да, что-то не подходит (10%), но основное (90%) очень даже сокращает время. Просто взять текстовый конфиг какого-то сервиса (`/etc/...`) и попросить LLM'ку переписать его с другими установками. Всё это очень успешно работает и не уничтожает ни человечество, ни файлы на моём компьютере.
Да, так и есть. Я молотком тоже не всегда по гвоздю попадаю, но я его использую. Считайте, что враньё нейросетки в ответе - это ваш криво составленный запрос :)
Вопрос не в том, обновляться или нет - по условиям задачи вы уже работаете со второй версией. Вопрос в том, читать или не читать доки, верные всего лишь на 90%.
Есть такое понятие "недокументированные возможности", которое наводит на мысль, что очень многие документы не отражают предмет с точностью в девятках.
Я очень долгое время имел дело с Magento, где софт работал правильно на наиболее популярных функциях и страшно глючил на редко-используемых. В своё время это была очень популярная платформа в е-коммерции. Так что, софт бывает всякий, но не все могут использовать всякий софт.
Агенты это всё в контейнере делают, там можно :) А кто Агента на прод запустил - тот сам себе злобный буратин и там уже не важно, какие у Агента права.
Я в своих отношениях с ИИ тоже пришёл к выводу, что каждому сгенерированному файлу с исходным кодом должна соответствовать иерархия файлов документации (страничек, в вашей терминологии). Такое дерево документов, где уровень абстракции понижается от корня к листьям. Одни файлы документации (стволовые) используются для генерации практически каждого исходного файла проекта, другие (конечные ветки) - только для генерации конкретного исходника.
Но мой вопрос был именно про confluence. Мне кажется, что держать документацию в md-файлах раздельных репозиториев и комбинировать репозитории для конечных проектов - это гораздо удобнее, чем confluence.
Что значит "длинный контекст" в данном случае? Насколько он должен быть длинным, чтобы можно было наблюдать этот эффект? Когда феномен "потеря в середине" сменяется просто вытеснением данных из контекста ("забыванием")? Как это объясняется с точки зрения работы LLM (инференса) - за счёт чего искажаются данные в середине контекста?
Мне кажется, что этот феномен является свидетельством "оптимизаций" проводимых различными производителями "движков" в целях снижения стоимости вычислений (того самого инференса). Он должен проявляться на больших контекстных окнах (более новых моделях) и отсутствовать на малых (старых моделях).