반응형
반응형

기술 인력 개발 기업 플루럴사이트Pluralsight)의 최근 AI 기술 보고서에 따르면 임원 및 IT 리더의 40%만이 직원을 대상으로 공식적인 AI 교육을 실시하고 있다고 답했다. 그리고 직원 AI 교육에 대한 CIO의 책임이 점점 더 커짐에 따라 IT 리더는 기업의 AI 준비성 책임 측면에서 해법을 찾아내야 할 처지에 놓일 가능성이 크다는 진단이다.

직원들도 주목하고 있다. 디지털 워크플레이스 공급업체 Slingshot이 8월에 발표한 설문조사 결과에 따르면 응답 직원의 다수는 AI에 대해 제대로 교육이나 훈련을 받지 못했다고 느끼고 있었다.

플루럴사이트의 생성형 AI 수석 저자 데이비드 해리스는 “일하는 방식을 완전히 뒤엎는 새로운 기술이 등장할 때마다 많은 사람들이 촉각을 곤두세운다. 내가 보기에 모든 비즈니스 관계자는 AI를 어떤 식으로든 도입해야 한다고 생각한다. 그러나 그 방법을 정확히 아는 사람은 드물며, 직원들의 지식 수준에 대해 확산하는 이도 거의 없다"라고 말했다.

그에 따르면 채용 시장을 통해 AI 기술 격차를 메우기도 쉽지 않다. 비교적 최근의 기술인 데다 빠르게 발전하고 있기 때문이다. 해리스를 비롯한 업계 전문가들은 또 개발자, 영업사원, 사무직에 이르는 모든 직원이 AI 교육을 통해 혜택을 받을 수 있다고 강조했다. 

한편 IT 직원들조차도 AI가 일자리를 대체하는 것에 대해 우려하고 있다. 플루럴사이트의 설문조사에 참여한 IT 전문가 중 거의 4분의 3은 AI가 자신의 기술을 쓸모없게 만드는 상황을 우려한다고 답했다.

인재 유지에 영향
이키가이 랩스(Ikigai Labs)의 사장인 카말 알루왈리아는 AI가 고용 시장에 큰 영향을 미칠 것이기에 직원 대상의 AI 교육이 필수적이라고 강조했다. 이키가이 랩스는 소량의 기업 데이터로 작동하는 생성형 AI 툴을 제공하는 업체다.

AI와 일자리 사이의 관계에 대한 알루왈리아의 전망은 복합적이다. 그는 AI가 오늘날 IT 일자리의 3분의 1을 없애지만, 나머지 3분의 1은 AI를 통해 향상될 것이라고 예측했다. 또 미래 일자리의 또 다른 3분의 1은 AI에 의해 창출될 것으로 그는 전망했다.

HR 회사 에잇폴드닷에이아이의 사장을 역임한 바 있는 알루왈리아는 “일자리 대체 현상이 상당할 것이며, 우리 생각보다 더 빨리 일어날 것이라고 본다. 나는 만나는 모든 사람들에게 업무 적절성을 유지하기 위해서는 기술을 배울 준비가 되어 있어야 한다고 직설적으로 이야기하고 있다”라고 말했다.

그에 따르면 조직은 지금 당장 AI 교육에 투자할 필요가 있다. CIO와 기타 경영진은 직원들이 최신 AI 기술을 지속적으로 학습하도록 장려해야 하며, AI 교육을 잘 활용한 직원들의 성공 사례를 알려야 한다. 시장에 AI 전문 인력이 부족하다는 점을 감안할 때 더욱 그렇다.

알루왈리아는 “재교육, 업스킬링에 대한 시각을 바꿔야 한다. 경영진이 이러한 변화를 방관하고 다른 중간 관리자나 개인이 처리하도록 조치해선 안 된다. 경영진이 변화를 지지하도록 해야 한다. 그래야 분위기가 조성되기 때문이다”라고 말했다.

플루럴사이트 설문조사에 따르면 IT 전문가의 74%가 AI로 인해 자신의 기술이 무의미해질 것이라고 우려하는 반면, 81%는 현재 자신의 역할에 AI를 통합할 수 있다고 확신하고 있었다. 점점 더 많은 IT 전문가들이 AI 교육을 자신의 커리어에 필수적인 것으로 바라보고 있었다. AI 업스킬링에 IT 전문가를 적극적으로 참여시키지 않는다면 인재가 빠져나갈 가능성이 커지는 셈이다.

