Я вижу ваш подход, как построение "карты" предметной области, когда из неё выявляются и сохраняются значимые для решаемых задач сущности и связи. Своего рода "индексация" нужных знаний.
Судя по вашему скрину, вы "индексируете" знания в области разработки ПО (метод, функция, атрибуты, переменные, классы, ...). Думаю, что в качестве специализированного агента у вашего подхода есть довольно неплохие перспективы. Если расширять этот подход и делать его универсальным (и для грибов, и для кулинарии, и для софта, и ...), то в пределе ваш граф очень сильно будет похож на нейросеть - связи всех со всеми и различные вероятности переходов по связям, и потеряет своё значение в качестве "индекса знаний".
Но если ограничивать область индексации, то вполне хорошее решение (y)
У нас написан конвейер миграции который выделяет самодостаточную единицы знания из предоставленных материалов
То есть, существует какое-то ваше собственное приложение, которое анализирует имеющиеся материалы по проекту и составляет "граф знаний", сохраняемый в БД (вектора и графы - индексы к этим данным). Т.е., это не универсальное решение, а "затачивающееся" под проект ("предоставленные материалы").
Декомпозиция и дообученные эмбеддинги.
Тут вряд ли подразумевается декомпозиция запроса пользователя - он слишком короткий. Значит должен быть какой-то массив документов (проектная база), который уточняет целевую предметную область и границы применимости конечного решения (например, грибы и кулинария). Вот этот массив документов уже можно декомпозировать и анализировать на предмет "самодостаточных единиц знаний". Что такое в данном контексте "дообученные эмбеддинги" и на каком корпусе знаний происходит их дообучение - не могу представить.
Насколько я понимаю, то, что в языковой модели представлено в виде матриц весов и неформализовано (вероятностное), вы частично формализуете (укладываете отношения в ~200 вариантов) и сохраняете в БД (+ индексы в виде графов/векторов). Это позволяет вам подтягивать в контекстное окно языковой модели дополнительные "единицы знания", относящиеся к пользовательскому запросу (даже короткому).
Когда я задаю сложный вопрос ... «Геном»... анализирует запрос, находит в графе все релевантные гены, проходит по их связям и собирает оптимальный контекст.
Насколько я понимаю, примерно так и работают агенты типа Claude & Codex - у них есть некоторая логика анализа проектной базы и свои внутренние протоколы поведения (каким образом "оптимизировать контекст запроса" к модели на каждой итерации). Только они работают с текстом проекта (кодом и документацией) напрямую, без пересборки "графа знаний" при изменении "предоставленных материалов".
Такой вопрос, а сколько "единиц знаний" получается для 'небольшой кодовой базы 300 файлов или 600 сущностей типа "класс", "функция"' и как часто её нужно пересобирать при изменениях этой кодовой базы (или проектной документации)?
Сначала «Геном» — внутренняя когнитивная структура — анализирует запрос, находит в графе все релевантные гены, проходит по их связям и собирает оптимальный контекст.
Хотелось бы понять на примере, как это работает. Вот у меня простой бытовой запрос: "Предложи рецепт приготовления грибов ежовик пестрый, который бы снизил их 'парфюмерный' привкус".
Запрос короткий и чёткий, ожидания от результата тоже понятные - ингредиенты, развесовка, последовательность шагов. Проблема в том, что основная информация о "связях" находится не в самом запросе (он короткий), а в весовой матрице 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, где софт работал правильно на наиболее популярных функциях и страшно глючил на редко-используемых. В своё время это была очень популярная платформа в е-коммерции. Так что, софт бывает всякий, но не все могут использовать всякий софт.
... и в пределе упираемся в те же самые проблемы, которые были решены при помощи LLM. Возможно, это просто следующий виток спирали эволюции.
Я вижу ваш подход, как построение "карты" предметной области, когда из неё выявляются и сохраняются значимые для решаемых задач сущности и связи. Своего рода "индексация" нужных знаний.
Судя по вашему скрину, вы "индексируете" знания в области разработки ПО (метод, функция, атрибуты, переменные, классы, ...). Думаю, что в качестве специализированного агента у вашего подхода есть довольно неплохие перспективы. Если расширять этот подход и делать его универсальным (и для грибов, и для кулинарии, и для софта, и ...), то в пределе ваш граф очень сильно будет похож на нейросеть - связи всех со всеми и различные вероятности переходов по связям, и потеряет своё значение в качестве "индекса знаний".
Но если ограничивать область индексации, то вполне хорошее решение (y)
То есть, существует какое-то ваше собственное приложение, которое анализирует имеющиеся материалы по проекту и составляет "граф знаний", сохраняемый в БД (вектора и графы - индексы к этим данным). Т.е., это не универсальное решение, а "затачивающееся" под проект ("предоставленные материалы").
Тут вряд ли подразумевается декомпозиция запроса пользователя - он слишком короткий. Значит должен быть какой-то массив документов (проектная база), который уточняет целевую предметную область и границы применимости конечного решения (например, грибы и кулинария). Вот этот массив документов уже можно декомпозировать и анализировать на предмет "самодостаточных единиц знаний". Что такое в данном контексте "дообученные эмбеддинги" и на каком корпусе знаний происходит их дообучение - не могу представить.
Насколько я понимаю, то, что в языковой модели представлено в виде матриц весов и неформализовано (вероятностное), вы частично формализуете (укладываете отношения в ~200 вариантов) и сохраняете в БД (+ индексы в виде графов/векторов). Это позволяет вам подтягивать в контекстное окно языковой модели дополнительные "единицы знания", относящиеся к пользовательскому запросу (даже короткому).
Насколько я понимаю, примерно так и работают агенты типа Claude & Codex - у них есть некоторая логика анализа проектной базы и свои внутренние протоколы поведения (каким образом "оптимизировать контекст запроса" к модели на каждой итерации). Только они работают с текстом проекта (кодом и документацией) напрямую, без пересборки "графа знаний" при изменении "предоставленных материалов".
Такой вопрос, а сколько "единиц знаний" получается для 'небольшой кодовой базы 300 файлов или 600 сущностей типа "класс", "функция"' и как часто её нужно пересобирать при изменениях этой кодовой базы (или проектной документации)?
Хотелось бы понять на примере, как это работает. Вот у меня простой бытовой запрос: "Предложи рецепт приготовления грибов ежовик пестрый, который бы снизил их 'парфюмерный' привкус".
Запрос короткий и чёткий, ожидания от результата тоже понятные - ингредиенты, развесовка, последовательность шагов. Проблема в том, что основная информация о "связях" находится не в самом запросе (он короткий), а в весовой матрице 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, где софт работал правильно на наиболее популярных функциях и страшно глючил на редко-используемых. В своё время это была очень популярная платформа в е-коммерции. Так что, софт бывает всякий, но не все могут использовать всякий софт.