조화롭게 구성
디지털 컨설팅 회사인 웨스트 먼로 파트너스의 AI 및 엔지니어링 부문 수석 파트너인 에릭 브라운은 만연한 위기감이 틀리지 않다고 진단하며, 조직과 직원 모두 '모든 곳에 AI가 존재하는' 미래에 대비해야 한다고 말했다.

그는 이어 AI 교육은 직원과 AI 간의 '조화'를 구축하고 인간이 결정권을 행사하는 모습을 보여주는 데 초점을 맞춰야 한다고 설명했다. “인간의 창의성과 비판적 사고를 AI의 효율성을 결합해야 최상의 결과를 얻을 수 있다"라고 브라운은 말했다.

또 일부 직원은 다른 직원보다 AI의 영향을 더 많이 받겠지만, 교육은 모든 직원에게 제공되어야 한다. 그는 “최고 경영진을 포함해 모든 직원에 대해 투자해야 한다. 교육에 대한 접근성을 민주화한다는 것은 모든 사람이 AI를 발전시키는 문화를 조성하는 데 기여하고 책임을 질 수 있다는 것을 의미한다”라고 그는 말했다.

AI 교육의 필요성을 강조하는 목소리가 높지만 현실적인 여러 어려움이 있다. 데이터 분석 및 AI 도구 제공업체인 Seeq의 CTO 더스틴 존슨은 교육에 참여할 시간이 부족한 직원이 많으며, 지속적인 교육이라면 더욱 그렇다고 지적했다. 직원 개개인의 필요에 맞춰 참여하기 적합한 적시 교육 과정을 마련해야 할 이유라고 그는 덧붙였다. 그에 따르면 이는 AI 교육 도구에 주목할 이유이기도 하다. AI 기반 교육 도구는 자료를 통합하고 고객 기업 고유의 특정 장비와 프로세스에 맞는 정보를 제공할 수 있기 때문이다. 

선구자들에게 기회를
존슨은 또 AI에 적극적인 직원들이 AI로 작업할 수 있도록 허용할 것을 권장했다. 이들 선구자들이 성공을 거두고 환각 및 기타 AI 문제를 피한 방법을 보여주는 웨비나 및 기타 이벤트를 개최하는 방안도 검토할 만하다는 설명이다.

“이러한 세션은 AI에게 질문하는 방법, 문서를 정확히 검색하는 방법 등을 공유할 수 있는 기회를 제공한다. 또 산출 결과를 검증할 수 있는 방법을 확산시킴으로써 기술에 대한 신뢰도를 높이게 된다”라고 그는 말했다.

한편 AI 기술이 빠르게 발전하고 있다는 점이 감안하라고 플로럴사이트의 해리스는 전했다. 새로운 기능과 용도를 반영하기 위해 AI 교육 과정을 정기적으로 업데이트할 필요가 있다. 어떤 경우에는 AI 교육 과정에서 제공되는 정보가 일주일도 안 되어 구식이 될 수 있다고 그는 덧붙였다. 

해리스는 “연 단위, 월 단위의 업데이트 소식이 아니다. 어제와 내일의 문제다”라고 말했다. https://www.ciokorea.com/news/349675

반응형
반응형

 

Apple이 2025년 봄 ‘나의 찾기(Find My)’ 네트워크를 국내 도입할 예정이다. 한국 내 사용자들도 곧 나의 찾기 앱을 이용해 개인정보가 보호된 상태에서 자신의 Apple 기기와 개인 소지품을 찾고, 친구 및 가족 등의 위치를 확인할 수 있게 된다.
나의 찾기는 사용자가 자신의 Apple 기기는 물론, AirTag 또는 나의 찾기 네트워크 액세서리를 부착해 둔 소지품의 위치까지 쉽게 파악할 수 있게 해준다. 기기나 소지품을 분실한 경우, iPhone, iPad, Mac의 나의 찾기 앱 또는 Apple Watch의 기기 찾기(Find Devices) 및 물품 찾기(Find Items) 앱을 활용하여 지도에서 위치를 확인하고, 해당 위치로 가는 경로를 안내받으며, 가까이 접근할 때 사운드를 재생하여 쉽게 찾을 수 있다.
또한 나의 찾기를 통해 사용자가 친구 및 가족과 위치를 공유해 보다 쉽게 서로를 찾고 연락을 유지할 수도 있다. 붐비는 기차역이나 혼잡한 공원 등에서 나의 찾기로 친구를 찾아야 하는 경우, iPhone 15 또는 iPhone 15 Pro 사용자는 정밀 탐색(Precision Finding) 기능을 통해 친구가 있는 위치까지 안내받을 수 있다.
 
반응형
반응형

https://www.cursor.com/

 

Cursor

The AI Code Editor

www.cursor.com

 

The AI Code Editor
Built to make you extraordinarily productive, Cursor is the best way to code with AI.

 

제품개발을 주저하는 비개발자를 위해

https://disquiet.io/

 

Disquiet*

IT 서비스 메이커들의 소셜 네트워크. 디스콰이엇에서 서로의 프로젝트를 공유해 보세요!

disquiet.io

 

https://disquiet.io/@williamjung/makerlog/%EC%A0%9C%ED%92%88%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%A3%BC%EC%A0%80%ED%95%98%EB%8A%94-%EB%B9%84%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%B4

 

제품개발을 주저하는 비개발자를 위해 | Disquiet*

Cursor가 또 하나의 킬링피처, Composer를 공개했습니다. 기존에는 필요하는 코드를 생성했지만, Composer는 파일을 생성하고 파일 간의 관계를 만들며 직접 코드를 실행할 수 있다는 점이 가장 큰 차

disquiet.io

 

  • Cursor가 새로운 기능인 Composer를 공개
    • Composer는 파일 생성, 파일 간 관계 형성, 코드 직접 실행이 가능한 것이 특징
  • 기술의 민주화로 비개발자도 제품 개발이 가능해짐
    • 제품 개발의 주요 장벽은 이제 코딩에 대한 막연한 두려움뿐임
  • 제품 개발의 난이도가 글쓰기와 비슷해짐
    • 좋은 제품 개발을 위해서는 기술 이해와 다양한 경험이 중요
  • Composer 사용을 위한 환경 설정 가이드
    1. Cursor 다운로드
    2. Next.js 앱 생성
    3. 파일 구조 설명
    4. 개발 서버 실행 (npm run dev)
    5. Shadcn UI 설치
    6. Composer 활성화
  • AI와 효과적으로 소통하는 방법 3가지
    1. AI에게 구조화 맡기기
    2. 원하는 디자인 캡처해서 AI에게 제시하기
    3. AI의 주의력 활용하기 (구체적인 지시 제공)
  • Instruction 파일 업로드 방법
    • 마크다운 형식으로 프롬프트 저장하여 AI 출력물의 일관성과 효율성 향상
  • 실제 사례로 3시간 만에 디스콰이엇 광고 소개 페이지 제작 경험 공유
  • 기타 Composer 활용 사례들
반응형
반응형

[python] html table을 Markdown으로 변경하기. 

 

htmltabletomdhtml 테이블을 마크다운으로 변환하기 위한 것입니다. 또한, 테이블 셀 내부의 내용은 HTML이 포함되어 있는 경우 마크다운으로 변환할 수 있으며, 이를 위해 라이브러리를 사용합니다 htmltomarkdown.

 

pip install htmltabletomd

 

https://pypi.org/project/htmltabletomd/

 

htmltabletomd

Convert html table to markdown table

pypi.org

from bs4 import BeautifulSoup
from markdownify import markdownify as md
import os

def convert_html_table_to_md(html_file_path, output_md_file_path):
    # HTML 파일 읽기
    with open(html_file_path, 'r', encoding='utf-8') as file:
        html_content = file.read()

    # BeautifulSoup을 사용하여 HTML 파싱
    soup = BeautifulSoup(html_content, 'html.parser')

    # HTML을 Markdown으로 변환
    markdown_content = md(str(soup))

    # 결과를 Markdown 파일로 저장
    with open(output_md_file_path, 'w', encoding='utf-8') as file:
        file.write(markdown_content)
    
    print(f"Converted HTML table to Markdown and saved as: {output_md_file_path}")

# 사용 예시
#html_file_path = 'path_to_your_html_file.html'  # 변환할 HTML 파일 경로
html_file_path = 'test_001.html'  # 변환할 HTML 파일 경로
output_md_file_path = 'output_markdown_file.md'  # 저장할 Markdown 파일 경로

convert_html_table_to_md(html_file_path, output_md_file_path)
반응형
반응형

Ibis는 모든 쿼리 엔진에서 실행되는 Python 데이터프레임 API를 정의합니다. 현재 20개 이상의 백엔드가 있는 모든 백엔드 데이터 플랫폼의 프런트엔드입니다. 이를 통해 Ibis는 연결된 백엔드만큼 뛰어난 성능을 일관된 사용자 경험과 함께 제공할 수 있습니다.

 

https://ibis-project.org/why

 

Why Ibis? – Ibis

the portable Python dataframe library

ibis-project.org

 

 

 

 

Why Ibis?

Ibis defines a Python dataframe API that executes on any query engine – the frontend for any backend data platform, with 20+ backends today. This allows Ibis to have excellent performance – as good as the backend it is connected to – with a consistent user experience.

What is Ibis?

Ibis is the portable Python dataframe library.

We can demonstrate this with a simple example on a few local query engines:

import ibis

ibis.options.interactive = True
  • DuckDB
  • Polars
  • DataFusion
  • PySpark
1con = ibis.connect("duckdb://")

t = con.read_parquet("penguins.parquet")
t.limit(3)
┏━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━┓
┃ species ┃ island    ┃ bill_length_mm ┃ bill_depth_mm ┃ flipper_length_mm ┃ body_mass_g ┃ sex    ┃ year  ┃
┡━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━┩
│ string  │ string    │ float64        │ float64       │ int64             │ int64       │ string │ int64 │
├─────────┼───────────┼────────────────┼───────────────┼───────────────────┼─────────────┼────────┼───────┤
│ Adelie  │ Torgersen │           39.1 │          18.7 │               181 │        3750 │ male   │  2007 │
│ Adelie  │ Torgersen │           39.5 │          17.4 │               186 │        3800 │ female │  2007 │
│ Adelie  │ Torgersen │           40.3 │          18.0 │               195 │        3250 │ female │  2007 │
└─────────┴───────────┴────────────────┴───────────────┴───────────────────┴─────────────┴────────┴───────┘
t.group_by(["species", "island"]).agg(count=t.count()).order_by("count")
┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Dream     │    56 │
│ Chinstrap │ Dream     │    68 │
│ Gentoo    │ Biscoe    │   124 │
└───────────┴───────────┴───────┘

Who is Ibis for?

Ibis is for data engineers, data analysts, and data scientists (or any title that needs to work with data!) to use directly with their data platform(s) of choice. It also has benefits for data platforms, organizations, and library developers.

Ibis for practitioners

You can use Ibis at any stage of your data workflow, no matter your role.

Data engineers can use Ibis to:

  • write and maintain complex ETL/ELT jobs
  • replace fragile SQL string pipelines with a robust Python API
  • replace PySpark with a more Pythonic API that supports Spark and many other backends

Data analysts can use Ibis to:

  • use Ibis interactive mode for rapid exploration
  • perform rapid exploratory data analysis using interactive mode
  • create end-to-end analytics workflows
  • work in a general-purpose, yet easy to learn, programming language without the need for formatting SQL strings

Data scientists can use Ibis to:

  • extract a sample of data for local iteration with a fast local backend
  • prototype with the same API that will be used in production
  • preprocess and feature engineer data before training a machine learning model

Ibis for data platforms

Data platforms can use Ibis to quickly bring a fully-featured Python dataframe library with minimal effort to their platform. In addition to a great Python dataframe experience for their users, they also get integrations into the broader Python and ML ecosystem.

Often, data platforms evolve to support Python in some sequence like:

  1. Develop a fast query engine with a SQL frontend
  2. Gain popularity and need to support Python for data science and ML use cases
  3. Develop a bespoke pandas or PySpark-like dataframe library and ML integrations

This third step is where Ibis comes in. Instead of spending a lot of time and money developing a bespoke Python dataframe library, you can create an Ibis backend for your data platform in as little as four hours for an experienced Ibis developer or, more typically, on the order of one or two months for a new contributor.

 
Why not the pandas or PySpark APIs?
 

Ibis for organizations

Organizations can use Ibis to standardize the interface for SQL and Python data practitioners. It also allows organizations to:

  • transfer data between systems
  • transform, analyze, and prepare data where it lives
  • benchmark your workload(s) across data systems using the same code
  • mix SQL and Python code seamlessly, with all the benefits of a general-purpose programming language, type checking, and expression validation

Ibis for library developers

Python developers creating libraries can use Ibis to:

  • instantly support 20+ data backends
  • instantly support pandas, PyArrow, and Polars objects
  • read and write from all common file formats (depending on the backend)
  • trace column-level lineage through Ibis expressions
  • compile Ibis expressions to SQL or Substrait
  • perform cross-dialect SQL transpilation (powered by SQLGlot)

How does Ibis work?

Most Python dataframes are tightly coupled to their execution engine. And many databases only support SQL, with no Python API. Ibis solves this problem by providing a common API for data manipulation in Python, and compiling that API into the backend’s native language. This means you can learn a single API and use it across any supported backend (execution engine).

Ibis broadly supports two types of backend:

  1. SQL-generating backends
  2. DataFrame-generating backends
 
 
 
 

As you can see, most backends generate SQL. Ibis uses SQLGlot to transform Ibis expressions into SQL strings. You can also use the .sql() methods to mix in SQL strings, compiling them to Ibis expressions.

While portability with Ibis isn’t perfect, commonalities across backends and SQL dialects combined with years of engineering effort produce a full-featured and robust framework for data manipulation in Python.

In the long-term, we aim for a standard query plan Intermediate Representation (IR) like Substrait to simplify this further.

Python + SQL: better together

For most backends, Ibis works by compiling Python expressions into SQL:

g = t.group_by(["species", "island"]).agg(count=t.count()).order_by("count")
ibis.to_sql(g)
SELECT
  *
FROM (
  SELECT
    `t0`.`species`,
    `t0`.`island`,
    COUNT(*) AS `count`
  FROM `ibis_read_parquet_pp72u4gfkjcdpeqcawnpbt6sqq` AS `t0`
  GROUP BY
    1,
    2
) AS `t1`
ORDER BY
  `t1`.`count` ASC NULLS LAST

You can mix and match Python and SQL code:

sql = """
SELECT
  species,
  island,
  COUNT(*) AS count
FROM penguins
GROUP BY species, island
""".strip()
  • DuckDB
  • DataFusion
  • PySpark
con = ibis.connect("duckdb://")
t = con.read_parquet("penguins.parquet")
g = t.alias("penguins").sql(sql)
g
┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Dream     │    56 │
│ Gentoo    │ Biscoe    │   124 │
│ Chinstrap │ Dream     │    68 │
└───────────┴───────────┴───────┘
g.order_by("count")
┏━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┓
┃ species   ┃ island    ┃ count ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━┩
│ string    │ string    │ int64 │
├───────────┼───────────┼───────┤
│ Adelie    │ Biscoe    │    44 │
│ Adelie    │ Torgersen │    52 │
│ Adelie    │ Dream     │    56 │
│ Chinstrap │ Dream     │    68 │
│ Gentoo    │ Biscoe    │   124 │
└───────────┴───────────┴───────┘

This allows you to combine the flexibility of Python with the scale and performance of modern SQL.

Scaling up and out

Out of the box, Ibis offers a great local experience for working with many file formats. You can scale up with DuckDB (the default backend) or choose from other great options like Polars and DataFusion to work locally with large datasets. Once you hit scaling issues on a local machine, you can continue scaling up with a larger machine in the cloud using the same backend and same code.

If you hit scaling issues on a large single-node machine, you can switch to a distributed backend like PySpark, BigQuery, or Trino by simply changing your connection string.

Stream-batch unification

As of Ibis 8.0, the first stream processing backends have been added. Since these systems tend to support SQL, we can with minimal changes to Ibis support both batch and streaming workloads with a single API. We aim to further unify the batch and streaming paradigms going forward.

Ecosystem

Ibis is part of a larger ecosystem of Python data tools. It is designed to work well with other tools in this ecosystem, and we continue to make it easier to use Ibis with other tools over time.

Ibis already works with other Python dataframes like:

Ibis already works well with visualization libraries like:

Ibis already works well with dashboarding libraries like:

Ibis already works well with machine learning libraries like:

Supported backends

You can install Ibis and a supported backend with pip, conda, mamba, or pixi.

  • pip
  • conda
  • mamba
  • pixi
  • BigQuery
  • ClickHouse
  • DataFusion
  • Druid
  • DuckDB
  • Exasol
  • Flink
  • Impala
  • MSSQL
  • MySQL
  • Oracle
  • Polars
  • PostgreSQL
  • PySpark
  • RisingWave
  • Snowflake
  • SQLite
  • Trino

Install with the bigquery extra:

pip install 'ibis-framework[bigquery]'

Connect using ibis.bigquery.connect.

 
Warning

Note that the ibis-framework package is not the same as the ibis package in PyPI. These two libraries cannot coexist in the same Python environment, as they are both imported with the ibis module name.

See the backend support matrix for details on operations supported. Open a feature request if you’d like to see support for an operation in a given backend. If the backend supports it, we’ll do our best to add it quickly!

Community

Community discussions primarily take place on GitHub and Zulip.

Getting started

If you’re interested in trying Ibis we recommend the getting started tutorial.

반응형
반응형

[DataBase] Postgres를 검색엔진으로 활용하기  

 

https://anyblockers.com/posts/postgres-as-a-search-engine

 

Postgres as a search engine

Build a retrieval system with semantic, full-text, and fuzzy search in Postgres to be used as a backbone in RAG pipelines.

anyblockers.com

 

 

 


  • Postgres 내에서 시맨틱, 전문, 퍼지 검색을 모두 갖춘 하이브리드 검색 엔진을 구축할 수 있음
  • 검색은 많은 앱에서 중요한 부분이지만 제대로 구현하기 쉽지 않음. 특히 RAG 파이프라인에서는 검색 품질이 전체 프로세스의 성패를 좌우할 수 있음
  • 의미론적(Semantic) 검색이 트렌디하지만, 전통적인 어휘 기반 검색은 여전히 검색의 중추임
  • 의미론적 기술은 결과를 개선할 수 있지만, 견고한 텍스트 기반 검색의 기반 위에서 가장 잘 작동함

Postgres를 활용한 검색 엔진 구현하기

  • 세 가지 기술을 결합:
    • tsvector를 사용한 전체 텍스트 검색
    • pgvector를 사용한 의미론적 검색
    • pg_trgm을 사용한 퍼지 매칭
  • 이 접근 방식은 모든 상황에서 절대적으로 최고는 아닐 수 있지만, 별도의 검색 서비스를 구축하는 것에 대한 훌륭한 대안임
  • 기존 Postgres 데이터베이스 내에서 구현하고 확장할 수 있는 견고한 출발점
  • Postgres를 모든 것에 사용해야 하는 이유 : 그냥 Postgres를 모든 곳에 사용하세요, PostgreSQL로 충분하다, 그냥 Postgres 쓰세요

FTS와 의미론적 검색 구현

  • Supabase에 하이브리드 검색 구현에 대한 훌륭한 문서가 있으므로, 이를 시작점으로 삼을 것임
  • 가이드에 따라 GIN 인덱스를 사용하여 FTS를 구현하고, pgvector(bi-encoder dense retrieval이라고도 함)를 사용하여 의미론적 검색을 구현함
  • 개인적인 경험으로는 1536차원의 임베딩을 선택하는 것이 훨씬 더 나은 결과를 얻을 수 있음
  • Supabase 함수를 CTE와 쿼리로 대체하고, 매개변수 앞에 $를 붙임.
  • 여기서는 RRF(Reciprocal Ranked Fusion)를 사용하여 결과를 병합함
  • 이 방법은 여러 목록에서 높은 순위를 차지하는 항목이 최종 목록에서 높은 순위를 부여받도록 보장함
  • 또한 일부 목록에서는 높은 순위지만 다른 목록에서는 낮은 순위인 항목이 최종 목록에서 높은 순위를 부여받지 않도록 보장함
  • 순위를 분모에 넣어 점수를 계산하면 순위가 낮은 레코드에 불이익을 줄 수 있음
  • 주목할 만한 사항
    • $rrf_k: 첫 번째 순위 항목의 점수가 극단적으로 높아지는 것을 방지하기 위해(순위로 나누기 때문에), 분모에 k 상수를 추가하여 점수를 평활화하는 경우가 많음
    • $ _weight: 각 방법에 가중치를 할당할 수 있음. 이는 결과를 조정할 때 매우 유용함

퍼지 검색 구현하기

  • 이전까지의 방법으로도 많은 부분을 해결할 수 있지만, 명명된 엔티티에서 오타가 있을 경우 즉각적인 이슈가 발생할 수 있음
  • 의미론적 검색은 유사성을 포착하여 이러한 이슈 중 일부를 제거하지만, 이름, 약어 및 의미론적으로 유사하지 않은 기타 텍스트에 대해서는 어려움을 겪음
  • 이를 완화하기 위해 pg_trgm 확장을 도입하여 퍼지 검색을 허용
    • 트라이그램으로 작동함. 트라이그램은 단어를 3자 시퀀스로 분해하기 때문에 퍼지 검색에 유용
    • 이를 통해 오타나 약간의 변형이 포함되어 있더라도 유사한 단어를 매칭할 수 있음
    • 예를 들어 "hello"와 "helo"는 많은 트라이그램을 공유하므로 퍼지 검색에서 더 쉽게 매칭될 수 있음
  • 원하는 열에 대해 새 인덱스를 생성하고, 그 후 전체 검색 쿼리에 추가
  • pg_trgm 확장은 % 연산자를 노출하여 유사도가 pg_trgm.similarity_threshold(기본값은 0.3)보다 큰 텍스트를 필터링함
  • 유용한 다른 여러 연산자도 있음.

전문 검색 튜닝하기

  • tsvector 가중치 조정하기 :실제 문서에는 제목뿐만 아니라 내용도 포함됨
  • 열이 여러 개 있어도 임베딩 열은 하나만 유지함
  • 개인적으로 여러 임베딩을 유지하는 것보다 title과 body를 같은 임베딩에 유지하는 것이 성능에 큰 차이가 없다는 것을 발견함
  • 결국 title은 본문의 간단한 표현이어야 함. 필요에 따라 이를 실험해 보는 것이 좋음
  • title은 짧고 키워드가 풍부할 것으로 예상되는 반면, body는 더 길고 더 많은 세부 정보를 포함할 것임
  • 따라서 전체 텍스트 검색 열이 서로 어떻게 가중치를 부여하는지 조정해야 함
  • 문서에서 단어가 있는 위치나 중요도에 따라 우선순위를 부여할 수 있음
    • A-weight: 가장 중요(예: 제목, 헤더). 기본값 1.0
    • B-weight: 중요(예: 문서 시작 부분, 요약). 기본값 0.4
    • C-weight: 표준 중요도(예: 본문 텍스트). 기본값 0.2
    • D-weight: 가장 덜 중요(예: 각주, 주석). 기본값 0.1
  • 문서 구조와 애플리케이션 요구사항에 따라 가중치를 조정하여 관련성을 미세 조정함
  • 제목에 더 많은 가중치를 부여하는 이유
    • 제목은 일반적으로 문서의 주요 주제를 간결하게 표현하기 때문
    • 사용자는 검색할 때 먼저 제목을 훑어보는 경향이 있으므로 제목의 키워드 일치는 일반적으로 본문 텍스트의 일치보다 사용자의 의도와 더 관련이 있음

길이에 따른 조정

  • ts_rank_cd 문서를 읽어보면 정규화 매개변수가 있다는 것을 알 수 있음.
    • 두 랭킹 함수 모두 문서의 길이가 순위에 어떤 영향을 미쳐야 하는지 여부를 지정하는 정수 normalization 옵션을 사용함. 정수 옵션은 여러 동작을 제어하므로 비트 마스크임: |를 사용하여 하나 이상의 동작을 지정할 수 있음(예: 2|4).
  • 이러한 다양한 옵션을 사용하여 다음을 수행 가능
    • 문서 길이 편향 조정
    • 다양한 문서 집합에서 관련성 균형 조정
    • 일관된 표현을 위해 랭킹 결과 조정
  • 제목에는 0(정규화 없음), 본문에는 1(로그 문서 길이)을 설정하면 좋은 결과를 얻을 수 있음
  • 다시 말하지만, 사용 사례에 가장 적합한 옵션을 찾기 위해 다양한 옵션을 실험해 보는 것이 좋음

크로스 인코더를 사용한 재랭킹

  • 많은 검색 시스템은 두 단계로 구성됨
  • 즉, 양방향 인코더를 사용하여 초기 N개의 결과를 검색한 다음, 크로스 인코더를 사용하여 이러한 결과를 검색 쿼리와 비교하여 순위를 매김
    • 양방향 인코더(bi-encoder) : 빠르기 때문에 많은 수의 문서를 검색하는 데 좋음
    • 크로스 인코더(cross-encoder)
      • 더 느리지만 성능이 더 좋아 검색된 결과의 순위를 다시 매기는 데 좋음
      • 쿼리와 문서를 함께 처리하여 둘 사이의 관계에 대한 더 미묘한 이해를 가능하게 함
      • 이는 계산 시간과 확장성을 희생하면서 더 나은 랭킹 정확도를 제공함
  • 이를 수행하기 위한 다양한 도구들이 있음
  • 가장 좋은 것 중 하나는 Cohere의 Rerank
  • 또 다른 방법은 OpenAI의 GPT를 사용하여 자체적으로 구축하는 것
  • 크로스 인코더는 쿼리와 문서 간의 관계를 더 잘 이해할 수 있도록 하여 검색 결과의 정확도를 높일 수 있음
  • 그러나 계산 비용이 크기 때문에 확장성 면에서는 제한이 있음
  • 따라서 초기 검색에는 양방향 인코더를 사용하고, 검색된 소수의 문서에 대해서만 크로스 인코더를 적용하는 두 단계 접근 방식이 효과적임

언제 대안 솔루션을 찾아야 할까

  • PostgreSQL은 많은 검색 시나리오에 적합한 선택이지만 한계가 없는 것은 아님
  • BM25와 같은 고급 알고리듬의 부재는 다양한 문서 길이를 처리할 때 느껴질 수 있음
  • PostgreSQL의 전체 텍스트 검색은 TF-IDF에 의존하므로 매우 긴 문서와 대규모 컬렉션의 희귀 용어에 어려움을 겪을 수 있음
  • 대안 솔루션을 찾기 전에 반드시 측정해 보아야 함. 그럴 가치가 없을 수도 있음

결론

  • 이 글에서는 기본적인 전체 텍스트 검색부터 퍼지 매칭, 의미론적 검색, 결과 부스팅과 같은 고급 기술까지 많은 내용을 다루었음
  • Postgres의 강력한 기능을 활용하여 특정 요구사항에 맞춘 강력하고 유연한 검색 엔진을 만들 수 있음
  • Postgres는 검색을 위해 가장 먼저 떠오르는 도구는 아니지만 정말 멀리 갈 수 있게 해줌
  • 훌륭한 검색 경험을 위한 핵심
    • 지속적인 반복과 미세 조정
    • 논의한 디버깅 기법을 사용하여 검색 성능을 이해하고, 사용자 피드백과 행동을 기반으로 가중치와 매개변수를 조정하는 것을 두려워하지 말아야 함
  • PostgreSQL은 고급 검색 기능이 부족할 수 있지만, 대부분의 경우 충분히 강력한 검색 엔진을 구축할 수 있음
  • 대안 솔루션을 찾기 전에 먼저 Postgres의 기능을 최대한 활용하고 성능을 측정해 보는 것이 좋고, 그래도 부족하다면 그때 다른 솔루션을 고려해 볼 수 있음

https://news.hada.io/topic?id=16468&utm_source=weekly&utm_medium=email&utm_campaign=202436

 

Postgres를 검색엔진으로 활용하기 | GeekNews

Postgres 내에서 시맨틱, 전문, 퍼지 검색을 모두 갖춘 하이브리드 검색 엔진을 구축할 수 있음검색은 많은 앱에서 중요한 부분이지만 제대로 구현하기 쉽지 않음. 특히 RAG 파이프라인에서는 검색

news.hada.io

 

 

반응형

+ Recent posts